Today, I read an article that listed the main phases of development as:

• Development
• Testing
• Code Reviewing
• Deployment

Without getting into Testing and Code Reviewing being the same thing, this list (just like the coffee mug that decorates this article) missed the most important phases in the Software Development Life Cycle (SDLC): Design and Maintenance!

Analysis and Design are critical to the success of any software development project. A properly planned and designed makes all the other phases a lot simpler. It's all about measuring twice and cutting once.

Maintenance will (ideally) be the longest of all the phases and (hopefully) the one that requires the least interaction... but that's rarely the case. I have been in big projects that lasted for decades and diverted considerably from the original scope... getting most of the code done during the "maintenance" period.

The Forgotten Phases

While forgetting these two phases may be seen as a simple thing or a slip of the mind, it reflects a common trend.

Software developers have skipped design and rushed into coding since programming existed. That's not new. Plus, developers often join a project halfway through development when the design phase has already been completed. So, forgetting or diminishing the planning phases would be "understandable."

But forgetting about maintenance is a big one. And it is boosted by a modern culture: with many projects lasting 1—3 years, and many developers' tenures being in the 2—3 years before jumping to greener pastures, software developers often don't have to worry about maintenance or deal with the consequences of the software they developed (many times without a proper design!)

The Importance of Being a Maintainer

This is a problem because maintenance is an excellent source of learning for a developer. It is an eye-opener. Especially for young developers still in the "my code is perfect and unstoppable" stage (yes, all developers go through that at one point or another, and unfortunately, some never grow out of it.)

Working on maintenance —and on the maintenance of a project that you have developed in particular— and dealing with the results of our own coding and the mistakes we made can be revealing.

There is a lot to learn from courses, videos, and articles, but the lessons learned from dealing with your errors are priceless and will teach more (if you are receptive) than most tutorials.

Development is fun and, like with most fun things, it requires some beforehand preparation and some clean-up after it is over. A party with poor planning will be boring and, without proper cleaning afterward, would leave the house dirty and unusable. Developers working on a project and not doing maintenance are like the party guests that arrive late, have fun carelessly, drink all the beverages, drop all the cups, and are the first ones out, leaving a mess behind for others to clean up.

Makers and Cleaners

Unfortunately, from my experience at the corporate level (which is nothing more than anecdotal), this happens way too often. And it ends up separating developers into two groups: the "Makers" and the "Cleaners." Makers will mainly be involved in the development and sometimes in planning and design, while Cleaners will be principally engaged in the development and maintenance.

Makers will grow faster within the organization (the part they do is shiny) but slower as developers (they move fast and break things... which other people will fix, so they may not even know they broke things.) Cleaners tend to be more experienced, patient, and undervalued within the organization... even when they are the ones keeping the project afloat.

Cleaners produce the same or more than the Makers. Still, their contribution is often overlooked because it happens during the "ugly" part of the project after everyone has pat themselves on the shoulders and celebrated a job well done, and the "stars" have been promoted or left for another shiny project... or, more often than not, to another company.

Eventually, most Makers become Cleaners. But until then, finding a balance between these two groups is essential for the well-being of the project and the company.

Conclusion

I won't advocate for staying at a company just to do the maintenance (you have to do what you have to do, and if companies don't value you, that thing is leaving). Still, an increasing generation of developers is growing and learning and living development without maintenance, which is a problem, too.

By skipping maintenance, developers are missing a significant educational period, which will slow down their progress and limit their capabilities in the long run.