The best question asked this week: What, exactly, are you trying to prove?
Reg, nailing it as usual.
Hey, I am not blaming customers. They don’t know what they want because nobody really knows what the optimum finished software looks like before development begins. Not the Customer, not the Developers, and not even the “Architects,” “Product Managers,” “Business Analysts” or anybody else who think they are a requirements expert.
Software development is a process of discovery, for the customer, for management, and for development. As information is acquired—through inquiry, inspection, or experience gained from misadventure—our understanding of what we are trying to accomplish is refined. In that respect, every tool, be it a programming language, a development process, or a testing practice, must be judged for its contribution to the transformation of both the requirements and the software over time.
Yes. And that’s why processes designed around a priori assumptions about either the nature of the so-called “software development lifecycle”, or the knowability of scope, will probably never cease to make our lives miserable and fail to achieve their stated goals. The analogy to “building a bridge” (or a skyscraper, or whatever) — perhaps even the overall analogy linking the creation of software to engineering — seems flawed. The physical laws of the universe constrain a customer, requesting the design and construction of a physical object, from changing their mind about the scope very often, and they can almost never make fundamental changes (“Oh, but we want the skyscraper to have 20 more floors”) downstream. The physical laws of the universe get in the way. Software is thoughtstuff. Those same physical laws do not apply (at least not in the same way or to the same degree). Customers can, and do, change their minds on a near constant basis, including changes in the fundamental nature of the thing under construction. They get away with this because they can, and they know it. Many of the “process” ideas that have grown up to support the idea of “software engineering” can be seen, from this perspective, as attempts to constrain the design and construction of software in such a way that the situation becomes analogous to that of physical objects.
Are we supposed to be surprised that customers resist this? Whether they’ve bought into the software engineering analogy or not, they will still strive fiercely — almost instinctively — to exercise all options open to them to change their minds.
Can we make “the process of discovery” that Reg describes “rigorous”? Can we make software in such a way that we’re not simply making it up as we go along? Perhaps. But no process that fails to acknowledge the core aspects of its steps and participants can ever really be successful. Thus, it behooves us to find a way to make the malleability of software and the unknowability of scope (a priori) first class artifacts in our processes.
“Agile” has balkanized, and the individual cults have — in some cases — become religions that are just as bad as the things they intended to replace. But at the outset, the interesting thing about “agile” (the only interesting thing about it, in my opinion) was that it was an attempt to acknowledge this reality, to address it explicitly, to deal with it. That was a good idea. We should keep striving away at it.
