mentis vulgaris
simple thoughts | jason smith
The Bottleneck
Posted by Jason Smith - 20/02/10 at 10:02:47 amNearly 70% of all software projects are considered unsuccessful. They are late, over budget and have fewer features than users wanted (and often ones they didn’t want – I’m looking at you, Clippy).
I gotta ask, would this situation exist if we had perfect knowledge of the future?
If we knew the user interface would confuse our users – would we spend as much time as we did implementing it the wrong way? If we knew our design would lead to performance issues, wouldn’t we select an alternate before we were too committed? If we knew the code we just wrote had a bug in it wouldn’t we fix the code before it even consumed a second of QA’s time? If we knew that QA would find a bug in a third party product caused by the way we called the API, would we have altered our design to compensate?
Most of our problems developing software would be solved by knowing, by learning the things we don’t know earlier and faster.
Now consider the Theory of Constraints:
- Any manageable system is limited in achieving more of its goal by a very small number of constraints.
- There is always at least one constraint.
In a nutshell, we will see the greatest improvements in our ability to reach our goals by understanding and defeating our greatest constraints.
If that’s so, then software projects are unsuccessful because we haven’t optimized the activity we spend most of our time doing. That activity is not coding, requirements gathering, bug fixing or dropping in an easter egg. The biggest constraint we have is Learning:
- Learning what the customer wants
- Learning whether what we wrote is what the customer really wanted
- Learning how use an API
- Learning code the guy down the hall wrote
- Learning when we’re actually going to deliver
- Learning whether our code actually works
- Learning why it didn’t in a special case
- Ad nauseum
Good product developers intuitively understand this. They actively seek out ways to learn faster and earlier.
They learn early that the UI they are doing meets the user’s needs and doesn’t confuse (prototyping and seeking active customer feedback). They understand that it’s orders of magnitude cheaper (in both dollars and effort) to learn about and fix a bug when the bug is introduced (automated unit testing and continuous integration). They understand that the fastest way to help our coworkers learn what we are doing is by collaborating with them (pair programming, daily stand-ups and being colocated). They learn about their risks early by working the risky code early (spike solutions). They know that code that is easy to understand is easier to learn and use (simple design, simple code that expresses intent).
Optimize the process of learning, and we optimize how we develop software.
1 Comment »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds.
Valid XHTML and CSS.
Great info once again!! I am looking forward for more updates=)
Comment by Sabina Nuse — September 2, 2011 #