Softwaredevelopers – Are you a Gardener or an Engineer?

There are 2 types of projects. And I think, unless the project itself makes it clear what kind of development model it is to be, the client should be presented both options with their Pros and Cons. Are you engineering a software, or are you planting, nurturing and growing it for full blossom?

The first type of project is planning ahead, specifying the must and must nots in a software specification, estimating cost and then freezing the plan, starting to develop. This will cost a lot of pre-planning time and the client, who we know, most of the time, will not know what he actually wants, until he sees the product. This is the classic engineering model. Waterfall, V-Model, V-Model-XT and all the others fit perfectly for these. With this model you will be able to give a final prize to your client, and he will have to wait.

Even in this engineering model make sure to use story boards, prototypes and all the other best practices for software projects and software development (testing, continous integration, version control – all your common sense things). Show the story boards and prototypes to your client as soon as possible, so he can get an idea of what the product will look like and what has or could be changed. Adapt your plan (which was freezed – remember?). If you don’t have a client, you can still use these to check workflows, usability and make sure that is indeed what you were looking for.

The second kind of project is like gardening. It’s more of an agile development process, and thus development models like Scrum are better fit. With engineering you probably have some techniques in common (version control, continous integration, testing – but maybe also prototypes and story boards). What you do different is you get a general idea of what your client wants, and then you start planting your seed. Get the first, basic features in. Nurture it. Make your client look at it. Is that how he wants it?

You will not be able to give the client the option. But if the client knows that most of the finished, engineered software is not to the clients satisfaction, will he not accept a work-time-salary/-price? While the project is running he will be able to see the progress. He will be able to influence, to change the project much more and much closer to where he wants the end-product to be. Tell that your client. Even with a grotty project, he will be able to cancel it much earlier. He did not agree to pay a million dollars for a software that he will be able to see in 2 years. He pays for what is being done, and he sees what is being done. And he can influence what is being done right when he notices, what I thought I want is not actually what I want – there is a better way. Then your product will bloom to satisfaction of the client.

In the end, both kinds have their reason d’etre. As so often in software development. But wouldn’t it be great (if applicable) for a client to be able to choose? For developer, project hoster and client to be able to talk to each other and actually nurture the product for it to grow in the right direction instead of using static concrete to create what was planned 2 years ago out of air?