One of the most challenging parts of being a software developer is striking a balance between the 'best' solution to a problem and the quickest. We are always looking to produce the best tools we possibly can, but it's important to recognise that these tools are useless if they never make it into production.
One of the most challenging parts of being a software developer is striking a balance between the 'best' solution to a problem and the quickest.
We are always looking to produce the best tools we possibly can, but it's important to recognise that these tools are useless if they never make it into production.
In my experience, there are two extreme types of developer: those who are focused solely on solving the problem they've been tasked with as quickly as possible, without giving any consideration to future developments or variation in requirements, and those who feel the need to build a system that can cope not only with every current possible variation but also every conceivable future variation.
Most good developers will attempt to steer a path between these two extremes and their ability to do so is critical to their success. I've always leaned slightly towards the first extreme.
To my mind it is more important to focus on the problem you do have than any you might have in the future. The future problem might not even happen, and it's better to get a tool into action and doing good than delay it to implement features which might never be used.
That said, if we build a tool to solve a particular problem, then six months later come across a similar but slightly different problem, we should reasonably expect to be able to apply the tool to the new problem without having to redevelop from scratch. By following good development practice we can achieve this.
The trick is to recognise which problems are likely to reoccur and in which ways they are likely to vary. So, for example, if we write a tool for a particular client to analyse a data file taken from their systems we may recognise that the analysis process and any actions resulting from it can probably be applied to other clients but that other clients will be very unlikely to have a data file in the exact same format.
Therefore we take a modular approach to our system whereby we can easily swap out the data file parser for a different one if we need to. We don't need to write another parser at this stage, nor even get too heavily involved in the details of how the parsers will be swapped; we just need to be aware that we may need to swap them in the future and bear that in mind when making any design decisions.
A lot of this is simply good practice anyway. Well-engineered code will be neat and modular in any case, and I would never advocate anything else. But it's possible to become distracted by future-proofing code and lose sight of the original problem.
As usual, the right path is somewhere down the middle.