Apart from writing code, driving architecture and designing/re-designing solutions; one of the most common activity for Software Developers is exploring a myriad of possible solutions to roll out a feature or improve an existing one.
When considering a particular problem being solved for a stakeholder, it’s always important to consider multiple ways of approaching the problem.
Here are the main things that I consider when making a decision as to which approach should be taken.
Understand The Problem
First and foremost, before heading off to find different ways of solving a problem, the first step is to always really understand the problem in the first place.
When I say, understanding – take everything written down with a grain of salt and think more critically about it – if something doesn’t quite add up, ask questions and try to gain more insight to see if you can get an unambiguous description of the problem being solved to be able to propose the correct solutions without adding additional complexity for both the developers and the customers.
Existing Solution?
Does it have to be done this way? is there a way to utilise the current solutions already in place?
You’ll be surprised of the amount of times code and entire solutions are written to do the same thing over and over again – and if the entire solution doesn’t exist, then maybe perhaps at least a subset of the problem is already solved somewhere – this is important to explore.
Time
Of course, the base cost for producing literally anything is time. The more attention we give to one feature means less time spent on another potentially just as an important feature. Time is the base currency and is the most important thing that you can spend – spend it wisely.
Although the time it takes in Software Development can be a pretty big “guesstimate”, depending on how large a piece of work is, the larger it becomes, the more inaccurate the becomes – also keep this in mind. That 2-week estimate is probably going to take you a week or two more – so also keep it in mind.
Value
If you go with x approach, what value does it give you now? what about with y approach?
Ok – now, we have a very abstract concept here – “value” – what does it really mean to have value? Well, this depends entirely on what you’re trying to achieve, and how well established your ideas are and how you see a product or feature going forward.
Some examples below:
Understand user needs better
The quicker you get the feature out, the better – even if the experience finesse isn’t quite there and just about gets the job done – getting feedback from users is better than spending 2-5x the time needed to just get a basic feature out – this is “cutting waste”, this is the agile way of writing software – to be able to get things out early and iterate on it.
This is a great value to consider if the feature or entire product is not established and is still trying to find a way to fit itself into the market.
Less operational costs
Does doing it in this way cut down on the money needed to keep the lights on? whether it be automating a portion that would normally take a persons time, or cutting down on your infrastructure bill?
This usually isn’t a huge concern if a feature is more on the experimental side, as it may be scrapped pretty quickly, but if it’s an established feature – finding an approach that costs less to run is usually a great incentive for the product and the organisation.
Speed
Does doing it in a particular way cut down latency by a significant margin? how much does it cost?
Again, usually isn’t a concern for experimental features.
Flexibility
Does it keep things flexible without being too abstract? does the extra flexibility justify the extra future cost?
Development speed
Some features just need to be first to market, doesn’t matter if the solution ends up being scrapped completely – again, this is similar to understanding user needs better, but this is more specifically having a competitive edge against and be able to say “We were the first to have feature x”.
Resilience
For certain types of applications, such as anything that handles payments, resilience is a very important aspect to consider – if it fails at any point, the system needs to be able to pick up where it left off without causing any weird side effects, uptime needs to be 99.99% etc.
Scalability
First things first, does it really have to scale? – if it’s more of an experimental feature, you could probably get away with a solution that uses a .csv as a data source for all we care, and you’d be fine until the feature is proven to provide value to the customer.
What’s the extra effort required to allow the feature to scale? does it have to do it now? or can it wait?
Again, there’s no such thing as a magic sauce for deciding, and the pattern becomes obvious over time as you gain more understanding of things, that the answer is almost always “it depends”.
Future Value
Will doing it in this particular way add more advantages in the future for any of the stakeholders in the future? how soon will the investment pay off? how much more costly is it over approach A, B or C? will the future benefit actually ever see fruition? maybe we’re thinking way too in the future?
The point here is, certain approaches may not add value now, but will have an impact for the better at some point in the future and is something worth considering when considering the approach you’re taking.
Future Cost
Now, this is the opposite of what we’ve just talked about previously, you’ve thought way too ahead into the future, that you’d actually end up adding future cost rather than adding value – you end up with an “Architecture Astronaut” solution – and the victims are your future self and everyone else that will be working on the solution in the future.
