Mon 2 Oct 2006
Frantically has been threatening for some time to comment on The Engineering Trade, I guess he’ll do this on his blog now. I am sure that he will provide some cogent arguments as to how this can be mitigated, I am equally sure he will be spot on in any analysis. I am also sure that although the consequences of the trade can be mitigated they cannot be removed. At least not entirely. At least, maybe, if one does not understand that this trade exists then it will bite you. Or something.
But here is what I think, things that can help mitigate the trade and things that cement the trade.
Specifications, handled incorrectly, lock the trade. Specifications are the API or SLA (maybe) between the users of the system and engineers who build the system. A quarter of a century ago (ouch) when at college we were taught that a specification formally models a system and that a system cannot ever be considered in isolation but forms part of and sits within an environment. When a system is delivered into an environment it inevitably alters that environment, forever. The specification could not take this into account - the specification no longer models correctly and is therefore false. A specification cannot ever predict the effects a system will have on an environment. The system that has been delivered is therefore wrong or at best imperfect.
But we know this, right? When I say handled incorrectly I mean that if the specification (the API) is nonporous - in other words if the specification is the only medium by which users talk to engineers (I discount business analysts here as for the purposes of this note they are translation devices and although essential any translation device is a lossy instrument).
I believe this has two effects (affects?) - firstly there is no trust between users and engineers and indeed this absence of trust is not even something that is noticed or deemed important until too late. Secondly, every specification comes with an expected delivery date. Because of the absence of trust and because we know that the specification is wrong and will be refined or changed or ignored toward the delivery date (and because delivery dates must not slip) then the engineering will be compromised to meet the date (fixing the engineering trade).
We can change this by blurring the distinction between users and engineers and by either removing the need for a fixed specification or accepting that the specification is mutable and be subject to (constant) change. The API between users and engineers must be at worst made porous and at best removed.
If one could do this then it becomes easier to understand how a specification could end up being true. As Keynes responded to an accusation of inconsistency:
When the facts change, I change my mind. What do you do, sir?
This quote should be stapled to every wall of every IT department. But if the specification is mutable how can it ever be satisfied? The first answer to this is that it never can be satisfied and one should give up trying. This is liberating, it is also scary, it will be shouted down by engineering classicists. It is also correct. What is key is to satisfy the specification enough. What is also key is that in delivering a system one should take smaller steps - not one big leap from no-system to system. Rather, smaller steps from no-system to some-system to some-more-system and …. essentially, ad infinitum.
I do not pretend to understand Agile, frantically and Tom do understand. What I do think I get is that this type of approach is central to Agile and Agile therefore understands a deal more about how systems are engineered and delivered than other more classical engineering models.
Finally, there is an interesting dichotomy here between engineering a system where APIs should be formal and nonporous and the design of a system where APIs must be porous and (to an extent) informal.
October 3rd, 2006 at 10:57 am
On the one hand this is a utopian ideal, leading to better systems, and should be applauded, on the other hand I suspect it’s almost impossible to achieve when “payment for delivery” is involved.
But then I may be baised: I’ve spent most of the last 10 years as a contractor. When involved in piece priced work, as opposed to time priced, the first thing you ask is “What do you want me to do?” and the second “How will we both know when I’m finished?” - starting a job without an answer to the second question invariably leads to hardship.
October 3rd, 2006 at 12:53 pm
I do not wish to get too deeply into Agile and how it works because I will quickly get way beyond my current knowledge but …. one of the key things with Agile is an exit condition for each iteration. So the users know what they are getting in the next release or iteration or story and this is explicit. So each step one takes is understood and subject to understanding and specification but the final destination is more vague.
Apologies to Agile colleague if this is nonsense or if the terms are misleading but I believe this is the general gist (jist?)
October 4th, 2006 at 10:04 pm
[...] Malcolm and I were having a chat over coffee recently, and, spurred by his recent posts and those of Tom and Tim, we meandered into discussing Agile. We didn’t discuss methodologies or tools or techniques or processes (OK, OK, I heard the catcalls and sighs of relief), what we focused on was Agile as a mindset. [...]