Contemplating the Ideal Structure for Application Development
I've been thinking a lot lately about the ideal structure for application development. It's more than just what makes the developer productive, it's also what makes a great application. There are components of infrastructure, user-interface design, support, reliability, stability, responsiveness. All the things that work together to create truly exceptional software.
I've been thinking about this because recent jobs have had vastly different models for how things should be done. Is there a QA department? Is there an Operations group that must take ownership of the developed product? Who supports the app with the end users? How does feedback make it's way to the developer from the users?
There are a lot ways to do this - probably as many as there are companies on the map. But I'm looking at the few examples I've been exposed to up-close, for an extended period of time.
The Cube Farm - Stick to Your Assignment, Developer
Probably one of the most Dilbert-esque, and therefore, most common, forms of organization is to function under the belief that management knows best. That people can really be modeled as ants in an ant farm - interchangeable, fungible, assets that can be told what to do and they will execute on those instructions as well as if they had any input or control in the decision-making process. It's born out of the idea of the old Peter Principle:
In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence.
Developers that are really good developers must be good managers, so they are put in charge of a small team. Do that well, and he must be a good manager, and so put him in charge of a few teams. This continues until he's no longer really good at his job, and the promoting stops. However, the damage is already done.
You now have a great developer in management, and so he believes that he knows how to do this development, and he's right - he knows. But only about how he does it. If there's a person that's really effective because they write the docs first and then use that as a template for the system, that's great. But it's not a universal imperative. Not everyone will work best that way. Maybe some people see a design unfold best when they start writing code and see where it takes them. This might be along the lines of the Extreme Programming movement. No two people are really interchangeable. Not really.
In this kind of environment, there are Teams for everything. There's a Team for requirements gathering. Another for design. Another for development. Another for documentation. Another for Q/A. All these groups are designed to be very good at their jobs, and individually, they are. But that doesn't alter the fact that the line of communication between the users and any one individual is very complex, and error-prone. It's like the school-kids game of "operator" - each kid whispering the word they heard to the next, and at the end of the class what comes out is often times not at all like what went in.
To get the users the very best application, every person in that complex system needs to be aware of what is going on in all the different groups. If they hear of something that should be told to another group, they need to be able to get that information to that group. Unfortunately, that's not how these groups typically work. The larger the group the less effective the communication. When in order to work, it needs to be just the opposite.
So while this seems like a good idea for development, it's never been really good at delivering a great product to the users. It can get useful stuff out there, but it's at the cost of time. This kind of structure runs very slowly.
The Tiny Shop - Jack-of-All-Trades Developer
One could think that the other end of the spectrum is the indie developer. Let's surround him with a few partners and call it the start-up or small business developer. This guy has to do everything. This includes doing the sales, marketing, support, requirements gathering, design, development, deployment, etc. There's just no one else to help. In my opinion, there's a lot to like about this situation, having been in it before - there's no one else to worry about dropping the ball. You have to understand the problem domain in order to write the system, but that means you have to really understand your customers - never a bad thing. You have to be able to balance the infrastructure "cool" with the practical and the user-interface - it has to perform acceptably, but it's got to look nice as well. You have to be good at almost everything in the pipeline.
There are plenty of downsides to the person that's a little weak in one or more of these areas. If you're horrible at UIs, then you're going to be very uncomfortable with the fact that there's no one else to lean on for a UI for your back-end. The same would be true for sales or support or domain knowledge. If you're not willing to come up to speed on these areas - or shop them out to someone who is, then you're going to be uncomfortable. But for those people that are used to this, it represents a wonderfully freeing opportunity.
You can write your own code because you understand the domain. Be it a drawing app, a photography app, a simulation of some kind, or something as focused as a cellular image processing app. If you understand the domain, and can code, this model really allows you to control the entire project - much like the old masters painters. They sat in a room, conceived of a painting and then did it. Period. There's a lot to be said for those that can do this, to enjoy this more than working as a single member of a much larger team.
But it's not without risks as you're only as good as your weakest link, and if you're doing it all, your product is only as good as your weakest subject. This isn't for everyone, that's for sure. But it's something I've had experience with, and found very satisfying.
The Partnership - A Hybrid Approach
In engineering, there's always the continuous spectrum where an optimization is done to find the most effective solution to the problem. Given that this is my background, I have to look at this same problem with this same bias. Where is the most effective balance?
My current thinking is that the best balance is a partnership with the right partner. You need to complement each other. I know how important this is as I've been in partnerships where this wasn't the case, and it ended horribly. You have to be willing to take control and take over for your partner when they are down, and likewise, you have to be able to trust your partner to do the same for you.
This doesn't mean that you need to identical skill sets, or even complementary ones. It's enough to overlap in some areas and be weak in others. It's part of the dynamics of the partnership. Have someone to lean on, but not someone that's going to ask you where the cover letter is for your TPS Report.
While I think there is value in a larger organization, and there's considerable freedom in the indie developer, an appropriate balance of the two is really where you have to live. If I had a bunch of money and never needed to make another dime, I'd be an indie developer and that's it. But if I need to actually sell something to someone, I think I'm shooting for the partnership.