How to Write Extensible, Maintainable Code When You Don’t Know About Future Features and Changes

In my twenty years of software development, I have found one constant in all the projects I been working on, things are going to change. Not even one project escapes this reality; no matter what you do and how well you try to gather requirements, all projects will need adjustments during development and after being in production.

So, it is a must to write software that is easy to read and easy to maintain instead of writing software to last (The Noble Art of Maintenance Programming). The answer is quite long. I will give you the key points, but you will need to investigate the subjects a lot more and put them into practice.

First, you need to deeply understand the entity-relationship model when creating databases and data structures. It really doesn’t matter if they are relational data, document types, or graph databases, the principals for managing data are the same. The foundation of any application is the data, not the business logic (it is also very important, but not the foundation). So, learn database design and data modeling.

Second, you must learn why we use object-oriented programming (OOP). It is not necessary to always use this pattern; it takes resources and is not advisable to use when real-time response systems are needed. OOP was created to model the real world on a computer (the weather, specifically) so we can deal with coding better when creating the solutions to real-world problems. We can achieve the same results without OOP by using other languages as Haskell (which is purely functional-oriented) or C (which is structured programming). Just remember that none of them are right or wrong, better or worse — they all have a circumstance and a time when some are better to use than others. That is why you need to go to the roots and learn why OOP exists, what it intends to solve, how it solves it, and when is better to use and when it is not.

Third, you must learn software architecture even if you are a developer and don’t plan to be in that role. Using layered architecture and multitier architecture will help you a lot when problems arise; you will know exactly where the problem is and won't be wondering where you have to look to locate it. In this ebook, you will learn more about the repository style, but the domain-driven design style is also very good.

Fourth, learn the SOLID, KISS, DRY, and separation of concerns principals and all the ones in "12 Essential Software Development Principles and Concepts." It will save you a lot of headaches.

Learn about the module pattern. This is very important since it will allow you to deliver small pieces of fully functional software so the user can test the application before it is complete. The user will give you feedback and make any corrections during development so the software that you write will already be on track. This approach saves you a ton of work. Make sure that always do a Minimum Viable Product. "Patterns of Modular Architecture" is a good article about it.

Learn about the Adaptive Object-Model Architectural Style. This one is not easy to learn since you have to put the business logic of the application in the database but not in the code. This is a supreme way to make an application since any changes in the business logic of your system only require an update to your database as configuration; the application will adapt to the change without needing to write any code and you will not need to deploy the whole system for every new change to the business logic (more on that here and here).

At last, the most important thing I ever found: consistency, especially when working on a team. All of us learn different approaches on how to do things to solve the problems of software development and we use different solutions. There is nothing wrong with the way you solve things as long it is a reliable solution and does what it is expected to do; it's fine that everybody is different (don’t fall for the trap of “everybody writes bad software except me;” you will always be wrong and will miss an opportunity to learn from others and improve yourself).

When you are on a team, if every developer puts their own style in the project, you are going to create chaos. The software architect or technical lead imposes (yes, it must be imposed) the style to be used in a project and it must be strictly followed. A lot of times, I work with styles, patterns, and architectures, I know I could do it better, but it's not my role to establish that and I must respect the hierarchy. Other times, there was no software architect and every developer created code in their style. It was very frustrating trying to figure out the bugs and trying to add or change functionality since every time I needed to figure out how things were being done, I needed to resist the temptation to erase everything and redo it my way.

Also, it is very common that the user interface (GUI) will have a mixed design and the user will find that grids and forms and all the parts have in different places — the fields,  buttons, messages, the way the data is validated in the same application; this is very unprofessional. So the first thing you can do to help you is the consistency principle. You can find it in this article.

This is only the tip of the iceberg and the beginning of a path on how to deal with unpredictable changes. You have to read a lot more and put in practice the concepts that I just mention. What can you add to this?