Its an easy trap to fall into and I don’t always think its the developer’s fault. I’ve seen more than few cases where the analyst has misunderstood (read: not correctly identified) what the user needs and that has been translated into code by the developer. You also tend to get users that want things that seem like a good idea at the time (to them) but isn’t something they will ever use.

A good way to avoid this situation is to follow the advice from Getting Real, a free eBook from 37 signals, the company behind BaseCamp and Ruby on Rails among other things. In the chapter on feature selection, they point out that you should Start with No. This might seem harsh, but it makes perfect sense. Every feature you add is a burden. It requires ongoing maintenance. As suggested in the book, you should look for trends — reoccurring requests before you add something new.

My basic strategy for adding a new feature into a web site or system after it has gone live is something like this:

• Is there a workaround for the feature?
  Yes -> don’t fix it.
  No -> Next question.

• Has the feature been requested before?
  Yes -> Next question.
  No -> Say no (nicely). Don’t fix a system used by hundreds/thousands/millions of people just because of one request.

• Is this feature going to be difficult to implement?
  Yes -> Say no (nicely) based on the difficulty. Wait for it to come up again.
  No -> Next question.

• Does the feature add value?
  Yes -> consider it. Make sure it is given a low priority for now. Wait for more requests for that feature before moving it up.
  No -> Say no (nicely) due to more important priorities.

This my seem quite harsh, but it helps to reduce the amount of new features you are adding to a site or system, and lets you concentrate on fixing up any existing bugs.

Unfortunately this won’t always work if you work at a relatively large organisation where you generally have to do whatever is requested. However, you can still try to apply this approach. Remember every feature you add is something you will potentially have to support and maintain in the future …

For example, in my context, I’m referring to web development. Specifically the time I spend developing, and updating web sites (creating content) versus the time I spend learning new skills and technology (consuming). The point is to move more towards creating, and allowing the time spent consuming to compliment what I’m creating.In other words, there’s no point learning everything I can about web development, if I don’t actually build or update any web sites. Pretty obvious stuff, but like many things, I never thought about it consciously. In fact, I know I sometimes procrastinate on something I should be doing with the excuse that I need to do a bit more research.

I’m not saying you should just dive right into things. I’m just saying, you should honestly ask yourself this question: what are you doing towards your goals right now, creating or consuming? And if you are consuming, do you need to be, or is there something you can create right now?

As a small child, you’re embarrassment index is very low (0?); you simply don’t feel it embarrassed by most things. Its probably around the time you start school that this changes, and you creep over the 0.5 mark for certain things, such as having your parents drop you off to school. I’m guessing that most people stay above 0.5 for a lot of things for most of their lives. However, as you get older, there are times where you do fall below 0.5. However, other people are quick to point out this fact and let you know that you are below the threshold …

I’m blaming society here for the high embarrassment index. Its not all bad, there are times when you should feel embarrassed. The point where it concerns me is when the fear of embarrassment stops you from achieving something. For example, being too embarrassed to go to the gym because of what people will think, even though you really do need to lose some weight.

I realise there are exceptions to the rule. There are people that have a naturally low embarrassment index and keep that way for their entire lives. So, I’m going to leave this thought with a link to an excellent book; What do you care what other people think by Richard P. Feynman who was definitely an exception.

Well I had the same problem accepting this at first. I had already accepted that my code sucks, and that I could be a better programmer by not programming. However, the concept of solving the problem at hand takes this one step further by making you catch yourself before you go writing code just in case it might be needed.

You end up asking yourself: “Wait a minute, am I over-engineering this?”

The main reason for not writing code just in case is that it rots. Code that isn’t used still requires maintenance, it still has bugs in it, and it still needs to be tested. The key is to accept that every line of code you write will potentially add more bugs. Reducing bugs means writing less code. Writing less code involves finding the simplest thing that could possibly work. Remember as a software developer, you are you’re own worst enemy. I believe that’s what makes this concept so hard to accept, particularly if you already think you’re a rockstar programmer.

Another problem, is that the simplest solution isn’t elegant enough for some people. For example, the simplest solution might be to just to skip the first line when looping through a file because it stores headings and not data. But then the questions start; what if the data changes and the first line isn’t a heading any more? What if we have headings across two lines? What if the data is encrypted in an alien cipher … and so on. Right now, the headings are on the first line, and the code passes the test of reading the data with the headings where they are. Problem solved, move on now.

A good way to ensure you solve just the problem at hand is to take a test first strategy. Sure you can write unit tests and execute them in xUnit if all that is available to you. But really, this simply means:

• Write the test first;
• Write enough code to make it fail second;
• Write enough code to make it pass third;
• Move on.

Note that writing the test may simply mean writing the test out in English (or your preferred language). Automated unit tests are still a luxury.