Why do all good developers usually end up creating the first version of a project, but as soon as it goes to production, we get a "secondary" team, usually with less experienced developers, maintaining it?
I think it is because the act of creating a new piece of software is seen as an art (at least by those creating it), whether maintaining it doesn't. As such, it is logical that you need the most creative ones, the ones with more experience to do it, so they can pick on what they've learned and apply it to the new project.
The fact is that if a developer participates in a project and, as soon as it goes live, he moves on to the next one (and this happens a lot in the software consulting business) you'll end up with someone that doesn't really know what it is like to have a system in production. How can he know that a "real system":
- requires the correct (not too less, but not too much) amount of logging, auditing, performance...
- has data, tons of it, always much more than what we expected/planned for
- requires some "circuit-breakers" in those special places so that some minor bug does not bring the whole system down
- needs refactoring, grows with refactoring, and that you need to look into all the existing data so that your refactoring is backward data-compatible
- actually has users, demanding users, sometimes those that never sleep
On top of that, a "maintenance developer" needs to do all of this... and on someone's else code. They need that special capability to reverse engineer a requirement just from the code, understand what the heck the guy who did it was thinking, and still cope with the users demanding fast change because the system they use all day is burning. These are the special artists!
I have one rule: when interviewing someone for a senior position, ask him how many systems has he got into production. You'll probably hear a number that goes up to 50, proudly. Now ask him how long has he maintained those systems in production. If he has no experience on that, I do not consider him a senior. Just as simple.
For consulting projects this is just as simple. If you're building software products there is one difference. If the products goes through several versions, these concerns become shared knowledge. Both teams (the ones doing maintenance of existing versions and those creating new ones) usually work in sync. There is even some rotation between them so they all go through the same set of concerns. If you don't have it on your teams... you should.
2 comments:
Hi Gonçalo, I understand your point and I'm agree with it. Obviously, It is a requirement for a senior developer to have some background in Software Maintenance area. But, when interview someone I wouldn't be so radical ... at least in Consulting it's hard to believe that someone who had an important role at development phase finishes his relation with the project before the steady phase is reached. This phase is not considered Maintenance but usually has the some problems has the next phase multiplied by 10.
Hi José,
Thank you for the comment.
I am not that radical in what I consider "Maintenance", just radical in terms of what they were able to learn from a production system. I actually need to understand if that actually happened. A post production phase is not the same as a maintenance, mostly because, as you mentioned, the problems in that phase comes multiplied by 10. It is common (and imo actually understandable) that developers, for instance, in that phase are so stressed out that they do not have the ability to step out, look from above, and learn from that experience. That phase also doesn't gives them the time to look at the process, understand it, optimize it, and take the good stuff to use in the following project.
That's what usually leads software consulting companies into reinventing the wheel project after project (there are many other factors of course). A senior guy is able to demonstrate this ability, whether in the post-production/tuning phase or a maintenance phase.
Cheers
Post a Comment