Re^2: OpEd: Programming is not Team Sports

[sundialsvc4]

I think that this is precisely the thing that silver-bullets like Agile et al apologize for:   “you realize that you’re building the house on-the-fly, just like you’ve always done, therefore, just keep doing it.   After all, you wind up with a visible structure that much sooner ...

After all, software development is so different from anything else that we have done throughout all of human history, “it must play by different rules.”

After all, users really won’t mind if the project is “a little late,” because they can plainly see that we are hammering nails and cutting boards as fast as we are able.

(thin smile...)   If only it were actually “a little.”

I have consistently found that, if you plan the project as thoroughly and as meticulously as you actually need to, the actual construction of the thing is, as I said, “virtually an afterthought.” It also enables you to say, and not only to say but to say consistently:   “deployed on time, deployed on budget, zero defects.”

z - e - r - o .

You know, there is really nothing complicated about writing, say, “Perl code that works.”   Writing the stuff is actually not complicated at all.   Building a test suite is also not very complicated if you are building it from a pre-arranged laundry list.   No, I submit for the consideration of the Monks that the reason why software projects so consistently overrun, in every possible way and at sometimes awful cost, is that we are making the stuff up as we go along, and we are making excuses for shoddy (non-)engineering practices that would never pass muster in any other engineering discipline.   Computer software is punishingly intolerant of this, because it is composed of thousands of moving parts.   And yet, we do it, and we insist that we must.

[chromatic]

If you redefine "programming" to be "the mere act of typing", then it's easy to "program" on time and under budget.

If you always have customers who know exactly what they want before you type a line of code and they never change their minds or ask you for anything else and they're happy when you never let them, you're the first programmer I've ever talked to with those characteristics.

Change happens.

[aaron_baugher]

I have consistently found that, if you plan the project as thoroughly and as meticulously as you actually need to, the actual construction of the thing is, as I said, “virtually an afterthought.” It also enables you to say, and not only to say but to say consistently: “deployed on time, deployed on budget, zero defects.”

I have consistently found that the above paragraph is nonsense.

Now, when a task is small enough that I can plan the entire thing out in my head before I write a line of code, then yes, I can predict pretty accurately how long it will take and cost. But that's because, as someone said elsewhere in this thread, "planning" in the context of programming IS coding to a significant extent. If you're planning and thinking about the program in terms of code and algorithms, then once you have it all "planned," you already have it coded, except for the tedious typing. Of course you can provide solid deadlines and cost estimates then -- the real work is done.

But that just redefines programming as planning, in my opinion. How about if you're writing pseudo-code? Is that planning or programming? What's the difference? What if, instead of writing pseudo-code and flowcharts, I go ahead and start writing real code, tweaking it as my "plan" evolves? How do I tell when I'm planning and when I'm coding? Maybe you can plan a program fully without thinking through the required code (and database tables and so on), but I can't. I don't even know what that would mean.

Look at it this way: instead of comparing building a program to building a house in real life, compare it to building a house in a CAD package (apples to apples). You could plan the house out on paper, with lots of notes and hand drawings about what you want until you have complete blueprints, and then use the tools in the CAD package to "build" the actual 3D house, considering that a separate step from the planning. Or you could just start up your CAD package, load a basic template that has some algorithms you commonly use (walls, floors, roof), and then start adjusting and tweaking until you have the house you want. Odds are you'd do a combination of the two: maybe a couple quick sketches on paper to get the basic look in your head, and then start "building," working out most of the details during the building stage.

You condescendingly imply that we're being ridiculous when we say programming is different from "other engineering disciplines," but the fact is that programming is NOT engineering, at least not in the full sense of the discipline. Building ideas from smaller ideas is different from building objects from smaller objects, like it or not. It presents different pros and cons, and the fact that "planning" and "building" can be intermingled in a way that they can't be in brick-and-mortar projects is both pro and con. You can't get away from that con, so you might as well take advantage of the pro.