I’ve mentioned the notion of “business-by-contracts” in several posts, but I have not detailed what that notion actually contains, in technical terms, so here goes, a brief description:
– as soon as you hear any of the words/acronyms “SLA”, “KPI”, “SRS”, “acceptance test” etc, chances are that you are dealing with business-by-contracts.
– system requirements are carefully solicited, analyzed, then frozen and documented, and they form the fundamental specification of the system’s overall behavior and characteristics.
– a business contract is then written, where the system requirements, together with other specifications such as acceptance testing criteria, and penalty clauses, form the “handshake” on what is to be delivered, to what cost, and by when the system (or service) is to be delivered.
– The system is typically developed by an organization that has little knowledge of, nor interest in the actual domain where the system eventually will be deployed, in other words, the developers of the system know next to nothing about the domain business needs, the client environment, the problems of that domain, the specific technical challenges in that domain, the scale of the client operations, nor about the way-of-working of the client organization and the intended end users of the product they are about to build. Even more importantly, the developers of the product will never ever use the product they are developing, themselves, not in any production setting.
– Very many real but opaque needs of the domain organization and its users will *not* be captured in the requirements gathering and analysis sessions, for several reasons, including that it is very difficult to communicate, understand and capture certain aspects of needs and functionality, much of such needs are often implicit and obvious for the client, but far from so for the contractor. Furthermore, in addition to being hard to identify, these implicit needs, should they also be formally captured in the reqspec, would also make the reqspec to grow exponentially, making it a nightmare to agree upon acceptance testing criteria.
– end user involvement in the project is very superficial and limited in time and effort.
Thus, the typical outcome of a product or project developed in a business-by-contracts model – unless the product is a simplistic commodity – is that it will be a long way from being satisfactory for the client and its intended users, despite meeting all the stated requirements, and even passing the acceptance tests.
In most cases, the product will always be seen as a “cludge” by its users, despite often years of post-delivery fixing and patching. The typical question from the contractor, when hearing all the complains on the recently deployed system, is: “but how can you say you are not satisfied, we’ve clearly implemented all the agreed upon requirements ?!?”
The fundamental problem with this approach to development is that it is primarily guided and controlled by purely financial goals (money/cost/time/effort/resource consumption etc), and developed by people with very limited knowledge and interest for the actual problem, and usage scenarios for the product intended to solve the problem. No matter how technically skilled the developers of the product are, unless they have deep insights into the problem domain, and the real – explicit and implicit – needs of the end users, the outcome of their work will be a cludge.
Have I seen such products in my professional domain…? Yes, way too many! Do I see such products on the consumer market…? Yes, but very rarely – consumer products tend to be much more solid in this aspect, even the most affordable of typical consumer product classes, e.g cars, cell phones, houses, kitchen sinks etc tend to work very well in their fundamental functionality, and even the quality of these low end consumer products tends to be “good enough”, eventhough not exactly thrilling… This is an interesting difference, and I might return at some point musing on why this is so….
Finally, an anecdote – albeit a trivial one – on how hard it can be to communicate requirements, even if the context, the problem and the solution all are trivial:
For a number of years ago, I hired some craftsmen to do some renovation work in my house. At a late state, I remembered that I for a long time had wanted to put an electric ventilation fan into the bathroom, so I asked the foreman of the craftsmen if they could do that. Sure, no problems, they would go and buy such a fan, and install it, it wouldn’t cost much, the operation as such was trivial.
When I return home on the evening when all the work in my house was finished, I went to the bathroom to check what kind of fan they had installed. Surprise! There was no fan to be found, so I called the foreman and asked why they hadn’t installed the fan, as agreed….
The answer was: “but surely we installed the fan, look carefully”.
I returned to the bathroom, still no fan, and then it struck me: I’ve better check out the laundry room downstairs… sure enough – there it was, the fan I had wanted installed in the bathroom upstairs…!
Moral of the story: communicating requirements is really difficult and error prone!