Plato, Aristotle, Dirty Harry, and the benefits of prototyping

I remember strongly disliking my philosophy classes for their absolute irrelevance to everyday life. It took me 20 years to only start comprehending the infinite wisdom hiding in the murky writings of these predominantly old bald white males.

Take Apophatic theology in its simplistic form – defining God by what God is not. Plato postulated that certain things have to be negated or discarded in the “pursuit of Truth, Beauty and Goodness.” Sounds very much like a software development project where we have to forcefully abandon bad practices if we ever want to have it successfully completed.

The same Plato described ideal world where every “Done” is perfectly understood, “Capabilities” are well-defined, and the eventual product – an F-35 – is a perfect plane. All earthly composite-made planes are only imperfect projections of that plane – and they do not really exist. Then, Aristotle came in and argued that all these earthly F-35s and all the earthly software projects actually do exist, along with their respective cans of worms.

I can probably agree with a number of 20th century philosophers that everything you see around is all Aristotle’s fault. Here is an example.

On a busy Monday afternoon you receive an RFP. The prospect expects the proposal to cover the entire project scope based on these requirements.

The problem is in the perpetual fog of war. Even with the best-formed requirements it is not always possible to see contradictions without actual, active and continuous prototyping. Somehow similar to the military concept of armed reconnaissance.

The world is full of stories about IT projects failures of varying proportions – from a complete disaster to very significant shifts in scope, budgets and timelines.

The Agile revolution made things somehow more complicated. Agile is easy to get started, but difficult to truly master, just like philosophy. In the Agile method, solid project vision is key along with a strong business product owner. From there, you outline reachable short-term goals and let the project develop organically. Interestingly, Agile, SCRUM and similar concepts were used successfully in the US defense domain for decades for extremely mission-critical projects – without too much ado.

When the Agile movement too often goes astray is when people take the easy path and jump into development with little requirements, expecting to fail often and somehow figure it out later. Most Agile efforts falter because they are missing a clear vision and competent business owners to guide the team in the right direction. This key philosophical point is difficult to get through to managers with deadlines and schedules.

Switching from the Greek philosophers to my personal modern project management guru Glen Alleman:

• Without a clear and concise description of Done in units of measure meaningful to the decision makers (Effectiveness and Performance), it’s hard to know how to reach Done, how much it will cost to reach Done, and when we will be arriving at Done.
• Once we know “Done”, we can then line up the Capabilities, which in turn will determine the route, deliverables, costs and measures of progress.

In best case scenario, requirements arrive in good shape and are even described in SysML. But SysML describes the process, while SysML simulation validates the process but does not validate the visual side. In other words, a big part of the picture is still missing. Even the best people visualize the actual endgame using their personal (magic word!) biased worldview. Ten team members reading the same requirements documentation or SysML chart will have ten slightly different visual interpretations of the system.

That’s why in order to turn an abstract idea from requirements into a somewhat realistic view, it is absolutely necessary to make a prototype that accomplishes small but critical features contributing to the overall goal. This brings the abstract expectations from all stakeholders into clash with each other and eventual alignment – at a small fraction of the cost for the whole project at this initial stage.

Another value of building a rough prototype is technology validation. Certain choices made in good faith to satisfy the requirements may be wrong, and it is better to find such structural defects as early as possible. Running a computation-intensive algorithm on a mobile device causes that device to overheat and shutdown. But there may be no way to uncover these limitations without at least a minimal app running a simple version of the algorithm on that type of device.

Prototyping is key, and someone has to pay for it. Without a prototype to truly visualize “Done” to everyone involved, someone is always tossing the coin. This mostly concerns fixed-price projects with vendors either being forced to double or triple their original estimates or take overwhelming risks, but Time and Material are not immune either: they simply turn the table of financial responsibility to the customer, who at some stage may become enormously upset.

Once you set up a prototype as a separately billed project, you have all the feedback and all the concerns and all misunderstanding laying bare on the table pretty quickly. Various internal customer interests are aligned, you finally understand what they want – and they understand far better what you are planning to do and how you will do it.

There is no longer a need to feel lucky, you can go ahead, make the right time and money estimates – and make everyone’s day. May the force (and Dirty Harry) be with you!