This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: The Dangers of assuming customer requirements
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
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"
A very witty comment 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.
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.
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 practises (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.
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.
Previous Topic
