I like to say that there are two kinds of developers, those who deal with legacy code, and those that create it, and we're often times, both. Of course we don't want to be the ones creating legacy code, but how do we prevent code from becoming outdated, or unmaintainable?
In my opinion, the answers lies in how you choose to model, and evolve your project.
In this article I mean MVP as Minimum Valuable Product.
Lifecycle of a dead project
If you're like me, I'm sure you enjoy the feeling of starting a new project. Every new line down means great progress, and features are created in minutes!
However, as it progresses, adding new functionality becomes increasingly difficult.
Part of this effect is rightfully justified, as the project literally contains and manages more data, but if we don't actively look out we'll inevitably fall into the Unmaintainability Pit, and lead our project into an early retirement.
I've seen many times this happen, even with stuff I created... But throughout the years you start to detect the dangerous paths earlier and better.
Our goal, then, is to do work that decreases the rising rate of the effort curve, and this is what a fitting Software Architecture does!
Notice the word "fitting" instead of "good". There's never a one size fits all solution.
Preventing Early Death
This next curve is what the development of an enterprise-level software usually looks like. Initially we have to take on additional effort, but we can at least delay reaching the unmaintainable state.
Although there isn't a clear guide to achieve this, here's a quick rundown on what can be done to go towards this goal:
Take Your Time Modelling
Make sure your abstraction fits the business requirements. If you're working with a client, sit down and work out what are the business actors and actions, as well as the conditions required for each action, and their outcomes.
There are frameworks you can use to build your understanding about a system. I used Lean Inception before, and have been recently taking a look into EventStorming.
Expect Changes
There's a reason software is called "soft", It is supposed to be changed and adapted, as requirements and rules changes over time. This means your modelling should take into consideration what kind of processes are subject to more frequent changes, and what kind of new data they may require to function.
In code, this means you must have clear separation of concerns, so future changes are less likely to require scattered changes throughout your code base. Clean Architecture is a certified classic for this subject, just remember to not overdo it in the wrong area and end up with Enterprise Edition FizzBuzz.
Document the Process
You should write down the business processes, save any diagrams you made, and how it translates into the code. The process of writing is good for both making sure you understand the concepts, and also often brings up some inconsistencies in the process that you didn't realize there were before starting to write.
This one is specially true for teams, but still applies for you if you're on your own. Believe me, you won't remember parts of your software months in, and It will come back to haunt you.
MVP Architecture x Planned Architecture
If you're this far, you probably realized that in the end there is always effort, but you can choose to have it upfront and increase of the project's longevity, or be speedy first at the cost of maintainability later on.
The decision of which path your project will take boils down to two questions:
- How fast do I need to iterate? (Need to quickly adapt to testing the market?)
- How thoroughly do I know the problem I am solving? (Domain Knowledge)
The answer of these questions will make you land somewhere on this decision compass.
Iterating on Architecture Itself
Of course, not everything is set in stone, in terms of your architecture. You can still pick for a fast initial iterating time, and improve the architecture when you see the need.
This is actually what I've seen experienced developers do. Of course, this is not easy as well, because you will need to pick the right abstractions at the right project maturity time. Nonetheless, it is possible and a skill you can learn.
Just be sure to take action before the "Project Maturity Point", or your project will likely not launch because you didn't iterate fast enough, or be legacy code you will need to fully replace.
What I'm doing in this front
I recognized this problem early in my career (not that I'm an expert), and came up with a project that I've been working on for the last 4 Years. If you liked what you've read, you'll probably like it as well.
Meet Meta-System, The Everything Framework for Efficient Developers. It is a data-first approach to software architecture, reducing the need for duplicated code, or increasingly complex architectural setups.
You can join its discord server for talking directly with me and for clearing any questions you might have, and even contributing if that's more of your thing.
Top comments (0)