The dangers of assuming customer requirements
I have learnt this week, never assume anything when writing an application for a customer. It reminds me of a lecturer I used to have who said
"never assume, it makes an ASS out of U and ME"
Very witty and completely correct. Often when writing applications customers will only offer half solutions leaving a lot of the work for you to guess and everyone knows that if you leave a developer to guess he will do the logical thing, which of course isn't what the customer wants.
Usually when in this situation I correspond with the customer regularly to ask them to decide how they would like things to work but in this scenario I was upgrading an old application and bringing into a new framework. This has resulted in me making some assumptions which after further investigation into the problem have turned out to be slightly wrong. Nobody really knew how it worked until I showed them what I had done and then they would say well it didn't use to work like that.
I tackled the project so that I was expecting change so making the amendments hasn't been to much of a problem and have done it along with the refactoring of the code. The work this week has made me appreciate the small iteration philosophies of many practices (Test Driven Development, Agile, XP etc) and how beneficial it is. Firstly customers needs will often change once they see the program working, so it I think it is important not to go to far down one solution because they might change their mind which may result in having to code the solution in a different way.
Working in a small coding/testing cycle means that you can refactor your code often which allows you to use the insight you have obtained writing the code to become useful. What I am trying to say is that once you have made a solution you now know what you need to do and you can look back over the code and see what can be clipped out and what parts can be brought together.
Working in a small coding/testing cycle means that you can refactor your code often which allows you to use the insight you have obtained writing the code to become useful. What I am trying to say is that once you have made a solution you now know what you need to do and you can look back over the code and see what can be clipped out and what parts can be brought together.
The main point I have learnt this week is, As much as humanly possible create a clear set of requirements on how the application should work because otherwise you could be wasting your time creating something that the customer doesn't want.
1 Comments:
That's true.I believe assuming is never gd.We're following XP in my company too. But not sure what the waterfall model guys have to say.
By Anonymous, at Mon Jun 05, 06:49:00 am 2006
Post a Comment
<< Home