|P is for Practical|
Re^2: The Boy Scout Ruleby sundialsvc4 (Abbot)
|on Jan 27, 2015 at 15:37 UTC||Need Help??|
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.)
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.)