Anachronisms and software design

 

In this article I will discuss exposing and dealing with anachronisms when designing software.

I came across the term ‘anachronism’ when I was doing software design for a client. We were designing online application forms. My client  was asking their customers about their marital status. I must admit I had to google what ‘anachronism’ meant, as you probably did too. Come on, be honest, we all know you did. I found an article on this topic, though it wasn’t to do with software design. It got me thinking about the anachronistic processes and features we build into software.

The thought that triggered my investigation

I was designing an online self-service application for customers to apply for my client’s product. The customer had to declare ownership of assets and in doing so declare if their partner owned any assets as well. In this case we wanted to design the ownership questions with the customer’s relationship status in mind. No point in allowing the customer to say their ‘husband’ owns a car if they are in fact single.

My client wanted to use 4 different relationship statuses that would result in the same software function. The statuses were ‘widowed’, ‘separated’, ‘divorced’ and ‘single’. I understand that culturally these have different meanings, but from an application processing and system perspective, they will probably result in the same outcome. Depending on your business rules. For my client it would make no difference to the system processing or their assessment on the customer’s eligibility for the product they wanted.

 

 

My real world example

Take the example of ‘widowed’ – for my client this has to be the most anachronistic relationship status captured. Why would my client need to know if their customer had previously been married and their partner had passed away? My thinking is that in times gone by when women had to get permission from their husbands or they could not remarry, this term was used. I am not saying we should remove the term ‘widowed’ from the general public lexicon.

What I realised, was that we would be building something into the system that was a cultural hangover of years gone by. Having said that, it is important to consider what your customers want. If they want to be able to declare their specific relationship status, even though it makes no bearing on the interaction with your company, then maybe you need to consider it. As a software designer, my approach is always to be lean and get the customer what they want as efficiently as possible. Reduce redundant questions, processes, rules etc. Often this means challenging the thought processes of your clients and product owners.

“Don’t bring the past along for the ride”

While this was a very small component of what we were building it made me think, what else we are building into the system that we don’t need. And – is the only reason we are building it, because ‘that’s the way we’ve always done it’. I want to challenge software designers and developers to question the product owner – is what you’re building anachronistic? Building new software is generally about moving to a progressive and sustainable future state, don’t bring the past along for the ride.

In the end, my client opted to keep the status ‘widowed’ – because their customers wanted it. Even though it had no bearing on the application for my client’s product. For the product owner it’s a piece of information that makes their customers happy, for developers it’s a redundant piece of data. Different information in a system/business means different things to different people.

The ‘Real World’ and the ‘Coding World’

Having worked in software design for over 10 years and working with some of the nerdiest of nerds. I have come to realise there are two worlds for tech nerds, there is the ‘real world’ and then there is the ‘coding world’. The ‘coding world’ doesn’t care about cultural hangovers, it cares about beautiful functions, classes, methods and for loops. It’s not concerned with people and people’s feelings, it cares about efficiency and logic.

As an IT consultant you find yourself stuck between the ‘real world’ and the ‘coding world’. We need to find a balance between what makes logical sense in a system and what real life customers want – even if it’s anachronistic. For business owners, the main focus is making money by keeping customers happy.

How should you handle an anachronistic change request or new requirement? Simply put, you need to challenge your product owners thinking. Remember you are making changes to move away from the past. “Why” is this feature needed. Have a look at our related article Capturing change requests.