Pragmatic software

A slight off-topic post today. I want to talk about pragmatic software design and development – the idea that when you implement a feature, before you start it ask yourself some questions: –

  • What are the customers / users expectations for this feature?
  • What is the bare minimum I need to do to implement this feature?
  • What impact will this feature have on the existing system?

There’s always a difference between customer and developer expectations of a feature. As developers, we think of user-facing features in terms of not only what the core feature is – say an Add New Customer – but also in terms of other cross-cutting concerns. Will there be validation on the screen? Will there be tooltips to offer the users help? A “please wait” dialog that opens on a background thread whilst communicating with the server? Caching some data on the UI so that you don’t have to make repeated calls to the database for performance reasons?

All of these are things that the customer probably hasn’t thought of when asking to be able to add a new customer to the database. Sometimes, they’ll be expecting them, others not. Sometimes they’ll be expecting features that you won’t have thought of. This is all part of normal requirements gathering. What you need to be aware of though is that every extra feature you add to the customer requirement changes their expectations going forward. These little “extras” all add up – this takes up time for you, and cost for the customer – cost that they might have rather spent on doing any number of other features.

As a developer you might want to deliver the “best” solution for the customer, adding in lots of features that you think should always be delivered. If you are able to deliver them for free to the customer, at a time that suits them, great. On the other hand, if you’re charging them for time that you’re spending on a project, give them the simplest option first. Spend time on writing well written code that adheres to SOLID principles where appropriate. Write unit tests. Then let the customer see it and mention at that point that it doesn’t include validation / tooltips / caching etc. – and give them an idea of how long it would take to deliver that. This doesn’t mean that you don’t want to give a good solution to the customer, or that you don’t have a “can do” attitude. It means that you’re empowering the customer to decide exactly what they want to spend their money on. It also protects you from spending days writing a feature that you’ve misunderstood and wrongly delivered (or protects the customer from not knowing what they wanted initially).

I guarantee you that literally dozens of times you’ll find that the customer doesn’t want those extras. Instead you can spend that time delivering other features that they absolutely need to get up and running as quickly as possible.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s