in reply to Interview Counterattack: "Show me a project-plan"

Interesting comments, Monks. I think that the general thrust of my comment was seen to be, as it was of course intended to be seen, as “somewhere in the middle of the usual two extremes.”

In way too many cases, computer software development devolves down to “we're making this thing up by the seat of our pants ("but of course it's gonna be great... no guts no glory..."). Dead soldiers had plenty of “glory”: it was the generals who screwed up.

No amount of dollars can pay you back for sitting in a hospital bed clinging to life after a heart attack, nor for walking into a divorce court with a man or a woman who's decided that you really do love your work most. (Neither one of which has ever happened to me, and this is why.)

And furthermore, these highly destructive work practices don't result in “better software.” I think they make our work-product much worse.

In my 25-odd years in this business, I've written a lot of great programs on paper. I've developed HTML prototypes using nothing more than a good text-editor, and thrown them away dozens of times in dozens of meetings. (That's what they were for...) I've written documents, and felt the same mental processes churning through my head that I've always felt when writing source. The idea took shape in my head and poured-out onto paper, and when sometimes-serious problems inevitably showed-up all I had to use was the “strikethrough” tool.

This is, I very-flatly assert, a distinctly better way. The software that results is much better. The work is completed faster because you land three-wheels-down on the correct runway and don't slide off the tarmac. Other workgroups complete their part of the task, in parallel to yours, because you've created an environment in which that sort of thing is possible.

Other “construction trades,” in fact all of them, routinely succeed in doing what the software development profession routinely fails to do. I think they're on to something. I think that when we run around bantering strategies with funky-but-upbeat sounding names like “agile” and “extreme,” all the while claiming that such things properly belong only to our storied ivory tower ... we're ... well ... we're just plain wrong. It's just not true. We're putting ourselves in harm's way by accepting it, and delivering inferior work. Literally, a “lose-lose situation.” I'm saying that what they're doing, and how they're successfully doing it, absolutely applies to us in every respect.

Replies are listed 'Best First'.
Re^2: Interview Counterattack: "Show me a project-plan"
by BrowserUk (Patriarch) on Apr 18, 2008 at 22:36 UTC
    In my 25-odd years in this business, I've written a lot of great programs on paper. I've developed HTML prototypes using nothing more than a good text-editor, and thrown them away dozens of times in dozens of meetings. (That's what they were for...) I've written documents, and felt the same mental processes churning through my head that I've always felt when writing source. The idea took shape in my head and poured-out onto paper, and when sometimes-serious problems inevitably showed-up all I had to use was the “strikethrough” tool.

    I learnt to do it that way too, 30 years ago. But then I realised that editing on screen is far more efficient that doing it on paper, so I gave up the paper. Then I discovered that prose was horribly misinterpetable. On paper I'd often used Wernier-Orr diagrams for bits of the design, but they were hard to draw and maintain, even in an editor, so I started using a form of pseudo-code; a hybrid of several I'd studied and various languages I'd used.

    After a while of that it dawned on me that if I actually used real code, instead of pseudo-code, I could mock-up the lower levels quite quickly and then get the lanaguage compiler or interpreter to verify what I'd written. It would point out inconsistancies, typos, mismatches in parameters. Stuff like that.

    And that led me to making the lower levels return mocked-up, but feasible return values. Then I could actually run the upper levels very early on. Demonstrate them, Test them. Show them to clients/stake holders.

    With a little more effort in adding a few sleeps or loops calculated to approximate the time taken by the as yet unwritten lower levels, I could even get a feel for what performance might be like. Measure it at a very early stage and track it as development went along. Show to the clients and get feedback on their impressions of whether it was good enough for their purposes.

    Often the first cut of the higher levels would show up some inconsistancy or other and I'd throw it away and start again in the knowledge of where it had gone wrong. Invariably, the second cut was better and came together more quickly than the first.

    After a few years they invented a name for this process. It's called RAD.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      After a few years they invented a name for this process. It's called RAD.

      Yeah, but would you build a building with it?

[reply]

        That's a wrong analogy. Would you DESIGN a building with it?!? Developing software is in no way like building a house (or bridge or whatever), on the other hand it is (in some regards) a lot like designing one. The reason why the misleading analogy of building something (which is, or rather should definitely be, mostly a mechanical application of the plans) comes in my opinion from the fact that most people have seen some buildings built, very few have seen them designed, sketches scratched, requirements changed by clients mid-way the project, the basic structures reworked due to problems found later in the project, ...

        Jenda
        Support Denmark!
        Defend the free world!

[reply]

        I certainly wouldn't. The task being spelled-out here is also pretty much one program being done by one person who is more-or-less fitting it together by feel. You can't scale-up that process, either to a bigger project or to more people. You can't start preparing the documentation team or the training team or the customer-support team “well in advance” because neither they nor the developer himself really know what the actual program is going to turn out to be until he mashes the "commit" button for what he decides to be the last time. What works in-the-small just does not work in-the-large. And if our brilliant-programmer has a bad driving-record or just bad luck, the project ceases to exist. That's how sleeping-bags wind up in cubicles.

Re^2: Interview Counterattack: "Show me a project-plan"
by chromatic (Archbishop) on Apr 18, 2008 at 21:58 UTC
    Other “construction trades,” in fact all of them, routinely succeed in doing what the software development profession routinely fails to do.

    By "all", of course, I assume you mean "none" -- otherwise I'd have to question whether you've ever actually seen anything ever constructed, let alone been in a building. I've worked construction myself, and I have a couple of friends who do HVAC design and sheet metal contracting. For every building ever built without a stack of change requests piling up the day after bid approval, I can show you a space shuttle software project at NASA (and there's only one of those).

    I think that when we run around bantering strategies with funky-but-upbeat sounding names like “agile” and “extreme,” all the while claiming that such things properly belong only to our storied ivory tower ... we're ... well ... we're just plain wrong.

    We call it software for a reason. Okay, Fred Brooks calls it "pure thought-stuff", but that's still at least somewhat different from the thirty story townhouse tower they built downtown here. You know, the kind where they have to dig a really big hole first, then sink pilings, and if they decide they need five more stories as they're hanging drywall inside, they're stuck thanks to the inexorable laws of physics and material science from their civil engineers. Meanwhile, we add a few lines of code and maybe another stick of memory.

    Is this not a fundamental difference?

[reply]

      Nope, it's not “a fundamental difference.”

        I'm very curious as to the kind of software you write where the tensile strength of a non-stable quicksort makes it impossible to iterate over user requirements.

        Alternately, if the difference between the physical and the virtual is not fundamental, what exactly is a fundamental difference, in your mind?

[reply]

In Section Meditations