Discover-Design-Build. In That Order.
Discover-Design-Build. In That Order.
Steve McConnell was a software engineer who worked at organizations like Microsoft and Boeing. He served as editor-in-chief of the IEEE Software magazine between 1998 and 2002. His first book, Code Complete, published in 1993, received outstanding reviews. It went on to win the Jolt Award in the same year. He has written and published more books. Many of them best sellers and all related to the software engineering industry. He’s now the CEO of Construx Software that provides training, coaching, and consulting for software teams and organizations.
In other words, McConnell knows his stuff when it comes to software engineering.
He has produced many useful resources and of his many gems of wisdom, there’s one I find myself referencing the most often. That’s what I will cover in this article here.
The public link is at YouTube which I have also embedded below. The most important part starts at 10:34 and ends around 17:36.
I’m not going to repeat every detail of this concept. He has said plenty in public YouTube and in his company’s paywalled training videos . My intention is to have my own concept handle / API endpoint for this concept I can link to whenever I mention it in future conversations.
Summary of Key Points
There are 3 phases when it comes to software development and there’s a linear order to them.
The phases are usually called Requirements, Design, and Implementation. McConnell prefers to call them Discovery, Invention, and Construction. I prefer to use verbs and fewer syllables, so I will use my preferred terms going forward: Discover, Design, and Build.
The order is: Discover → Design → Build.
McConnell has a single key insight about these 3 phases that has several key implications. The key insight is that the phases overlap during a software project.
One implication is that you begin the later phases before the earlier phases are complete.
You start Building before Discovery and Design are complete.
Design work starts before you finish Discovery.
Another implication is that some “upstream” work depends on “downstream” work. Examples such as:
You cannot finish writing a requirement in Discovery because you need to do some Design work to test that it’s feasible.
You cannot complete a Design because you lack implementation details. Details that you learn only after you try to Build something.
McConnell likens the nature of software projects having overlapping phases as a wicked problem. He has a nice and clean definition of a wicked problem, calling it a “problem that cannot be fully defined until it’s at least partially solved”.
His charts make it easy for him to make the following bold claims:
The degree to which a software project is a wicked problem varies.
And the degree is related to the amount of overlap.
So if you can reduce the amount of overlap, you can reduce the “wickedness” of a software project. This is the boldest claim and bears repeating: you can reduce the wickedness of a software project.
Screenshot of his Youtube video at 15:55 https://youtu.be/zrry3IpWCrg?t=954 
Screenshot of his Youtube video at 16:45 https://youtu.be/zrry3IpWCrg?t=1005
QnA
Q: Is it possible to reduce the overlap to zero?
A: I don’t think so. It’s possible to reduce the overlap to the absolute necessary bare minimum (ANBM). But this leads to a different question about two kinds of ANBM.
Q: What do you mean by “two kinds of ANBM”?
A: The two kinds are: theoretical and practical.
The theoretical ANBM which you only realize on hindsight or you assume perfect knowledge.
The practical ANBM based on the available information at the moment when making decisions.
You can get practical ANBM as close to the asymptote that is the theoretical limit with experience across multiple projects, but it’s like seeking perfection. You can get close but never actually reach it. The more any one project differs from previous projects that you have done before, the wider the gap is between the theoretical and the practical.
Knowing when to be at peace with that gap, and when to be dissatisfied and wanting to do better is the difference between a self-harming perfectionist and a productive high performer.
References
Responding to Uncertainty with the Intellectual Phases Model | Steve McConnell
Construx OnDemand - Understanding Software Projects (vueocity.com)
Great to see you writing again!
I wonder about the desirability of having as low an overlap as possible. I think the less overlap, the more the problem is "solved"? But if you assume you have low overlap, you won't look for nuances and improvement won't happen?
Feel like in the context of "Fuck around and find out," low wickedness means that there's nothing to find out so there's no point in fucking around. I guess whether this matters is up to what you're trying to do - if you're just trying to complete a task (exploit mode) you want low wickedness, but if you're in explore mode, you make the situation more wicked.
Also, I was thinking about Cedric's wicked and kind learning domains and how they relate to this concept.
https://commoncog.com/ill-structured-domains-not-wicked/