Engineering

Mender First

There’s a popular misconception that all programmers love building shiny new technology; looking for excuses to use the latest and greatest framework or language.

They prefer working on new “Greenfield” projects. And I’m sure that’s true of a fair number. They would probably self-identify as a Maker. Conversely, there are those who Andrea Goulet labelled the Menders —those who love the art of maintenance; finding and fixing bugs, focusing on security, stability, scalability and so on. In her article about the differences between maker and mender, she argued that you need both types on your team. While I agree with the premise, I think that there is more to the maker/mender divide than she discussed.

Having people on the team that identify closer to one end of the spectrum or the other is a good thing. As a leader, I think you have to cultivate a healthy tension between them. Technology is continually moving forward, and it’s necessary to keep up. The makers will tend to argue passionately for that, while the menders will help to keep it in check, making sure that technology isn’t chosen for its own sake but still provides the needed functionality without compromising on security or stability.

The thing is, back in 1999 (and I’m willing to bet it goes further back than that) in the Pragmatic Programmer, Dave Thomas and Andy Hunt argued that practically all programming is maintenance programming. Andy Hunt said _”It’s only the first 10 minutes that the code’s original when you type it in the first time. That’s it.”

By that definition, every programmer is a Mender. But as we’ve seen, some people identify themselves differently.

My take on it; with maybe a few exceptions, programmers are capable of both mending and making equally, but generally, since making is considered to be sexier and mending is thought of as dull or janitorial work, then most people want to be doing the sexier, fun, “making” stuff. Jeff Atwood discussed this at length back in 2006 in the noble art of maintenance programming. He argued then that the best programmers should be doing the maintenance work; new projects are “easy.” Anyone can bash them out, and then they get bored because it becomes hard. It devolves into a mess because the time, thought and care wasn’t put into it at the beginning, and the developer doesn’t really have the skill or practices to keep it maintainable. That’s when you need the Menders. Developers with the skills and discipline to maintain high levels of performance, even under tight deadlines and constraints. Ideally, the best developers will also act as mentors to ensure that better practices prevail over the long-term.

I believe we need more developers working with a Mender First mindset. We have to find ways to remind them that, in fact, they are always in maintenance mode.

Need some help with your team to implement better practices to cultivate a Mender First mindset or looking for more Menders to augment your team? We have been developing and maintaining Ruby on Rails-based applications for clients who care about the long-term maintainability of their system for over 10 years. Contact us to discuss ways in which we might be able to help you.