Re^3: The Boy Scout Rule

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.

Comment on Re^3: The Boy Scout Rule

Replies are listed 'Best First'.

Re^4: The Boy Scout Rule
by sundialsvc4 (Abbot) on Jan 30, 2015 at 12:42 UTC

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.”


Syntactic Confectionery Delight
	PerlMonks