Ends are not bad and many ends aren’t really an ending; some things are never-ending.
— C. JoyBell C.
In my previous posts, I presented a flow model to help understand the “Order of Operations” for diagnosing and fixing Engineering projects. As well, I presented the concept of the Customer Membrane and asserted that anything that doesn’t pass across this is generally not important. To allow a better understanding of the proposed model, let’s look at a few examples software projects that went sideways. Most are loosely based on my own experiences, with names, places and details changed to protect the innocent [1].
The Never-ending Story [2]
Most of you are familiar with a project that starts with good intentions but later thrashes on forever, never getting to completion, but never fully dying. It’s the project equivalent of a zombie – destroying everything in its path and consuming a lot of perfectly good brains.
Let’s focus the camera on the story as it unfolds: the Engineering team has been asked to build an exciting new customer-facing application to streamline the online ordering process – this will revolutionize the industry and bring a valuable amount of market share to the company. After consultation with some ambitious and optimistic [3] Engineers and Architects, the Engineering Manager confidently announces that it should be done within six months, well in advance of the annual holiday rush (a key factor in past market share swings). However, after three months of work, the team estimates the remaining effort at another six months, which is cutting it close to the holidays. Another three months pass (which – ironically – is the original completion date) and as the team better understands the work required [4], it appears that it will take at least another year to complete. In truth, nobody really knows when it will be done. Worse yet, there is very little to show for what has been done to date – nothing is actually working or demonstrable.
When we put a microscope on the project, we might see something like this: at the start of the project, the Engineering group needed to decide on a User Interface (UI) framework to build the customer-facing part of the application. The company has an existing framework, but the Engineers weren’t very excited about using it yet again. There was an internal debate on two new options, both popular open-source frameworks: React and AngularJS. After weeks of analysis and debate, the teams decided that neither framework could do what was needed (even though their application was really no different from thousands of other successful and much larger applications using one of those two), so they decided to build their own.
The work was so fascinating to the Engineers that they didn’t even notice the sound of the deadlines whooshing by. Because they were using Scrum, they only focused on the immediate work and never worried too much about the longer term. When confronted with outlining the work remaining on the UI framework, the team realized that there was an almost infinite effort to complete it. Who knew that creating a framework was so hard? [5] So they went back to the drawing board and rebooted the project using AngularJS, since another team in the company had some success with that. After a few months of using AngularJS, they decided that they didn’t like its limitations and flip-flopped over to React as their new foundation. And so began the third rewrite of the entire application. Now they just needed to decide how to store the user data…
What went wrong?
In this project, the team got sidetracked building an unnecessary framework and never got the project done (or even to a state where anything could be demonstrated). Why did this disaster happen? The customer wanted a great new online ordering experience and had zero interest in whether the application was written in AngularJS, React or even COBOL [6]. Assuming that the end users were focused on getting a specific capability and not a very specific user experience, the Engineering team likely had a tremendous flexibility in the actual UI. There was no need to sweat over which framework to use and definitely no need (ever) to build a homegrown UI framework. The Engineers thought it would be a really cool project to build and justified it (possibly even subconsciously) by highlighting requirements that couldn’t be met.
In the terminology of the Flow model, the Engineers were focusing primarily on items that are 5th or 6th in the Order of Operations without nailing any of the first two or three.
In fairness, we don’t know that the team was oblivious to all the Customer’s requirements, but we know they didn’t meet the most important one: to create a great new ordering application by the holiday season to capture valuable market share.
In the context of the Customer Membrane, we can see that the UI framework used is not obvious in the interface between the Customer and the Development team. The end result of the UI framework (i.e., the application’s user interface) is visible, but the Customer has no idea (or concern, as a rule) about what is behind the scenes. As the diagram shows, those frameworks are on the wrong side of the Customer Membrane:
With this mystery solved, I’ll continue to look at more examples in the next post. Please comment below if you have a similar experience to share.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] (or guilty)
[2] pun intended (both with the movie title and the Scrum term reference)
[3] or possibly naïve
[4] or so they say
[5] Actually, anyone who has actually tried to create a framework
[6] Assuming that COBOL has evolved to create web applications, which I have not verified [7].
[7] If pressed, I will deny that I know what “ENVIRONMENT DIVISION.” or “PIC X(9)” mean.
Leave a Reply