Problem Solving in Software

Very occasionally, people will start asking me in detail what I do for a living. When “I write software” or “I make websites” doesn’t satisfy them, I go into a bit more detail about the different aspects of my job. One thing that happens quite regularly if I don’t go into enough detail, is that I’ll tell someone how long it took to write something, or how much it cost, and they’ll raise their eyebrows.

“How can it cost so much?! It’s just a website!”

I can see their point. Most websites contain common elements – login, lists, articles, shopping carts, and so on – so you’d think that once you’ve written one, you’ll have the bits and pieces you need to make more. And taken individually, each of these parts are fairly straightforward – a list of products contains some pretty basic HTML, surely? And HTML is just a text file?

And again, that’s a fair point. The real time isn’t taken in writing these bits and pieces, it’s taken in understanding how the customer wants them to be written and how they need to fit together in a certain situation. For example, a shopping cart quickly becomes more complex when the customer adds on a few more features:

• Integrates with Google Checkout
• Customers can save carts for later ordering
• Customers can reload past orders into a few cart

But it’s not just the cart, it’s viewing products too – what if certain customers see custom trade prices? Or products can be assigned to multiple categories and the customer wants to see how many products are in each category next to the category name? All of these things are minor when taking in isolation, but together they are a thousand tiny cuts which bleed development time.

As well as a collection of features, a specification for a website will also discuss requirements in language which is specific to the company you’re quoting for. Rather than “cart” you might have “basket”. Or you could have “assessors”, “reviewers”, “investigators”, or any other number of terms which a company uses internally and when referencing all of the features they want on their site. Eric Evans talks about the “domain” of a problem when discussing software – not only do you have to appreciate what kind of features are necessary but you have to understand the domain in which they’re going to be used, in order to create a solution which fits together correctly.

So software is a whole big bag of questions and clarifications and solutions. From a developer’s point of view, it’s not just a case of taking some standard components and piecing them together – though that does happen occasionally. Instead every step of the development process is about solving problems, by understanding what the customer wants and by understanding the problem domain. Every day of development sees a developer tackle a new bit of work that needs resolving in a novel way, and that’s why making software isn’t just a case of shoving some parts together and hoping that it works, but a process, an evolution of the initial ideas.

When clients come to us and ask for software, they’ll pitch it by saying “make us a website”. But we know that what they really mean is “look, understand, and solve our problem”. And that’s what we do.