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

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: Interview Counterattack: "Show me a project-plan"

Replies are listed 'Best First'.
Re^3: Interview Counterattack: "Show me a project-plan"
by chromatic (Archbishop) on Apr 18, 2008 at 22:42 UTC
    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]
        That's a wrong analogy.

        I agree completely. The source code is the only full and complete design of the software. Everything after that point is manufacturing.

[reply]
[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.

        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.

        What utter rubbish. The top level "program" might be might be a single standalone application. Or it might be the home page of a new website. Or the first subpage in a sub-application. Whatever the form of the application, there is a top level, that structured programming suggests, is itself relatively simple, but which dictates considerable influence over the structure and interfaces of the next level of components.

        Once that level has been laid out, excercised, demonstrated and approved--usually a matter of hours or days--a team of any size required can start working on the internals of the next layer deeper, as their interfaces with the top level have been defined. And the documentation people can start documenting the top level straight away, in parallel. This isolation of concerns reduces coupling (the Holy Grail), between the lower levels and allows the teams to operate free from co-dependancies upon each other.

        The process works just as well for a team of 720 people as it does for one, because the interfaces between each subgroup are clearly defined. Even when those interfaces need to change, whether through customer requirements altering from above, or implementation requirements from below, the changes and negotiations they require are isolated to one vertical path through the development, not scattered throughout the project. Meetings are smaller, decisions are quicker, parallel paths continue unaffected.

        The hierachal breakdown of projects into sub-projects falls out naturally from the design process, rather than being artificially imposed from on-high by capricious whim. At the end of each day, each sub-project has a working program. The top level works, because each of it's dependants are mocked up. Each of the sub-groups substitute their part for its mockup in a copy, and can develop and test independant of each other.

        Only once they are happy with their testing does their part get integrated back into the top level. And if it breaks, the top level reverts to using the mockup, allowing it to continue to test other interfaces as they become available, until it doesn't. At any given point in time, each group can continue to develop and test their part in isolation of others, because the interfaces are clear, and have been mocked up early.

        Catastrophic failures--through code failures, death, holidays, staff changes, server failures, whatever--are isolated to just the affected sub-project and so do not bring the entire project to a halt as with set-in-stone development plans.

        Regardless of whether you use an OO, procedural, or functional design philosophy, or which languages you use, the decoupling of dependancies through interface isolation, is the key to project control and management. RAD allows projects to move forward faster and respond to requirements changes earlier and more easily.

        The idea that requirements can be gathered completely up-front, signed off and never change belies the realities of modern life. The last really big project I architected had to change track in late mid-stream for purely political reasons. An election brought about a change in flavour of government, and the project leader was called in front of a standing committee to explain why there was so little regional involvement in the project. The hierachal RAD development philosophy allowed the project to respond to the changes mandated by parliament with minimal delays to the overall project timelines.

        I cannot imagine re-carving the stone tablets of a waterfall development project plan, in similar circumstances, without it having a huge impact on timelines and costs.

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

        We either do things the Sundial Way (the big thud of specifications gathered meticulously up front, and by gum, if the users aren't happy at the end of the process, that'll teach those pinheads to take requirements gathering seriously next time, I mean it), or we're heroic cowboys pulling all-nighters because we couldn't possibly get anything right if we didn't strap our poor hapless users in dental chairs and pull future predictions out of their mouths.

        Strawman much?

        I realize anecdote is not the singular of data, but I'm not the only person around here who's used agile development to deliver software that delighted our (yes, it scaled to a whole team) customers. Now either we're all liars, or you're wrong that it doesn't work.

[reply]
        That's how sleeping-bags wind up in cubicles.

        Just to clarify, the sleeping bag wound up in my cubicle because the company was so wildly successful that it could not hire people fast enough to keep up with its crazy growth and I enjoyed stepping up. Like samizdat and I mentioned, having to sleep at work can sometimes be an indication of an environment where personal achievement is possible and going from trainee to manager in 2 years is a path open for those willing to camp through a crisis.

        I do totally agree however that organizations that end up in emergency mode perpetually are in trouble and not a good place to be if they don't solve for it in a timely fashion.

[reply]

In Section Meditations