If you’ve ever worked in a service industry, you’ll have noticed that there are many people that just do their job. They go to work, do what they are supposed to, collect their paycheck, and punch out at the end of the day. They fill a role, and they do well at it. They stay out of the spotlight – their ‘off’ time being their fulfilment, and the job being an ends to a means. The same holds true in the Software Development environment.
Software stacks are large these days. Well, at some startups the code base is still growing, but even their, the open source code being referenced is quite large. Now, it’s great when a developer / architect can build and design these larger complicated systems. But as time goes on – new things don’t need to be built out so much as in the past. Sure, things like GDPR can wreak havoc on websites, but for the most part, code bases are pretty stable.
An example of where a Maintenance Master is most suitable: Imagine a stable codebase which doesn’t need to be completely re-written. It needs to be maintained. Minor to Major bugfixes, improvements, business logic changes – these are common maintenance items. This type of work can be well planned out, well tested, and scheduled. Which makes it the ideal scenario for Maintenance Masters.
Being able to keep a code base alive and relevant is no small task. Knowing the reason for business logic implementations. Having a history of decisions. Doing all this without checking the Repository history or checking the resolved tickets list is a huge asset. In addition to this, they are great at sticking on a problem until it is eventually resolved. They’ll guard their area of expertise and are predictable about the deadlines they can meet. Sometimes they’ll explore new ideas or concepts – but they are largely happy with the status quo. They are able to churn out a lot of code – but it’s going to be the same code style repeated in every scenario.
- Knowledge Stores
- Produce a lot of code
Being able to stay on a single project or code area for a long amount of time might be great – but it is countered by being unable to see larger solutions or newer approaches that can clean up the code. For example – the DevOps movement has put a huge dent in the abilities of maintainers. Now, their entire process must be revamped. This in turn causes maintainers to become disenchanted with their code or their company – and often will result in their departure for a more stable opportunity.
Not being a part of the huge ‘go getter’ mindset, maintainers don’t typically go way above and beyond the job description. They aren’t typically looking for a promotion and often watch others pass them by. They’ll sometimes get stuck maintaining a failed piece of code without realizing a refactor would be more useful in the long run.
They also sometime lack in their communication skills. They know their job – they expect you know yours, and they don’t anticipate communicating what they are doing outside of what the process makes them communicate.
Managing a Maintainer
There are some obvious do’s and don’t’s when managing or leading a maintainer.
- Keep their work planned and organized
- Give them an area to own
- Give them some autonomy
- Keep their environment stable
- Provide early notice for large changes conceived for their area
- Use them to train new people
- Haptic switching of their projects
- Expect new ideas
- Promote them to architect positions
- Use them to interview
- Push them outside of their comfort zone.
Maintenance Masters are an excellent piece of a development team. They will keep the lights on and things stable. They won’t push much of a changing agenda – but they will get things done. If you blame a code base, you’ll find their name dispersed through a file – not as an originator, but as an editor. There is absolutely nothing wrong with being a maintainer – however – if you are one, and you want to move into management or leadership, you’ll need to step out of your comfort zone.