Actually, from a biological standpoint, that is just speculation. But, in any case, we are not talking about Nature at all: we are talking about a very, very human project.
And in my specific case, I am talking from a very long history of working with projects that failed, or that were about to and I managed to help claw them back.
The problem is that everything ... everything ... in a computer program of any size is functionally connected to everything else. (“Software is a Mechanism,” again ...) These dependencies exist, not only in the simple flow of information and control, but also in sequence and in time. Even if “responsibility” is segmented, the finished software is not. And, end-users and their specification documents can provide no useful information with regard to these, because these people do not know how to build software, nor how software is built or how it functions. We do.
Also, please: I am not standing on a podium or a soap-box here, and I am neither speaking in absolutes nor trying to. I look at a lot of “project failure-states,” and therefore get a pretty good idea of how they got there, but my goal and purpose is only: to get them out of that state. How, where, when, and why did the process fail? (Pick a language, pick a platform. Hell, for that matter, pick a methodology.)
Fairly consistently, I find that there has been a lack of appreciation for the de-stabilizing consequence of “change, itself.” Both on the part of the team, and on the part of management / owners. Very, very often, there was some sort of “surprise discovery,” and this resulted in deep, rippling, changes. (Imagine a sepulchral “gong” that just keeps reverberating down unknown cloistered halls at the Monastery ... Suddenly, one reverberation is accompanied by the ominous sound of a falling block of stone. Somewhere.) Very large chunks of the source-code could be seen in the change-control system (if they had one ...) as being changed at once, and there were a couple more commits to pick-up things that had been “missed.” Again, I am seeing these things mostly from what is by that time a forensic perspective.
In all cases, the projects were undertaken by professionals who never meant to fail at what they had set out to do. For a while, the project is flying high. Then, there’s a puff of smoke. A little ... puff of smoke. Nothing to be concerned about ... a puff ... of ... smoke.
|Replies are listed 'Best First'.|
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr (Friar) on Jul 22, 2015 at 01:18 UTC