Software development has many goals. The code needs to be written quickly, clearly, with limited resources and so on. The software itself needs to be fast, easy to use, run on many platforms and more. As you achieve more of one goal it’s probably at the cost of another. If you software is highly optimised it probably harder to understand. It’s not possible to have it all.
Different software engineering practices and techniques have been developed to try and cope with all of this. You might have originally learned the waterfall model or agile development. You might have memorised DRY, KISS and SOLID. Often the original ideas repackaged, renewed and renamed over time. However the ideas are updated they should still be trying to achieve specific goals and they can’t achieve all goals equally.
This blog isn’t about some perfectly balanced programming practice. I don’t think that exists. Different situations call for a different emphasis. I want to talk about how to balance programming. How to think about what you want to achieve and how to pick the choose guidelines accordingly. How to decide when to follow a rule and when to put it aside.
I graduated university in the late 1990s and have been working with software ever since. Mostly of that time has been spent in small teams, as part of small to medium sized companies. I’ve written a lot of new code but also worked with a lot of existing code. This often involves revising and improving code to make it more consistent, smaller and more understandable. More recently I’ve spent time thinking how to organise the processes as well as the code itself.
Posts here are part of me thinking through these processes. Although there may be answers here they probably aren’t the final answers, yet. I hope to post about: engineering practices, task estimation, coding standards and anything else that seems relevant.
I hope its useful for me and maybe for others as well.
Leave a Reply