“Mark has developed most of the solution.” That’s what they told me when I joined the company. It was the last century; I was young and all-knowing back then.
The software we were developing would read weight measurements from a precision digital scale connected to a PC. Then, each measurement will be tagged, stored and reported using a local database. The final setup would be installed on various labs.
Mark had given his notice; he was leaving the company. I was taking over his code. “It is all done,” he said confidently. He showed me around thousands of lines of code, it was nothing too complicated. Just the normal CRUD code (Create, Read, Update, Delete)
“Oh, by the way,” he added casually, ”the only thing left to finish are just the few lines of code to connect to the scale using the serial port.”
“Uh. Ok?” My instincts sensed danger.
“Do not worry about it,” he added noticing my concern, “there is sample code in the scale’s technical manual. It is only 3 lines of code—literally.”
As it turns out, the 3 lines of code worked beautifully. Every single time. But they were written in a language different than the language that Mark used to develop the other 99% of the application. We spent the next weeks trying to reproduce the manufacturer’s sample code in the new language, unsuccessfully.
At this point, the rest of the solution was demonstrated to the customer many times. He just could not understand what was the hold up around this last little detail. Embarrassingly, he even offered me the sample code in the manual. “It is easy,” the customer remarked, “only 3 lines of code.”
Eventually, we implemented a clumsy approach that worked most of the time. It was much slower than the sample code provided by the instrument manufacturer and it would fail from time to time.
Later in my career, reflecting on this episode, I realized that we were focusing on amount of work done and neglecting the remaining project risk. Something like this:
Measuring work and risk is important. The issue arises when we veer exclusively to views like the chart on the left.
On a side note, my experience is that the malady of measuring amount-of-work-output exclusively is found in devolved ‘agile-run’ teams. In these cases, the team has regressed to the exclusive incentive of showing progress in the form of stories or points completed. Meanwhile, technical debt, and conceptual debt grow unchecked.
METHOD TO DETER FALSE EXPECTATIONS OF PROGRESS
Patent not pending or forthcoming.
AXIOMS
A1 Every non-trivial project has at least one hard, hidden problem in it.
A2 The problem above is never explicitly stated in the project charter. Otherwise, it would not be hidden.
A3 A project with no hard, hidden problems is a trivial project.
PROPOSITION 1
Unless you find and solve the hard, hidden problems, your project will never finish.
Definition is important: In my example above, the problem was not to connect to the scale. But connecting to the scale using the technology selected to develop the application.
PROPOSITION 2
Also known as: “The notion of sufficient angst.”
Once you found a hard, hidden problem, it is enough to perform the minimal amount work to prove that the problem can be solved. There is no need to finish the whole darn thing to know that the problem can be tackled successfully.
Alternatively, you may decide that you will not solve the problem, by effectively declaring it not part of the project.
COROLLARY
An efficient way to execute a non-trivial project is to find a hard, hidden problem in it, and perform the minimal amount of work to prove that this problem can be solved.
Do this until the original project becomes a new, larger set of trivial projects.
If this resonates with you, then it is worth questioning the apparent progress of your current projects. Set some quiet time aside with pen and paper and perform some mental scouting for hard, hidden problems.
Hint: Run end-to-end scenarios in your head. Many hidden problems lurk in the boundaries between teams, workflows and organizations. Running your mental fingers over these boundaries will find holes, cracks, lumps and bumps ignored by each participating sub-system, as each sub-system on its own tends to be inward looking.
Or we could leave it alone and let it run its course, as hard hidden problems do not go hidden forever, as Mark demonstrated.