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.
Comments
WC, 27 February 2011 at 2:37 am
Good post! I chose the ‘bugfix’ position at my previous job because I really liked it. (Nobody else wanted it, though.) There’s a thrill in hunting down a bug and fixing it, and proving it was fixed. And the code is always better for it afterwards.
BTW: The input element for ’email’ is named ‘liame’ so non-programmers can’t submit comments.
joe Lee, 28 February 2011 at 6:58 am
Thanks for the post! It’s refreshing to see a varied view point to the typical attitude towards maintenance programming.
I completely agree with many of the points above, especially the point of “You’ll learn to value data and databases”, I think “backend” developers who say ” I rather not write sql” rather surprising since that’s what most data interactions with a data store boil down to!
I also think you can potentially learn how to program better as you may be expose to a better way of doing things, but at the same time you can be exposed to a bad way and pick up the same bad habit.
Manu, 28 February 2011 at 6:25 pm
I totally agree with all the points you have mentioned. If you are in consulting maintenance must be very lucrative. I would also say that a lot of maintenance work does get outsourced (for example development of the older releases of a product would get outsourced so the in-house team can focus on new releases). Many programmers might not consider maintenance as glamorous but it has several useful advantages mentioned in this post.
It is also worth mentioning that one should try to do a mix of maintenance and new development. Such a profile would be a killer profile. Maintenance will teach you how to write good code but new development will help you put into practice what you learned. Otherwise, that just remains good theoretical knowledge in your mind. I have been doing more maintenance work in a product development company (I sure do not regret it) and started looking for jobs at startups or young companies with small development teams. Such companies prefer that you have done more new development.