Phillip Trelford's Array

POKE 36879,255

Legacy Hiring

Over the years I’ve been involved in a lot of developer hiring. Here I’d like to share a pearl of wisdom I gleaned from a colleague I shared the hiring process with.

Their angle was to give extra points to people with experience with both building AND maintaining systems, i.e those who stuck around long enough to understand the consequences of their own actions.

I found this is an interesting insight, the logic being that you learn the longer term impact of your design decisions from hanging around to fix the faults and add new features.

But what does staying the distance actually teach you? I think the only real way is to find out for yourself, but here’s a few things that spring to mind.

Prefer simple

Simple isn’t easy, there’s an old saying that goes “I didn't have time to write a short letter, so I wrote a long one instead”.

The same goes for code; finding the underlying simplicity can take significantly longer than just bashing out the first thing that comes to mind. However the long term payoffs for system maintenance can be huge.


Tests can be a good thing, and test-driven development (TDD) can provide a helpful suite of regression tests to move forward with. However if the end result is tightly-coupled tests then the the pattern might be better coined Test-Driven Concrete (TDC), as instead of making change easier the product becomes almost impossible to maintain (thanks to Ian Johnson for the metaphor).

Instead of testing at the class and method level you should be testing required behaviour.


If you’re embarking on a big shiny new project, it might make sense to have some developers around who’ve been through the mill and come out the other side, and can help guide you to a more maintainable future.

Do you have any tips to share?

Comments (2) -

  • Roger Lipscombe

    6/17/2015 6:36:34 AM |

    Logging and metrics. You can't figure out what went wrong without the logging, and you can often not notice that there is a problem unless you have metrics. Plus, you can compare last week's metrics with this week's and see if you broke something.

    If you're building something big, some sort of introspection is good too. These days, I'm doing Erlang, so I can get hold of most of it via a remote console, but a REST endpoint that lets you ask what the system thinks it's doing is useful in any language. If you're using .NET, you can put something together using (e.g.) NancyFx really easily.

  • Martin Jensen

    6/22/2015 1:43:47 AM |

    Responsibility! I think this is a "skill" that is hard to quantify and if overlooked, can lead to a range of issues, including bugs and technical dept. I'd rather hire a developer with high responsibility and lower technical skills, than a developer with low responsibility and high technical skills. Because I think in general that it is easier to learn the technical stuff than taking responsibility for your actions.

    Responsibility might be "learned" if a person has stuck around to the maintenance phase of a project. But this is not guaranteed.

Comments are closed