-
-
-
-
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
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
Intelligence is Intelligence, even if it’s Artificial
I had a stimulating conversation with the head of our GenAI practice, Suhail Khaki, a few weeks ago. Suhail made the remark that the more he works with GenAI, the more it strikes him that it’s less like conventional computer software, and more like a person in the way it interacts. He made the remark: … Continue reading What, How, and When in Software Development →
Learn More
Retail as a Conspiracy
I was one of the early buyers of the first release of Apple Vision Pro AR headset early this year. I got up at 5am my time to place an order on-line at the first moment when the device became available for pre-order. I then made an appointment at my local brick-and-mortar Apple Store to … Continue reading What, How, and When in Software Development →
Learn More
The “hype cycle” is about the hype—not the technology
The hype cycle has little to do with the merits of a particular technology. It simply has to do with the amount of publicity the technology has received. In particular, if the publicity jumps ahead of what the technology can immediately deliver, then the technology quickly gets labeled as “over hyped”. This is not the … Continue reading What, How, and When in Software Development →
Learn More
5 Trends & Takeaways from Google Cloud Next
Executives, decision-makers, technical experts, and Google Cloud partners converged at Google Cloud Next to explore cutting-edge innovations and industry trends. GlobalLogic was there, speaking about modernization strategy and delivering a Cube talk on Intelligently Engineering the Next Gen AI Platform we are building for Hitachi. Among the buzz at GCN 2024, using GenAI for customer … Continue reading What, How, and When in Software Development →
Learn More
Give yourself a promotion using GenAI
I think we’d all agree that getting promoted is desirable. Higher wages, better job title, greater impact, and perhaps more prestige. But it’s not without its problems. Like many engineers, I started out writing code. I was good at it, and customer demand increased for my services. I then started hiring other engineers and promoted … Continue reading What, How, and When in Software Development →
Learn More
Share this page:
-
-
-
-
URL copied!