Embedded Files
Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: 'Now, it's complete because it's ended here.
Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: 'Now, it's complete because it's ended here.
Frank Herbert "Dune"
Frank Herbert "Dune"
I'm sure you're all familiar with the picture that compares software development to building a tree swing. It's a great example of "funny because it's true," showing how, at each phase of the SDLC, the initial idea is misinterpreted, changed, and twisted—resulting in something completely different from the original concept.
I think one reason this comic strip is so popular is that anyone who has participated in any project can relate to at least one frame. Across the projects I've worked on, I could identify every single frame, and I'm sure I'm not the only one. This is why we have so many concepts, methodologies, and tools that aim to address these problems: Agile Development, Rapid Prototyping, Iterations, CI/CD pipelines, Direct Capture of Objectives, Retrospectives, Show & Tell Sessions, self-documenting code... Even listing them all would take longer than I intend to spend on this post.
Instead, let me address one issue I have with the picture. While I understand its comedic purpose, I can't stand that "What the customer really needed" is the last picture, not the first! That's the most important part and the one that, if not understood correctly, will lead to the most problems in all subsequent steps. You know that old catchphrase: "the client is always right"? Wrong! The very first picture shows the fallacy of such thinking. Michał Bartyzel wrote in one of his books, "Clients always know what they want [...] they do not always know what they need." That's the sentence I try to keep in mind whenever it's time to discuss something with the customer.
Distilling the real, underlying need helps us avoid misunderstandings further down the line. It allows us to separate the Must from the Could, Should, and Would (MoSCoW); it lets us define the Minimum Lovable Product, and protect against scope creep. In the best-case scenario, it can help us avoid all the pitfalls from the other pictures by simply removing the need for some functionalities. The rule that says the cost of fixing a bug rises exponentially the later it is discovered? The same goes for functionalities to be implemented—the functionalities that don't need to be implemented are the cheapest and fastest to deliver.
A few years ago, I was tasked with estimating and designing a plan to write a set of interfaces that would gather data from multiple devices in a client's network. Most of these devices already had connectivity options included in our product, but there was a lot of legacy equipment with hundreds of different APIs and connectivity options. The cost of implementation for these "odd ones" would be huge. Fortunately, after some inquiries, it turned out that most of them were being phased out—the client needed to track their status at a given point in time but had a replacement process already in motion. In the end, it turned out that a data migration was enough to meet those needs—preparing a single data import instead of multiple interfaces drastically cut the cost!
Consultant working in the Need Distillery
An even more interesting thing happened a few years later when I worked for another big customer. This time, instead of thousands of devices to reconcile, we dealt with thousands of processes to digitalize. For the first iteration, each team was given four processes to analyze, implement, and deliver. During the analysis of our four processes, it turned out that one of the processes consisted of following steps:
System X exports some data and puts it on FTP1 once a month
System Y exports some data and puts it on FTP2 once a month
Person A takes files from FTP1 and FTP2, consolidates the data in both xls files and sends a result to a dedicated SharePoint space
???
It turned out there was no "profit" step at the end of the above process—no one used the consolidated file! It was just laying on some server until it got archived away. We found a dead-end process that was no longer needed. The customer could save Person A from a pointless job and use their time more effectively. They saved implementation time and operational costs for this process, and we could mark 25% of our increment goal as "delivered"!
Of course, more often than not, the scenario is quite the opposite—we realise some necessary functionalities were not accounted for, some "simple" task transforms into algorithmic monstrosities, miscommunication happens, requirements are not refined enough, the team misunderstands intent, etc. That's why we still need all those different tools mentioned above. It's just worth remembering that sometimes less is more—and Distilling the Need gives us a chance to notice it.
Page updated
Google Sites
Report abuse