![](https://ciansheun.com/wp-content/uploads/2019/05/lincoln-boombox-1320x564.jpg)
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.
![](https://ciansheun.com/wp-content/uploads/2019/05/New-Project-21.png)
Register your domain name with Cian’s Web Hosting
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.
Key take aways
The message I’d like to pass on in this article is to think laterally, question ‘why’. I’d encourage this is all walks of life, but for the purposes of this article, I’m talking about software design.
- Think outside the box, think lateral and question ‘why?’
- Simplify your design, to make the process easier for customers and staff.
- Remember there are two worlds – the ‘real world’ and the ‘coding world’.
- Fresh eyes help, get someone from the outside the team or organisation or even from another industry. Get them to take a look at your design. They will see things you can’t.
- Question things from different perspectives and dare to be progressive.
- Here is the article that got me thinking Huffington Post – Marital status is irrelevant
An interesting dilemma – To what extent do we allow old cultural norms dictate the decisions we make in the design of new software vs. attempting to change cultural norms by the decisions we make when developing new software? I guess it depends on the circumstances and the end users. Something as simple as storing a person’s marital status, for example, would not come at much of a price in terms of space or bandwidth, so perhaps it was an easy decision for your client to keep the customer happy and leave it in the new system. Or perhaps your client saw a potential use for this information in the future and thought to simply collect it now to save on hefty infrastructural costs and changes in the future. Thanks for sharing.