I wish we could just call developers users. There are so many developers in the world, that it almost makes perfect sense that we consider them users. Look at all the software, in particular, look at the open source projects on github. They're disproportionately geared toward developers. In essence, we're creating tool software where the users are other developers just like ourselves. Some may say that is a problem — too many tools, not enough applications to solve specific problems. Software not applied. On the other hand, too many tools is kind of hard to believe. There is such thing as too much choice, and under these conditions, only the strong survive. The great thing about tools, however, is that even if you've familiarized yourself with a specific tool that doesn't have a large community of supporters, you're free to either continue using as is, or to continue developing the tool. Either way, you're using it for your own project, which may happen to be another tool, or an application that a more typical user needs. Tools are just software. Developers are just users. It's not just in the open source space where tools are fundamental to the software development process — I hear Visual Studio has a few customers too. Myself, leaning toward the open source end of the spectrum, can't help but wonder — how do projects better serve their primary users when they are developers?
So maybe calling developers just regular users is painting with a broad brush. But just as an exercise, why not look at things this way? A particular user profile in an application is going to require certain things — certain widgets, certain, layouts, and certain default settings. Developers want familiar patterns, a consistent API, and documentation. This is actually a key difference between the developer user and the typical user — developers crave documentation. Which isn't to say that the regular user doesn't want documentation, they just don't want it as a prerequisite to using the software. They would just like to get started, learning the ins-and-outs of the thing. Trial and error is the best teacher when it comes to learning a new software system. The same is true with developers — trial and error trumps all other approaches to learning, but when it comes to troubleshooting, and learning the ins and outs of why the component behaves the way it does — that's where documentation is crucial. And maybe that's so different from the regular user after all. The UI should be intuitive, they should be able to get the hang of how to use the thing without using the user manual as a crutch. And developers just want to code — you're not coding when you're reading documentation about how to code.
Developers are also like typical end users in that they are typical end users. No, seriously, they use some of the same applications as the rest of the universe. Which should come as no real surprise — you can't script everything. Even if we could, we wouldn't want to. Somebody out there has already done it for us. And so we use the software that already exists, whatever the use case might by. It's probably a web application, because everything is a web application. Things go well. We start learning where things go, which buttons not to press, everything makes sense. Then our minds start to wander. I wonder how this thing is implemented? I've already got a client application I wrote myself that talks to this other thing, how can I plugin this one in? And so on. Where is the API, we want to know. How can we better utilize this software? There are fewer and fewer applications without APIs in one form or another. They're capturing the developer audience, which keeps growing and growing.
Why does the developer audience keep growing like this? It never used to be this big. Something must have triggered the exponential developer growth, right? Or, is it the same factor that's still causing growth in the software development community? I think it's the same factor — accessibility. Without it, you only have those dedicated programmers who really know what they're doing. Without accessibility, you have a much larger investment ahead of you in terms of learning the trade. The barrier to entry has been lowered. Significantly. It's been lowered, in fact, to the point that an individual could crank out an application, and make it available to a marketplace, all in one day. Mind you, this says nothing of capabilities or the quality of those capabilities, but it most certainly attests to the notion that anyone can develop software.
Reading code is an unnoticed activity in software development. It goes unnoticed because you don't explicitly set out to read code, it happens as a bi-product of some other activity. Usually when you have to implement something and you need to look elsewhere for inspiration or guidance. Where do you look for such examples? There are probably plenty lying around in the source code repositories where you work. Probably even your own code will revive itself and serve as a source of knowledge. Open source projects have a lot of code available for your reading pleasure. Now, you may or may not actually use the code you're reading. That is, you may only be ware of how the software works or what it does as opposed to having installed it locally on your system. Doesn't matter. If you can find what you're looking for in the code base, it has delivered something valuable. A source of inspiration or guidance. It never used to be as easy as it is today, to find these examples online. Collaborative open source project tools such as Gitbub provide the means to easily locate code you want to read. The code, for the entire project, is visible in your browser, and easily traversed.
It's one thing to target a developer audience by exposing an API from your product. It's something else entirely to engage those developers, to influence the creation of new applications that function on the very backbone of your system. Developers can certainly appreciate communities, but getting a community going around a programming environment is something that needs to happen organically, over the course of many years. It takes time to build an audience, and this generally happens as a result of a great API. Organically-formed communities aren't necessarily created by the product owners, but instead by the enthusiastic users that want the product to succeed. Of course, this is almost always an open source project, where you see this kind of community synthesis. But, the idea applies in any software scenario with a potential developer audience — you're a tool maker. The broader application itself is just the bare-bone business rules, probably with a user interface. But the API is the tool-belt. So is the API documentation. So are the API examples. These are essential tools that any developer needs if they're to have any interest in adopting your stuff. Provide the tools, keep them clean, and the community will form itself.
The global developer audience is a big one. There are no major technological communication issues, only cultural and political. And yet, it seems that there is too much out there. I'm part of the audience myself, and I have trouble focusing on any one project available for me to learn and understand simply because there are so many interesting tools at my disposal. I'm sure there are others like me too, wondering, how do you limit the scope of what you learn, and what you build? Should you impose limits? Should you instead, continuously broaden your horizon while keeping your depth at a minimum? I wish I could say I had an answer, but I don't. The generic approach of striking a balance between breadth and depth can only work so well as the software ecosystem continues to grow and grow. The best thing I can do for myself right now is to understand the foundational principles behind what makes good software, and how to make the best use of programmable systems out there today, and the new ones as they pop into existence.
No comments :
Post a Comment