Our Blog
Problem Solving in Software
30 October 2009 14:03, Posted by ColinVery 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.
Great 404 Page Idea
18 June 2009 09:53, Posted by simonI came across a great 404 page the other day and thought I would share it. The page at first glances looks like any other but if you read the text, you will see that they have redeemed themselves for the broken link by offering me a discount of $3 off any of their products.

This is a great way to capture the interest of would be browsers that would normally see this page and immediately hit the back key, instead not only do they capture my attention, but they also tap into my curiosity which gets me to immediately click the products link.
In this case I didn’t need any of their products but this is a great tip.
Also note the search bar being visible. This is essential on a 404 page for keeping customers that know what they are looking for on your site.
