Customization and Change in Software Development

For years I've been looking at APIs and protocols which speed up development but still confer a high degree of customization. Components, code libraries, CMSs and other such pre-packaged modules help with speed, but by their very nature they can stifle customization. By no means am I saying libraries aren't flexible, the good ones are, but sometimes the investment required to go 'off road' is so close to custom coding, you lose the initial benefit of using a library.

In a simplistic sense, the problem is illustrated by situations in which a client asks: "can you change this to...". Regardless of what development methodology you're using it, be it Agile or Waterfall, the time to make the change has to come from somewhere. What's that I hear you say: "don't worry, we have a change request budget factored into the project". That's good, very PRINCE2 of you, and for the most part this works great for small changes. What happens when a change request budget is exhausted, then what? You're in a situation where you have to ask for extra budget to cover off-spec work. Maybe you'll get the extra money, maybe you won't. Or you could take an Agile approach and say: "OK, we can put that in, but we have to drop another feature to cover the resource short-fall".

Although that scenario may sound perfectly reasonable to you and me, my experience has been that it's hard to convince clients to give up a previously agreed feature. It's like trying to get candy off a kid in a supermarket, once it's in their vice-like grip, they'll throw a tantrum should you try separating them from their prize. I do understand why it's a flawed proposition to say to a client: "if you want that feature, you'll have to sacrifice another." Why would they, they've thought up a good new feature, it has no connection to any other feature which was previously planned. It's a perfectly logical argument from an Agile perspective, we have limited resources, if the resources aren't increased, we need to trim back on previously agreed features.

This issue isn't as problematic for teams developing in-house software, they know and accept Agile principles, they can come to terms with dropping a good feature for a better one. But business owners aren't software designers, why should they understand this particular Agile concept? It's prioritization, and not everyone is good at that. Then there is the extreme version of this, Minimal Viable Product (or MVP). Anyone who can successfully sell that idea to a client should change their business card title to 'Lord of the Software', they are true smiths of the trade in my view.

Enter WordPress, Our Savior...
Let's say WordPress is currently viewed as a fabulous way of solving the problem of development speed + customization. It's all about pre-fabrication and bolt-on modules. The reality is WordPress isn't immune to the problem of customization, it's just faster at it. No API or code-base can perfectly predict and cater for the permutations that make each individual businesses unique. Plug-ins are essentially pre-packaged implementations of a [design] pattern, this is what WP excels at, but doesn't totally solve the problem of fast customization when it comes to deviations caused by unique business requirements.

Let's return to a statement of the problem: clients need customization in order to suit their specific business needs. What if we were to mangle this and say: "clients change their mind because they don't know what they want, thus putting strain on resources and injecting unpredictability into the project." I know saying "clients don't know what they want" sounds bad, but what it really means is business owners don't understand the software development process, nor should they. Does this then become a matter of 'education' - you could try that, but someone's got to be willing to learn in order to take in something new. Having the 'teach the client about software development' mentality leaves a lot to chance. Don't get me wrong, I try indoctrinate clients into the world of software development as much as I can, but I don't rely on this as a sole means of steering a project in a predictable manner (nor should you).

I've been trying to reduce the potential of clients changing things as much as possible from the onset. I do this by really probing them early on in the project, it's not just a matter of asking lots of questions, but rather the right questions. The goal is to avoid the potential for change once the project is underway. Now, this is only possible to a certain extent, you'll go crazy trying to cater for all situations. So if you can't know all possible outcomes ahead of time, what else can you do to instill predictably?

One approach I've been using for year which is very much in the spirit of Agile is suggesting options rather than asking the client exactly what they want. I know this may sound counter-intuitive, but sometimes it's easier to tell someone what you don't want, rather than what you do. The premise being that by removing the unwanted options, you're left with a pool of viable options. In practical terms, it's the difference between saying: "how do you want this?" compared to "we can do it this way... or this way... or another option is...".

By taking this approach, you reduce the risk of stakeholders changing their mind later down the track (reduce, not remove). By offering possibilities, you're helping with the issue of the client not knowing what they want (maybe they don't know what's possible, so you tell them). To me this also seems like proper consultative service, rather than expecting a client to design what they want. A client should only have to tell you what the end goal is, or what task their user is trying to achieve, then it's up to the software designer to make it so.

Subscribe to RSS Feed.