Ever hear the expression, the punishment should fit the crime?
How about, a proportionate response?
How about, to a man with a hammer every problem looks like a nail?
Now, I’m not trying to implying that your code is a crime, though it may very well be. But do you, a professional software coder really want to only have 1 tool?
This episode’s topic is “always make the solution fit the problem”.
Now this is, perhaps without fail, the single biggest mistake junior coders make. Sadly, some of us never stop making it.
Consider this, you are an engineer capable of creating an online store to rival Amazon. Your father comes to you and asks you to make a website for his hobby business selling garden gnomes.
Do you “engineer” a system capable 99.999% uptime and 10k transactions a minute?
No, you probably install phpShop and show him how to use it.
In my less younger times, my standard justification was always, “I’m designing it for tomorrow”. Or ” i know i will need to extend the system here “.
The truth? Probably something like “I wanna build something cool that I can be proud of” or “I want a challenge” or the ever popular “I wanna try out this new technology/library”
Now I should have just been proud to have achieved the often difficult outcome of a happy customer.
Now I’m not trying to sell you some new ideology or practice like emergent design. (Although you might be interested to check that out)
I’m trying to sell you something that is software folks seem to have missed. User experience (or UX). UX is not about user interface design. It’s about the user experience.
Tough concept I know, we coders like in a world of abstraction and obfuscation and its easy to assume things are not what they claim to be.
Before you get out the soap box and claim I write functions and classes, I don’t have users!!
Are you sure?
Your are probably your own user. The guy at the next desk is probably also your user. Should you not care about their user experience?
Consider the following function:
By looking at the function signature can you tell what it does?
This is perhaps worse, the name actively misleads the user.
This would be better
Take a deep breath, let’s put that aside for a minute. Go back to Dad’s garden gnome business.
When faced with a project like this that poses you no personal risk, take a moment and consider some other factors:
- Cost of construction – Does the amount of time you spend building match what you are being paid? Does it match the expected quality and capability of the customer?
- Opportunity cost (time to market) – Will the delay caused by the more complicated solution impact the business? Does the customer really need it ASAP?
- Cost of maintenance – If you build something custom, you will be 100% responsible for its maintenance, future improvements, bug fixes, etc. If you acquire it from somewhere else then you can get some of this from the original project.
- Actual usage levels – Will anyone actually use it?
- Cost of learning – Learning new stuff is fun and having someone pay you to learn it is also nice. Is your customer happy to pay for your learning?
- Likely usage growth pattern – Most software will never reach Google or Amazon level of usage and will almost never do it overnight. Generally you should build the system to be able to handle 10x the expected load and no more. Between launch and achieving 10x load, you will learn a huge amount about the users, the market, the technology choice, your team, etc. This knowledge will have a huge impact of any future extensions and expansions.
- Your actual experience in the problem space – It’s nice to be confident but inevitably we will not know everything we need to when we start a project. It’s often better to build the known requirements and then extend based on real data; real user feedback, real performance bottlenecks in the system; etc.
At the end of the day, value yourself and your time.
Do a good job but don’t overdo it.
Revel in the fact that to you not all problems look like a nail.