Do you feel like your organization’s development process delivers too little at too slow a pace? Your gut feeling is probably correct. In this post, I’ll describe three paradigms that result in near zero or even negative productivity.

The Solo Developer Paradigm

This one is too easy and obvious, so let’s just tick it off. In the Solo Developer Paradigm, Conway’s law has been taken to the extreme resulting in a single system being implemented by a single developer. Initially, productivity is good, because the person can keep the entire system in his head and changes are easy because the solo developer changes code that he has written himself. After a few years, the person quits and leaves you with a masterpiece of professional software engineering… not.

You discover that the system that the organization has depended on until now is an undocumented, untested mess of programming by Stack Overflow. Attempts at evolving or understanding the non-existent architecture result in waste of time and frustration, and eventually you arrive at the conclusion that the entire thing must be rewritten. Oh, one more thing… The requirements aren’t documented anywhere. Enter negative productivity.

How To Get There?

To be fair, this situation can arise organically. The company is small, young, or just isn’t centered around IT. In such cases, it’s quite intuitive to start out small with one developer. This is not wrong in any way. The wrongdoing comes after; when you keep running a larger development organization like that.

Some Afterthoughts

One thing puzzles me about this setup: why does this seem to be the natural order of things? Referring to my own experience, and hence anecdotal evidence, I can say that I’ve never seen a solo developer producing something of industry-strength quality: properly documented architecture, testable and tested, and properly deployable and deployed. Is it the perceived lack of time? Do certain people end up in the solo developer position? Does the absence of peers result in lower standards? I honestly don’t know.

The Left Unchecked Vendor Paradigm

In this paradigm, an organization outsources everything to a vendor, or “partner”, after having stated that software development isn’t its core business and that it can be bought off the shelf. For some reason, this tends to result in poor quality, increasing costs, and frosty relations after a while. In the long run, productivity approaches zero as discussions about future system changes become contract negotiations and arguments over quality.

How To Get There?

No vendor, regardless of seniority and experience, can read your mind and execute on your business plan. Good vendors will try to do the right thing and understand as much as possible of your business and its challenges; bad vendors will sell you armies of people. If you outsource “everything”, how do you ensure that the vendor knows how to leverage system development to best execute on your business plan? Many problems are best solved without software. Sometimes it’s just cheaper and faster to get ten students to do some manual data processing. How do you ensure that the vendor’s iterative deliveries map to your current objectives? By the way, are there even iterative deliveries, or has the vendor promised to deliver The System on The Big Day? How do you ensure that the system is maintainable, testable, and well documented? Vendors come and go, and so do the people who work for them.

In summation, unrealistic expectations together with inadequate sourcing and vendor management skills will easily push you into this paradigm.

Some Afterthoughts

In my mind, you can’t outsource your entire problem domain to a vendor in a fire-and-forget fashion. It won’t work, even with the best of vendors.  Setting up the adequate communication channels, managing expectations (both ways), and doing acceptance testing will require time and headcount. And here’s the tricky one: Given the cost of the above, when does the business case break down?

The Junior Developer Paradigm

There was a great business idea, funding was secured, and now it was all about speed. Thirty in-house, local contractor, or off-shore (or mix thereof) developers would ensure the success. Something was launched and it kind of worked. While there were quality issues, and some customers complained, there were already big plans for the new killer features. As those features were about to be implemented, the development process came to a grinding halt. What went wrong?

How To Get There?

You get into this situation by treating software development like packing bananas into wooden creates. Suppose it takes one person one hour to pack ten crates of bananas, then it takes ten people ten hours to pack one thousand crates of bananas. Truth be told, I don’t know whether banana packing works like this, but I can tell you that software development doesn’t. Going for head count is a bad idea. Going for junior developer headcount is even worse.

Increased headcount, regardless of level of seniority, in software development organizations adds to complexity. Planning, coordination, and communication are affected. Everyone who’s brushed against “scaling agile” in one form or another can tell a story or two about that. There’s an extra danger in scaling through junior developers though. Junior developers are expensive! More expensive than seniors. The cost comes in many forms:

• Junior developers produce a lot of code. This may sound good, but the quantity comes from the fact that they’re not skilled enough to express themselves succinctly. Lots of code equals lots of code to maintain.
• Junior developers produce average, at best, solutions. Because of limited experience and knowledge, a junior will pick the first solution he got to work, as opposed to being aware of multiple solutions and picking the one appropriate for the situation.  
• Junior developers tie up senior developers, who should ideally mentor and teach them, but who most likely will end up rewriting or refactoring their code.
• Junior developers haven’t experienced the full software development life cycle, which means that they may have limited knowledge about testing, operations, and eventually costs of maintenance.

Now multiply this by thirty people…

Some Afterthoughts

Obviously, my intent isn’t to diminish junior developers. Nobody’s born senior and experienced, and everybody needs to learn on the first jobs. Besides, the nature of our industry is such that continuous learning is a must. That said, there’s a ratio that needs to be maintained between senior and junior developers, and there needs to be acceptance for the fact that the junior ones are learning, and that there will be cost of rework. The banana packing paradigm ignores this fact and tries to pass off as linear scaling.