It’s not always wise to aim for sustainability
Developers tend to hate legacy code. It’s messy and inflexible and no fun to work with. Most of the time that’s a direct result of quick and dirty work so it seems logical to aim for building sustainable high quality code instead so that the code last for long without becoming a burden.
Only sometimes the long run doesn’t matter.
Yes those situations exists when getting something out the door quickly is more important than it lasting for long. Especially if this something is a shot in the dark. It doesn’t make any sense to prepare something for being maintainable in two years time when you can’t be sure that it will last that long.
The open source and also venture capital motto fail often, fail fast, fail cheap applies to product development as well.
So if you have to build something quickly and don’t have the time to build it to last how can you deliver something that won’t become a nightmare later on?
To wrap it up the following is what we need?
- Fast results that are not too expansive when your product is not successful and thrown away
- Technology that can easily be extended in case of success
Now if the time pressure in the beginning results in low code quality that can not easily be extended you need to design for change rather than quality. It is important that you can throw away and replace small components.
For me it boils down to this:
The only design pattern you have to follow at all times is separation of concerns. Even dirty code when separated into logical components can be a good base to start from as you can replace it one by one without starting from scratch at once.