This blog
This blog focuses on future-proofing software develoment. This concept is used on many industries like electronics, medical industry, industrial design, … but is less talked on software business. The reason of its unpopularity maybe due to several reasons:
- The previously mentionned industries produce mainly physical products which are not easy to change after delivered whereas we can generally change software’s source code and release much faster.
- Future proofing for software can be easily led to big design up front and over-engineering.
Neither big design up front nor over-engineering are good, and that is what agile movement and data-driven decision making are there to help fighting them.
However, not thinking about the future while developing software is even worse. Software is supposed to change and it often changes very fast, especially when your business depends on it. Because of that, we tend to say “if it doesn’t work, we can always change it later”. Most of the cases, it is desirable even encouraged. We need of course iterate fast and deliver values to customers to stay competitive. In reality, if we don’t plan for the future, technical debts and feature bloat keep rolling with new incoming feature requests. Over time, instead of working on the next cool features, we’d spend our day to fight these legacies. Productivity decreases and team’s morale is dragged down.
To develop future-proof systems, we don’t need days to plan ahead but just need to take it into account we design and code. And most importantly all our team should be aware of that, because building and maintaining systems is a collective effort. Other authors mentions the concept without using the word future-proof: reversibility (in The Pragmatic Programmer book), evolutionary architecture (in the book of the same name), … I hope that this blog will help a little bit to raise more awareness about the problem.
As designing future-proof systems is vast, in this blog, I focus only on the practicality for these aspects of future-proof systems:
- Readability
- Sustainable and Maintanability
- Flexible architecture
To achieve these goalds, most of the time is via code, the rest is via communication and methodologies. In my posts, if there is code, I generally use Kotlin to demonstrate idea because it is sufficient concise and less boilerplate, but the idea should apply for other programming languages, too.
About Me
I’m Manh-Ha Vu, a software engineer in Paris, France. I’ve been in software development since 2011 and had a chance to working with different teams on “legacy” systems and also building a new product from scratch. I’ve learnt a lot a lot of pitfall and good ideas during those years and I’m hoping to share some of them with you 😁.