An interesting post over at 37signals suggests that it’s good to give up on a feature that’s taking too long to implement. This is a great tip if the pain of implementing a feature outweighs its value or benefit.

A better tip is to properly assess the value of a feature before starting to implement it. When you’re familiar with the environment in which a feature is to be installed, and you’re knowledgeable about the users and use of an application, you can assess such things as:

• are there other ways of achieving the same outcome using existing features?
• how often is this new feature going to be used?
• how critical to the application (or business) mission is this feature?

I have another tip: don’t even start thinking about implementing something until your customer has asked you for it a second time. (Children reading this blog should ignore this particular tip!)

I must however suggest caution with this approach: because to be able to persuade customers not to add a feature, for whatever reason, requires trust between customer and supplier. For large projects, we build trust by finding out about our customer and how their business works. The primary objective of this activity is to gain enough knowledge and information so as to be able to implement what they need effectively – which isn’t necessarily what they ask for! Indeed, we often advise on making changes to their business process, reducing the amount of work we have to do! Sometimes people get so caught up in the mindset of a ‘contract’ that they forget what they’re in a contract for.

The reason why engineers don’t want to give up is because of the perceived loss of engineering effort: their part of the pie, their code legacy. Gone forever. I’ve worked with software engineers who have been distraught at learning that their software is to be discarded – either unwanted or superseded. But they really shouldn’t have worried: it’s all history – get over it and move on.

You can apply these tips to real life too!