The Gradual Development Paradigm
Software project management is tricky. The industry proves this over and over again: delivering less than expected, slipping features, projects, milestones, products…
The gradual development idea presented below is not something new – it's more or less common-sense. Often, however, not all positive implications of it are fully understood or internalized, so I thought I’d share this article, which I sent to my team several years ago.
Admittedly, some of this is old news. After all we live in the age of Agile, rapid iteration and integration, test-driven design and development. It still surprises me how many teams tend to slip in old behaviors on a regular basis, so I have personally found these practices worth reviewing and repeating.
Case Study
Imagine that you have 5 developers and that you are 1 day before your deadline. If they have not checked in anything, you are scared (understandably): they may deliver anything between 500% (100% each) and 0%. That's a lot of stress for a team lead.
Now imagine that you have 5 developers, who have delivered gradually in smaller pieces. Understandably, they have delivered less (because gradual development is more expensive), but at day-1, you know that you are at say 450% so your uncertainty is only 50% (rather than 500%) or even less (since as a result of the gradual development you have lost time, so you know you can only accomplish 20% more summing up to say 470%).
Which situation would you choose to be in: 500% of risk with a potential heart attack or 20% of risk with a known under-delivery and 8-hour work days at the end of the project?
The Theory of Gradual Development
The diagram below presents the principle of gradual development. Person A has adopted the "I will code it on my computer and worry about code and design review, deployment, logistics at the end when I am done" approach. Person B has adopted the "gradual development" approach.
But wait a minute, I hear you say, person B is actually slipping while person A may deliver on time after all.
What is missing from the diagram is that it is never a 1-person team. We usually talk about teams of 5, 10, 20 people. Let's assume that there is a 5% probability that Person A will not deliver on time i.e. there is a 95% probability that Person A will deliver as expected (that's a good healthy number – everyone who has shipped a product will tell you that is a pretty high confidence.
Then for a team of 20 people, the combined probability to actually deliver on time is 95%20 = 36%. That's encouraging![1] Here are the expanded results:
Or, as a chart:
Note that for a team of 200 people, the probability to deliver on time is close to 0%!
How does gradual development help? Well, on "ship day - 1", you know that your team has already shipped 90% of the product, so the probability to ship on time is 90% + (10% * 95%20) = 94%. Way better than 0%, isn't it?
The Practice of Gradual Development
Here are some practical directions:
1. Defy the urge to produce big chunks
All of us want to impress our bosses or peers by creating something big and delivering it as a whole. That's one sure way to produce the "wow effect". In reality however, you rarely (if ever) get to impress anybody that much. However, you can, truly, build a reputation of a rock-solid and predictable achiever. People who have this reputation are awarded and valued everywhere, because the mere ability to ship and sell is what defines a business.
2. Constantly ask yourself "how can I deploy this today?"
Gradual development is great in theory, but in practice it's just too easy to slip back to the regular "I am going to show them how fast and complete I am" or "I'll have enough time to deploy after I am done" routines.
Gradual development does not come naturally to any of us. It (much like OOP) is an acquired taste, so we have to constantly remind ourselves that we have to constantly ship. You are not ready with the whole implementation? Not a problem! Stub it (e.g. make the unimplemented functions to return E_NOTIMPL) and ship it.
“Deploying” or “Shipping” may mean different things to different people:
- To a developer, "shipping" means adding the feature to the build and to the installation of the product.
- To a tester, "shipping" means deploying a test in the lab (as "lab ready").
- To a PM, "shipping" means publishing a spec (although the spec may not be fully ready).
3. Maintain a rapid create-test-deploy cycle
People often forget that deployment is part of the job. In fact it is a very significant and time consuming part of the job. We all came into the software development business, because we wanted to program. It turns out, however, that software development is not only about programming. Strangely enough pure programming does not really occupy most of our time: deployment and maintenance does. Embrace this reality and make it a goal not to program, but to deploy.
4. If you are a manager, reward gradual development
You want predictability from your business? Then reward predictability (e.g. predictable achievers, rather than unpredictable Einsteins[2].)
5. If you are an individual contributor, keep in mind the perspective of your manager
Remember that while you can happily live with a confidence of 95%, your manager is a manager of 5, 10 20 people, so he / she has to live with a significantly reduced confidence.
+++
[1] For simplicity, it is assumed that the probability of successful delivery from a given team member is independent from other team member's deliveries i.e. for a team of two people, the combined probability Pcombined = P(contributor 1 delivers on time) * P(contributor 2 delivers on time). If this assumption in not valid, the resulting combined probability is even lower!
[2] This of course is taken to extreme. You absolutely need the Einsteins. In fact, it is “manageable Einsteins” that often make the difference between a moderately successful and a hugely successful product.