-
-
-
-
URL copied!
While any software development initiative has unique features, some situations recur so often that I feel like I should have a recording that I can play back the next time that same situation comes up. One of these is the “What,” “How,” and “When” of software development.
Projects get into trouble when it’s not clear who owns these critical decisions, and—perhaps more importantly—when the wrong person or function tries to own one or more of them. When the business people try to own the technical “how” of a project, you know you’re headed for trouble.
Similarly, when the technical people start designing end-user features (the “what”) without input from the users or the business, that often ends in disaster as well. And when either function tries to dictate “when” without regard to “what” or “how,” that spells trouble big-time.
Just the other day, I heard a business person say, “It’s obvious what they need to do—why can’t they just start coding?” Here the business person was saying, essentially, that the “what” is known (at least in their own mind), so the “how” should be obvious—meaning that engineering should just start doing it.
In such situations, unless the engineers are truly incompetent (rare), it’s very doubtful that the business person speaking actually understands either the “what” or the “how.” The engineers certainly do not, or they would indeed be coding.
Recommended reading: Software, the Last Handmade Thing
When a business person makes a statement like this, if he or she is in a position of sufficient power that the engineers do indeed “just start coding” even in the absence of clarity around the what or the how, the project rarely ends well. In particular, it rarely, if ever, delivers what the business person had in mind, when and how they wanted it.
And—you guessed it—it’s the engineers who generally get blamed for the failure, not the person who insisted they go ahead no matter what.
Projects work best when the business says “what,” the engineers say “how,” and the business and technical people negotiate jointly in good faith over “when.” Sometimes the “when” is fixed—for example, a trade show-driven launch date or an investor deadline. In that case, the business and technical people need to negotiate over the “what” and “how.”
Similarly, either the “how” or the “what” might be fixed—for example, because you are making modifications to an existing system and have limited technical options, or you have committed to deliver a certain feature. In this case, the “when” and the other of the three independent variables (either “what” or “how” respectively) need to be negotiable. Otherwise, a predictable failure—and/or development burnout—will occur.
Perhaps the most frequent issue is when a single person or function tries to own all three—the what, the how, and the when—telling engineering what they need to develop, how they are going to develop it, and when the project is to be delivered. Unless the person doing so is a universal genius—rare—this inevitably leads to problems.
I worked with Steve Jobs for four years at NeXT, and even he rarely tried to dictate all three. Two out of three he would try for—but rarely, if ever, all three (and then not for long). Steve would generally defer to engineering on the “how” and would often (though sometimes grudgingly) accommodate strong pushback on the “when.” While I’ve never worked with Elon Musk, I get the sense he also listens to a core team of engineers he trusts. Unless you consider yourself smarter than Steve Jobs and Mr. Musk, you should pause to reconsider your own actions when you try to dictate what, how, and when to your engineering team.
Another often-overlooked facet of this puzzle is the fact that all three activities require communication. Even if the “what” seems clear in your own mind, it still needs to be expressed in terms that the engineering team can understand. This process of ‘backlog elaboration’ nearly always reveals gaps in the clarity of the initial vision, even if it might have seemed ‘obvious’ to you. Similarly, the ‘how’ may be clear to your technical leads, but it still needs to be expressed in architecture diagrams, sequence diagrams, API specs, and other artifacts that communicate the technical vision to the engineering team.
Only when the “what” and “how” are expressed in sufficient detail can a reliable “when” be produced. The fact that the “what” is clear in our business person’s mind, or the “how” is clear in the mind of the architect, does not mean that the person’s vision could be successfully operationalized without further work. This is why “just start coding” reveals a real gap in understanding of how successful software projects are implemented.
All this can be really fast—even verbally and at the whiteboard in some cases. But in general, the more input and understanding you get from the people actually doing the work, the better your backlog and the more accurate your timeline will be.
A proper appreciation for the value of each ingredient (“what,” “how,” and “when”), combined with due respect for the roles of their proper owners, is the key recipe for successful software development.
More helpful resources:
Trending Insights
If You Build Products, You Should Be Using...
Digital TransformationTesting and QAManufacturing and IndustrialEmpowering Teams with Agile Product-Oriented Delivery, Step By...
AgileProject ManagementAutomotiveCommunicationsConsumer and RetailMediaLet’s Work Together
Related Content
Crowd-Striked: Lessons Learned and Best Practices for Future Prevention
Incident Summary On July 19, 2024, CrowdStrike released a content configuration update for the Windows sensor that resulted in widespread system instability, causing Windows systems to experience the "Blue Screen of Death" (BSOD). The issue was traced to a channel file named “C-00000291*.sys” included in the update, which caused system crashes upon deployment. “Channel files” … Continue reading What, How, and When in Software Development →
Learn More
IIoT: The Future of Manufacturing
Evolution of Industrial Innovation: How IIoT Will Impact Manufacturing in the Future? The Manufacturing Industry is entering a new era thanks to the Industrial Internet of Things, or IIoT. This revolutionary technology is dramatically reinventing manufacturing with the integration of digital technology into processes that enhance output quality, reduce costs, and increase productivity. IIoT … Continue reading What, How, and When in Software Development →
Learn More
Generations and GenAI
This is probably a well-known fact in sociology or some other such discipline, but it struck me the other day that only the generation that knows how to do something can be the one to make that thing obsolete. Take driving a car, for example. My generation and the ones preceding me in the U.S. … Continue reading What, How, and When in Software Development →
Learn More
We’re getting the chance to live in the future
Early 20th Century motivational speaker and author Dale Carnegie once wrote “Today is the tomorrow you worried about yesterday.” I believe that Mr. Carnegie’s point was that unless today is the literally the worst day of your life (and my sincere sympathies if it is), then the energy you spent worrying about it yesterday was largely wasted. I haven’t read much … Continue reading What, How, and When in Software Development →
Learn More
Share this page:
-
-
-
-
URL copied!