Josh Sharp design and development. Web pages with purpose.

Sometimes it might seem like what your manager wants you to do, and what you wish you could do, are two different things. You, as the shining pinnacle of developerness that you are, would like to satisfy your client's requirements by developing a generic solution that fits, but can also scale up, down, and sideways depending on the scenario. But this isn't what your manager wants to hear.

By the way, this isn't aimed at my manager, or anyone I know — just an attempt to explain a programmer's thought processes.

Let's take an example. Say your web application needs to allow admins to create a tree stucture of users, assigning them to groups and sub-groups. Each user will be two levels deep, in a subgroup.

So you propose the solution of creating a generic system (data structure, interface, the works) allowing n levels of groups — admins can add as many as they like. This is a nice generic solution which appeals to your programming principles and doesn't need any hard-coding of limits and the like.

But to your manager, this is overkill. Why add in this extra functionality? It will take twice as long, and the extra half isn't even relevant functionality. Just code in the ability to add two levels of groups, and you can move on to the next task. Why would you want to spend time and money doing otherwise?

The answer, dear manager, is that I am planning for all situations. Even though they definitely only need two levels at this stage, you can reuse this code for another project, or give your client the ability to expand and adapt their usage as they grow over time. I am creating a solution which provides a minimum of fuss for the client and myself in the long run. Why isn't this a good thing? Shouldn't we be praised for looking after the customer and minimising long term stress?

Say your client buys out another company and all of a sudden they need a higher-level group, so they can differentiate between companies. Given this situation, they could come back to you and ask, can you give us the ability to add another group? And you sigh, and shake your head, because this means rewriting code to do what it wasn't supposed to do — hacking it apart. To your manager, sure, reasonable request, plus this is something else they can make a profit on. But your developers are stressing about having to modify and recode the existing application from something elegant into something clumsy and ugly. And an unhappy developer is not an efficient developer, especially if this scenario is always repeating.

Add to this the undeniable fact that you are basically charging the client extra for your short-sightedness. As the supplier of solutions, it is your job to help the client understand and formalise their requirements. It is not their fault that your client cannot see all possible usage scenarios they might have for your software. That's your job.

It's like selling a client a static website in this day and age — no CMS, so the client has to come back to you when they need changes made. Sure, the client thought their site would never need to change, but now they're moving suburb and they can't change the address on their contact page. People would consider this underhanded when CMS software is so ubiquitous, so why write these sort of limits into any other solution you provide?

Obviously, I realise there are limits to what you can anticipate, but when you consciously prey on the client's short-sightedness you are doing yourself and your client a disservice.