When creating software solutions, we want to design something to be the best it can be. But what does "best" mean, and whose definition of "best" should we be using?
From a development standpoint, writing code can be tantamount to art. It is a creative endeavour and you want to be able to use your wealth of knowledge to create the most beautiful code you can. This might mean using the most cutting-edge technologies because you know the rationale behind why they are the "best".
As a developer you will also be thinking about it from a maintainability standpoint. What problems and risks might pop up in the future and how do I build in protection from this? How do I reduce potential support overheads, how do I make this code perfect before I send it out into the big wide world to fend for itself?
The problem here, is that you might never reach your idea of perfection. You can mitigate risks but what will be the cost of the time spent to make sure you have protected yourself from every risk, compared to the likelihood of ever encountering that risk? Sure, it is useful to build in scalability, but are we spending time (and therefore money) creating something that the client will never need to use?
The best for the business is something that they can sell. Something that looks impressive and will draw customers in. New products need to bring in money, strengthen client relationships or build prestige for the brand. This needs to be achieved with as little overhead as possible. If the code you are writing does not fulfil these needs, then do you need to be writing it? What parts of the product need to be completed first so that the business can put something in front of a client - because those are the parts that should be prioritised.
The customer version of best is something that solves their business problem at the best available price point. These means keeping development time down. The longer a single developer spends creating their masterpiece, the more it is going to cost the client, we believe in making sure we are not asking our clients to pay for development time past what they actually require.
Here at STaC Solutions we have a saying. "Don't build a skyscraper when the client only needs a doghouse". Sure, it is more exciting and rewarding to build the skyscraper, but it is likely that the customer needs the doghouse for a specific reason and a skyscraper, regardless as to how architecturally beautiful, will not meet the requirements in the same way.
This is not about cutting corners, or hastily throwing together dirty solutions. It is about creating a balance between the best from a technological standpoint, and what is best for the business. This should be surgical and nuanced.
You are aiming for a version of best which is the best you can do within the time allocated and with the resources available. If a client has a business-critical need, we want to target those specific requirements as quickly as we can. This means focussing on the parts of the product which are going to have the biggest impact to the client. Being pragmatic is not about providing less, it is about prioritising and working together to come up with a better solution for everyone.
Fortunately for us, our clients are less interested in our construction skills and are more interested in how we can deliver their software projects! If you would like to discuss how we can strike a balance to solve your business needs reach out to the team today.