Note: This post has been in draft since October 2006. But my views have changed very little, which is nice. My grammar has changed though, so I've made a few adjustments to reflect that.

There are many programmers/software developers out there who take a requirements spec, design what the spec says, and deliver the product which is what the client wants, right?

Software is for people, the people who use it. Not the people who wrote the spec. It is vital to understand the original business need rather than the software need. In most cases a non technical committee wrote this spec, and from that you can be sure that it is bloated, likely with after thoughts. It doesn't take much time to ask for more, but it takes more time to create it and even more time than that to avoid it when using it.

Spend time with the user. Don't ask them what they want, but observe and try to understand what they need. If you spend time with the customer/end user of the software, you will quickly realise that the core business need is much simpler than the spec your recieved.

I work as an software consultant in an IT Outsourcing company, based in Dublin. Software development is not one of the companies core markets, but we do have a need for small systems to help with our business processes.

When I recieve a spec, I read it once, then head to the person who needs the application. I spend time with them, watching their work, and what they do daily. I ask them their expectations for the system, and tell them my ideas. I know this is not ideal when a spec is from an external client, but if it can be built into the requirements building process, this can work to the advantage of all parties involved, ultimately to the end users satisfaction.

When a software system is developed and a large amount of data is involved there has to be a way to break it all out, and make sense of the data. Relating data to different subjects and people and chronologically. Essentially, it all comes down to metadeta. Doesn't everything?* At least it does when you're a software developer who's passionate about organising data, relations and making sense of it all for the user.

I was sitting in work, looking at some code and I switched to iTunes to get some coding music on, and as always I looked for an opportunity to be distracted. I noticed that there were way too many genres in my music library.

It's an entire column in iTunes that I never use (I think it can be hidden, but thats erroneous) . That's one third of the browse bar thats never touched. After this revelation, I started to organise my music into genres. It's more difficult than I thought. Which genre should CSS go in? Pop? Rock? Indie? Soft Rock? And what the hell is soft rock? Is that even a genre? What's alternative? Alternative to what? I kind of guess Alternative Rock is Rock, but different. Isn't that what all bands are trying to achieve? Something the same, but different, something ... alternative.

So the question I ask is should music span more than 1 genre, should it be based on the general feel of the album, or on a specific song? Can a band cross genres between albums/songs?

I'm trying to conclude this post, but can't. Seems that a single album with many genres might give the user too much freedom, it could be dangerous. Constraints are good.

Lesson: Even if you can't figure out why something is built a certain way, there is usually a damn good reason for it, and someone has already sweat over it for a lengthy period before you thought of it.

Conclusion: To bring this back to software development - Just because a user requests a change to a piece of software, doesn't make it a viable reason to make the change. Most users don't know what they are asking for and can't see the long term effects. This is how software becomes bloated, the developer tries to please everyone. Further reading.

* Kind of like the matrix, but the CG isn't as good.