Re^2: The Boy Scout Rule

[sundialsvc4]

This is usually the status quo that I initially walk into.   The first, and perhaps the most difficult, step is to persuade management to treat a software project exactly as they would treat “the building of an automatic machine.”

Computer software is, in fact, an automaton.   Acting only and completely on the yes/no instructions of which it consists, the machine is expected to correctly perform (or, correctly and meaningfully decline to perform) a real-world business process for a business consisting of humans.   If the software code-base here really is as you describe it to be, the root cause of the problem lies in [the lack of] software project management.   The code was “untested,” yet it was released and is in service.   There is no such thing as “technical debt,” but the business cost of software failure – or even, inadequacy – is more than “measured in cash.”   If the organization does not fundamentally change its approach to software building, then any “rewrite everything in” successor will merely suffer the same fate.

Usually, the root cause of the problems do not lie in the day-to-day activities of the code writers.   The problem is upstream of this, in the business itself.   But this is partly a social consequence of the very attitude that Joel’s article (Joel knows his audience ...) speaks to:   that the software developer’s job is to take “business requirements” and to “write code” for it, and that those requirements ... a wish-list, really ... can, in fact, be changed arbitrarily without harm or consequence.   Strangely, no one thinks that way when designing buildings or physical machinery.   Yet, computer software is a machine with more degrees-of-freedom and loose-motion than any physical artifice could ever have.

If you find yourself speaking to “CVS vs. git,” then this is probably a symptom of “lack of version control and/or of release discipline.”   If you are even discussing the importance of code-review and testing, it’s a symptom that these things are not burned-into the organizations process culture.   Basically, that there is no process culture.   A dire situation like this one must be simultaneously addressed at multiple levels:   (Okay, a taste of what I do for a living ... tough love.)

1. Triage:   Stop the bleeding.   Get control of business blood-pressure, even if you must amputate a limb of the existing app/web-site (temporarily ... or not ...) in order to stabilize what’s left.   Stop all “future development,” because it will not matter in the end if a corpse [failed business ...] has yet-another half-grown arm in its [defunct ...] web site.
2. Eliminate “self-serving software excuses for” actual project management:   Out with the Scrum, the Agile, the euphemisms like “technical debt.”   “Everyone, please sit down.”   No amount of quibbling about exactly how a group of software-writers spends their work day will, in the end, make the slightest bit of difference, as long as the teams are being asked to perform a series of tasks that are not rigorously defined before being presented to them, having first gone through an analysis & planning stage which translates business requirements into modifications to a now-moving machine otherwise known as “the application.”   Yellow sticky-notes don’t solve anything, and focusing on such things is merely indicative of the root problem.   Carpenters and masons and electricians do not have discretion.
3. Get to “Big-D Done,” then “Move From Done to Done”:  
   1 = It Works, completely, perfectly, and in all cases.   0 = It Doesn’t.
   “Yeah, it sucks to be binary,” but a digital computer is.   The software machine consists of millions of freely-interacting moving parts, all of which are “either Yes or No.”   “Either Done or Not-Done.”   “Proved to be Correct, and to stay Correct in all cases.   Or, not.”   You can’t talk about “technical debt” because functionality is either in the product or it’s not, and the cost of any change is the same in terms of its risk to product stability.   You didn’t “incur a debt to be paid-back later.”   You didn’t do it.   And even if you did, it’s most likely not Done.™

I could continue, but I’d have to charge you.   ;-)   Basically, software development fails consistently because the work actually consists of building an automated, moving, piece of machinery but nobody approaches the task in that way.   Programmers focus on how they arrange their tool-boxes, what they wear to work, and where they stand at 10:00.   Business owners stand at a distance, staring at metrics but without knowledge of the process.   Incomplete requirements are handed down because those that supply them don’t know what is required.   Changes are handed down ... but without a change-order process ... because neither party understands the cost and risk of “any change at all.”   And the software machine chugs along, full of broken parts, incomplete behavior, and badly-dented covers (emitting foul smoke) which haven’t been opened in years.

The business failure, though, is not a failure of computer technology, nor of the language(s) that are used.   The business failure is ... well ... a business process failure.   But it is also a failure to recognize that the singular ruling constraint of this kind of project – altogether different from any other type of project – is the software machine.   At the end of the day, no one is there but the machine and its user.   The programmers, the managers, the testers, no one has any direct influence on what the machine does.   No other type of project that has ever been “managed” has that characteristic, and “that characteristic” trumps all other concerns.   It is the Nature of The Beast.

(You can find it on Kindle (Amazon) now; soon to be on Apple platforms too:   Managing the Mechanism, by Vincent P. North.)

[Your Mother]

If you find yourself speaking to “CVS vs. git,” then this is probably a symptom of “lack of version control and/or of release discipline.”

That is ludicrous. There are literally CVS operations that can take an hour which take 10 seconds in git. CVS is the IE of RCSes.

I could continue, but I’d have to charge you.

I suspect consumer protection law would be in play at that point.

[RonW]

Software does get treated differently. The perception being that is is "soft", therefore malleable.

Our requirements group prepares requirements for 3 groups: Mechanical, Electrical and Software. They are familiar with and use the processes required for mechanical and electrical specifications. But when we (the software group) ask them to follow the same processes they follow for mechanical and electrical, they claim that those processes are too slow so they would not be able to deliver specifications to us in time. So they would need to issue preliminary specifications to us - but that would be extra work, so better to keep using the current processes.

Then, the upper level managers state that the business case for using software at all is the flexibility software allows and the speed it can be developed. Therefore, if we follow processes oriented for creating hardware, we negate the business case for using software.

Of course, when we get incomplete/ambiguous/self-contradictory specifications, we still get blamed for not delivering what was wanted. And when we do ask for clarifications, we get blamed for the delays introduced by the need to respond to our questions.

So why do software developers keep developing software?

At least for my team, most of the time we have fun making our software make electro-mechanical "contraptions" do things.

[sundialsvc4]

Ron, you definitely should be telling everyone in the company who will listen to you that specification and planning is actually far more important for Software than for Plumbing and/or Electrical ... and that Software, in fact, is not one whit more “malleable.”

If you describe the thing that you are building in terms of it being nothing less than a self-directing machine, composed of millions of mutually-interdependent and interacting parts, and that nothing ever happens except as the consequence of a binary yes/no decision with no possibility of direct human influence ... then you will accomplish the mental gear-shifting that, it seems, someone at your company at one time tried to do when they specified the same formal planning and design process for Software as for Plumbing and Electrical.

It’s easy to see the need for discipline in these other trades, because you can see them with your eyes.   You’d instantly reject the “stand-up comedy routine” if you saw that even a stationary thing, like an electrical layout or a plumbing grid, were being constructed, because you’d see and intuit the folly of such an undisciplined approach.   (Not to mention it would not be legal, and you would lose your license to do the work ... a concept of which the Software industry still has no parallels, yet.)   Not a soul goes to a workplace without a sheaf of blueprints, all bearing that vital license-stamp, and no one does anything but follow it.   The projects happen, routinely and safely, because of that.

Ron, someone at your company was definitely on to something very important when s/he created that original idea of formally planning Software as with everything else.   That way of thinking should be frankly encouraged.   Computer software is very much like Laws and Sausages:   people encounter it every day without really understanding how it gets made and what strictures apply to it.   And so, they treat it “differently,” and more casually.   Fact is, since software is a machine, and one that runs autonomously, it requires more planning and more discipline than almost anything else . . . yet, rarely receives it.   “Aye, there’s the rub.”