Re: Software Projects In Real Life: "I See Dead People"

[sundialsvc4]

A very thoughtful reply, mr_mischief.   Thank you.

A serious “fly in this ointment” is that the “features” of which one is speaking:   (a) are only the parts of the iceberg which are above the ocean, and (b) are tacitly assumed to be independent.   Therefore, the development team, without (as they(!!) say ...) “over-”specifying anything, pursues these highly-visible features one by one, but without proper regard to the whole.   The resulting work-product is too-often extremely brittle, becoming unserviceable in a comparatively short amount of time.   Words like “potentially,” used in the context of words like “useful” or “releaseable,” are, ahhh, “highly overrated.™”

Again, the “self-directing machine” analogy.   A hopelessly-coupled contraption of highly interwoven parts.   Almost nothing is truly independent, in the general case.   The experienced business-analysts who look for such things might be the bearers of inconvenient truth, especially if they are themselves experienced developers.   (As you may have guessed, I play that role frequently.)

And I speak, frankly, from the point-of-view of the coroner, or the emergency-room triage nurse.   Projects that have been “scrummed until they have to be scrubbed” are usually where I come into the scene.   This influences my thinking, and prompts this Meditation, but of course is not intended to be a straw man.   We all understand, I think, that I am pointing to something without attempting to gather all of reality into what I am pointing to.

There is a germ of truth, of course.   There is such a thing as analysis paralysis, but there’s generally a much bigger thing known as “going off half-cocked.”   I agree that the project should be redlined in definite stages and that those stages should be as succinct as possible, but equal attention must be paid both to the parts above the water and to the vastness that is below.   If you let them, business stakeholders who really do not understand the process of building a software machine will seek to manage and micro-manage the activities.   (Not entirely wrong, because they’re the ones paying for it, as well as the ones who will be most-invested in the result.)

Perhaps my most serious beef with “scrum,” and with most of these methodologies (to be frank), is that they both set and encourage perceptions among stakeholders that the process itself really can’t consistently meet.   This observation comes directly from my self-appointed role; from the dead or near-dead bodies that I see.   One of the first things that I find that I have to do is to (re-)build trust, not only in myself but in the whole damn software-development process!  When “trust” has been shattered, you really can’t get it back.   Sometimes the project can be turned around.   Sometimes the only realistic path is a slightly-softer and less-catastrophic crash landing.   In either case, the damage has already been done ... even though the teams consisted of professionals and no one knowingly acted in bad faith.

[mr_mischief]

without proper regard to the whole

is a terrible strawman. If you have developers disregarding the whole and integrating things poorly, they are bad developers. It's not caused by developing small, modular pieces.

[eyepopslikeamosquito]

A very thoughtful reply, mr_mischief. Thank you.

Yet again, you've replied to yourself, not the person you intended. At least this time, you didn't insult yourself. :)