In the old days when I started programming, green programmers trying to build their skills and get experience started out doing maintenance programming. Only the old hands got to write new code. The newbies cut their teeth debugging and fixing musty old code that still worked for the business. I’ve done my share of new development, but today I do maintenance programming almost exclusively. After working on way too many failed ground-up “green fields” projects I prefer to debug, fix, and enhance production software. I like working with real users rather than making up “use cases.” I prefer building confidence and making my clients happy with my work rather than arguing with them about features, specs, budget, and schedule. I like having a prioritized list of well-defined tasks that refer to existing code rather than trying to blue-sky specifications. I like charging by the hour instead of by the project, and not having clients balk at my rate.
I mainly work with web applications now, and I specialize in database-backed web sites. I rarely take on new development projects, but I frequently get called to salvage projects that went bad. Clients fire their developers (and vice-versa) leaving production code orphaned. Developers put their energy into new development and don’t respond to bugs or enhancement requests from old clients. I charge by the hour and I get the job because I don’t tell clients they need to throw everything away and start from scratch — something they get from other consultants.
Software often stays in use longer than anyone expected when it was written — until recently I supported a law office billing system that was written in 1986 using OMNIS 3 and wouldn’t run on any Macintosh newer than an SE/30. Clients who depend on legacy systems will pay plenty to keep those systems running, because they can’t risk their business on new software, and they can’t afford to fund new software development and the subsequent data migration and training. There’s a rich vein of maintenance work out there that most programmers turn up their noses at, preferring ground-up development projects that neither they nor their client are well-suited for.
Some of the benefits of maintenance programming:
You’ll learn how to debug
Debugging someone else’s code requires more effort and rigor than debugging your own. You have to track down problems step by step; you can’t assume you know what’s wrong and jump to a quick fix. Reading and debugging foreign code makes you think about how the code works (or doesn’t) rather than what you think it should do.
You’ll learn how to program better
You can debug and extend good code easier than bad code, so you will learn how to tell them apart. You will have to reason about the code and deduce the original programmer’s intent. Skilled programmers recognize what makes good code good, and what makes bad code bad, and working with lots of code will impart that skill. You will develop a knack for finding your way around an unfamiliar code base and recognizing bad code smells.
You’ll learn how to optimize
The original programmers already made the premature optimizations, so you get to identify and fix real efficiency problems and performance bottlenecks. Ground-up development project teams often spend a lot of time and energy worrying about performance issues that may never materialize. Working systems have real, identifiable performance problems. Finding and fixing performance problems can be fun, and it’s a great skill. Clients always notice and appreciate you making their application more efficient.
You’ll learn new (to you) skills and tools
You may not get to work with the language du jour, but you will get to learn languages, libraries, tools, and production environments you probably wouldn’t learn otherwise. You’ll find a lot more work involving common, mainstream business tools. Ground-up development projects often bog down just deciding which language and tools to use. You won’t have to make those decisions, sell them to your client, or get blamed for them. You’ll spend time learning some obscure and proprietary tools and languages, but those can pay off too. Larger companies with their own IT departments do their own maintenance work, but often hire contractors with specialized knowledge and experience.
You’ll learn to value data and databases
Applications still typically follow the input -> process -> output model from old data processing textbooks. You have to understand the data and how it moves through a system before the code makes sense. Almost all applications use a database of some kind, usually a relational database management system (MySQL, PostgreSQL, Oracle, SQL Server, etc.). A skilled programmer knows relational concepts and how to navigate a production database. Not understanding databases cripples programmers and leads them to write lots of bad code to do what the DBMS should handle. I frequently refactor pages of slow, buggy application code away by replacing it with SQL.
Clients will appreciate everything you do
Every bug you fix and enhancement you make improves an application people already use. Real users will notice the changes and give immediate feedback. When you develop new software from the ground up every spec change, delay, and additional expense can cause conflict with your client. When you address actual problems everything you deliver makes your client happy.
You will have better specs and clear constraints
Fixes and enhancements are smaller and better-defined tasks than ground-up development, and the existing code and environment constrains your choices. You have to focus on solving a real problem. You and your client can agree on the tasks with less chance of misunderstanding. With new clients I build the relationship by asking them to list just the top five pains they have with their software, then I offer to fix those, and promise not to charge if I can’t.
Easier to walk away from bad clients
We all get involved with clients we don’t want to work with. It’s a lot harder to get out of the relationship if you have a contract for a big development project, time and money invested, and the big expectations clients always have for new systems. Maintenance work is shorter-term and the tasks are smaller, so you have more opportunities to terminate the relationship without breaking a contract or either side losing money.
Agile by default
Fixing bugs and making important enhancements let you work in agile mode without having to sell a methodology to your client. They will want things fixed right away, so you can make incremental releases, collaborate with real users and get immediate feedback, and work with a few bite-size tasks with a defined finish line.
You’ll learn about business
By definition, production software addresses at least some real business need. Learning how it does, and does not, work for the business, and working with real stakeholders familiar with the software forces you to learn something about the business. Knowing something about business applications will boost your career more than learning a new programming language.
You’ll learn people skills
Programmers in ground-up development mainly work with each other. New systems don’t have real users; instead you get use cases and management stakeholders. Maintenance programmers get to work with real users, often the people on the floor who work directly with the application and experience the bugs and where the software doesn’t match the reality of their job. Learning to listen to and talk to people who don’t have the same assumptions and culture of programmers broadens your perspective and gets you out of the programmer shell.
You’ll get follow-on business and referrals
Who do you think gets more repeat business and referrals: a great car salesperson, or a great mechanic? People need their software fixed and enhanced more often than they need a new system developed. And your satisfied clients will send referrals your way because they have friends and colleagues who have broken software systems too.
Your work won’t be off-shored
But you may end up maintaining the results of your client’s off-shoring experiments.