On methodology, hiring, waterfalls, and sandcastles

One of the things I’m struggling with right now is to express a few thoughts which have been milling around in my head regarding lightweight and effective strategies and approaches for small business / projects. When I say “small business” what I really mean is the New Zealand version of small business – REALLY small business.

The following links are all related to this thinking – thinking which will hopefully surface eventually in some meaningful way (when actual work isn’t quite as hectic).

Case Study: Rapid iteration with hardware – the whole site is an interesting read, however the relevance of that one post to my line of thinking is a series of segues. The post shows the usefulness of an agile vs. waterfall approach in many situations when it’s done right. In software development, release early and often is a great way to go (even if you’re releasing prototype/demo software and not the real thing), however my question/problem is if this is a project for a client, how do you estimate/quote for the project? Especially if the client is seeking a fixed price approach?

If you aim to release early and often then you can catch mistakes early on in the piece – this is excellent. However it’s not helping you a lot as a business if you catch the mistake early (and avoid wasting time on further development down the wrong track) but still exceed your budget in order to get the customer what they wanted expected.

My current thoughts on this matter follow 2 lines of thinking:

  • Don’t do fixed price projects.
  • Keep any fixed price project as small as possible essentially by splitting it into multiple units of work, thereby hopefully mitigating the potential for overrun (and also giving you a chance to have learned a bit by the time you come to do subsequent quotations so you can revise accordingly)
  • Don’t do fixed price projects.

Neither of these options is going to be popular with some customers.

Engineers as leaders is an interesting read which will have relevance to anyone who’s moved from a technical role into a leadership one. The comments around productivity are especially telling. I’ve always find it ironic that typically a business finds someone who’s great at creating software and then puts them in a role where they’ll be spending less time doing that (but more time talking about other people doing it!). The transition suits some people more than others – some people feel obliged to make it, but should realise that it simply might not be right for them.

I like the idea of developers as “lazy weasels” too. A better term could be useful, however in a certain solution we’ve inherited (from an external source) there’s a lot of reinvention of wheels present, which could be avoided if the original developers had decided to spend 5 minutes seeing if an existing solution was present before running off and writing something from scratch.

Why you want code monkeys who tinker in their own time is something you might want to add to your interview script if you’re involved in hiring developers. It’s pretty obvious stuff, but will hit the nail on the head regarding a lot of interviews you may have done – when you’re sitting there and the candidate has all the right technologies down on paper, and can answer a few questions to show basic aptitude, but yet you’re asking yourself why you can’t get enthused about them.

As for sandcastles, they’re cool and remind me of happy times at the beach. That’s all.

Tags: , ,

Posted on Tuesday, October 19, 2010 11:14 PM |

Like this? Share it!

  • # re: On methodology, hiring, waterfalls, and sandcastles
    Gravatar
    Commented on 10/19/2010 11:58 PM

    Ross,

    At work we face the exact same problem of clients demanding fixed price whilst also asking for flexibility. It is a conflicting requirement and even after telling them about all the advantages of an iterative approach (which saves money), they insist on the fixed price. There is two things you can do then:

    1) Include a ridiculously large buffer for "unforeseen" in the price. Sounds dirty? That's how pretty much every external IT vendor responding to a bid does it.

    2) Budget box it. The price is fixed, the features are not.

    Some clients are so stubborn that they will not even accept solution #2, which automatically leads to #1.

  • # re: On methodology, hiring, waterfalls, and sandcastles
    Gravatar
    Commented on 10/20/2010 12:24 AM

    Hi Ferdy,

    #1 gets a little harder when it's a return client, if the project "feels" like a similar amount of work as a previous project it leads them to question the price difference between the two. Some of the examples I have in mind are instances where the client is non technical, which makes things even harder to explain.

    I agree that every external vendor takes that approach, which is partly why I want to try a different way - unique selling proposition and all that :)

    One of the other things I'm doing in the background is creating a small set of short documents explaining the conflicting requirements you mention in your comment - in the hope that having a pre-prepared run down of basic concepts such as the project triangle (time/money/features) using non PM speak will save time and help them understand our perspective.. possibly naive, but hey..

    My goal here is to allow us to spend more time writing code and less time dealing with specs and PM issues, which I realise is a little naive ;)

Post a comment
Please add 4 and 4 and type the answer here:
Remember me?
Ensure the word in this box says 'orange':