Many people view software maintenance as tedious, boring and ultimate penalty rather than a challenging and interesting job. And in fact, maintaining an old body of code can be painful and depressing. There’s so much to make you bang your head against the wall: bad programming style, wrong design decisions, stupid bugs and lots of areas where you simply don’t understand what for or why the heck somebody wrote such terribly bad code.
On the other hand, changing existing code, improving it, adding functionality to a running system can be fun and very satisfying. And there’s even some chance that there are hidden gems in old code. Something you can learn from people with lots of experience and good coding habits. It’s a challenging job to try and find out why certain deicisions were made as they are, and very often you’ll find out there once were good reasons for why something was done in quite some complicated fashion rather than in an obvious way.
So constantly being on an edge between breaking code and improving an existing system can be seen as dangerous and rewarding at the same time.
Being a young programmer, stuffed with only fresh ideas and little useful advice on how to write real software, it is surely a good thing to be put into a team with experienced developers. There’s so much to learn nobody ever told you and maybe nobody ever will.
So I think a new programmer should start maintaining a running system. They had a lot of time doing fresh development already during their education, and now it’s time to learn the rough edges. They should be given the chance to break an existing system. More than once. Because that is how you really learn to really be careful and not to judge existing code too fast.
Having to read and change crappy code does two things: it shows you how important it is not to write crappy code, and you’re forced to respect code. This body of code may have done it’s job for years, no matter how badly written it is. So it’s worth trying to be understood.
If you don’t handle it with respect, it will take its revenge: it’ll break and give you a hard time solving trouble tickets.
Putting new programmers into a think tank (where they presumably cannot break much) is no good for anybody. They won’t learn to understand the code in your organization, and they’ll write code that will be hard to understand for you. They won’t learn much and chances are they’ll simply write a system that’s completely out of spec. And they’ll have to learn things the hard way anyways, just later, when it’s probably even more risk to your project.
So I think young developers should start in a maintenance project rather than some fancy new strategic project.
We should resist the promise of “The young guys all can do Java a lot better than we can, so they should do the fancy new Java project while we maintain the really important core systems”.
Funny enough, chances are that if you bring the young into maintenance projects, the old guys will learn a lot from the young about newer concepts and tools that could make their jobs easier, and the young will learn a lot about how software is written in your organization. They’ll soon understand that you’ll have to accept bad code and weird decisions as long as they don’t fully understand the consequences of changing them.