In an age where agile development methods are widely adopted, properly designing the architecture of software beforehand seems to have become a lost art. After all, there’s much to say for just starting off with a small piece of working code and building upon that – while refactoring if needed. However, such theories are often (wrongly) interpreted as an excuse to never design anything ever again, and the refactoring step is often being ‘forgotten’ because the focus on the bigger picture is lost. This means your little gem is likely to eventually turn into an enormous out-of-control behemoth, that nobody can either understand or maintain.

In the past we’ve seen that it’s pretty much impossible to design entire applications into detail, but thinking about what you’re about to build (even if it’s just by drawing some quick sketches for a module you’re working on) can often be very revealing for yourself, helpful for your coworkers, and can mean the difference between software that’s easy to work with or a nightmare to maintain.