Premature infrastructure is a peculiar behavior pattern that I witnessed in every single tech company I worked for. It is the habit of creating infrastructure code before it is actually needed. The development team is predicting future requirements and preparing ahead of time. That might be preparation for a future feature, extension capabilities that aren’t needed yet, or customization that may or may not be wanted. I believe that creating premature infrastructures is one of the biggest problems in software development.

I'd like to tackle an old dilemma: Class instantiation. Which pattern do you use to create a class? Do you always use a new statement? Do we still need to use Singleton or Factory? Should we always use dependency injection? How about static classes, are they truly evil?

Desktop application development dominated the software world for many years. However, with the rise of the internet, web applications took over with an incredible pace. When smartphones became popular, mobile applications came to be in huge demand, pushing desktop applications into third place. While the previous statement might be true to startups, there is still an incredible amount of software development happening in desktop applications. Consider programs like Excel, Adobe Photoshop and the Chrome browser.

Have you ever encountered an over designer? An over designer is a software developer that had some life changing event and became obsessed about architecture. The result being, obsessive decoupling, endless coding of Factories, creating deep (also needless) inheritence hierarchies and various use of design patterns for no good reason. I believe the over deisgner is a mutation in the natural evolution of a software developer. Software Developer’s Evolution Not every software developer reaches to Senior level.

A long time ago, on my first programming job I had a design problem that I couldn’t solve. This problem haunted me. The reason was that it seemed so simple, and yet I couldn’t find a good solution for it. Eventually I did a huge refactor, but instead of solving it correctly I simply changed one problem to another. Recently, years later, in a different company, I came up with that great solution I was after.