Optimise Later

One of our design philosophies at Blueprint Power is that you don’t spend too much time optimising code early on but instead focus on writing maintainable code with maintainable languages. More often than not, I have watched teams concentrate on picking the fastest language or improving the processing by some percentage instead of defining a solid data model and design pattern for the code.

This hunch has served me well throughout the years. More often than not, by the time the performance bottleneck impacts you if your teams have been writing documented code in a readable language, it is easy enough to profile and optimise those areas that need it. For every performance landmine you find, there are at least a hundred you missed by focusing on this philosophy.

I have been fortunate in my professional life to come across problems that required bespoke solutions for even meeting the requirements. These weren’t bleeding edge solutions; we were building the edge. Even in these situations, I will argue you should focus on defining your needs, documenting your code, and optimising later.

One of my heroes, Kent Beck, is credited with this quote, and I will end with it here - “Make it work, Make it right, Make it fast.”