Something came to me the other day when thinking about software development. Developers usually want to work on "new development" rather than "maintenance". Maintenance is usually thought of as dealing with someone else's shit. But what is maintenance really? Isn't it just fixing bugs, adding features, making it run faster? What's new development? Isn't it just fixing bugs, adding features and making it run faster from the previous iteration? So what's the difference? I don't see any. I think that the difference is just perception of the problem.
It's a perception of new development that you can hack it till it works, toss it over the fence to someone else to maintain it and fix it. How do we fix that? Maintenance starts on Day Zero. You expect that at any time you are going to pass it along to someone else to maintain it, or you will be "stuck" with doing it yourself. That's one of the benefits of writing tests, specifically unit tests: you are always in "maintenance mode". If we can get rid of the idea of being able to hack and have someone else being responsible for it later; if everyone takes a long term view of software; I think that software over all would be in a lot better place than it has been in the past.
Maintenance is dealing with other peoples shit. It mostly has to do with fixing other peoples bugs, or adding little features to a giant monstrosity of spagetti code. New development means that you get to write new code, with new features, while not having to work too much with someone else's spagetti code. You usually have to deal with someone else's code a little bit, but hopefully not too much.
ReplyDeleteDoesn't that go against collective ownership? Isn't your comment just what I said is *bad* about the current perceptions and how it doesn't do anyone any good long term (or even short term)?
ReplyDeleteIf you don't want or can't work on code the guy you are sitting next to has written, what luck will someone 6 months or a year from now have?
What good does it do for anyone if you let someone on your team check in "a giant monstrosity of spaghetti code"?
How can the nasty cycle stop without someone making sure spaghetti code just *doesn't happen*? How do we get rid of the role no one wants?
My post was about making everyone look at what they are doing as maintenance so that you are always getting the project in a state to hand off to someone else. It's a "do unto others as you would have them do unto you" kind of thing. It's about future proofing your work as best that you can. It's about shorter turn around time for features and not having to have the whole application in your head to make changes. It's a random thought about how to make software engineering better.
The whole "handing off" to maintenance mode is an interesting phenomenon, made worse by the Internet "bubble".
ReplyDeleteWhen companies were trying to recruit top people, they promised these people they would be writing new code all of the time because taking care of their code is less fun. Thus, the hand off. Now we've got that attitude that "handing off" is a normal (and correct) thing to do, and it certainly is not.
You learn from your mistakes much better if you have to fix them yourself. At the same time, you are much less likely to make mistakes if you have to fix them later. People take more care, are less sloppy and actually have *motivation* to unit test, since unit testing cuts down on the number of bugs they'll have to fix later.
If they have less bugs to fix later, then that person can work on new features and their job will be more fun! Nice cyclical motivation.
Wonderful work. I enjoyed read your site a lot.
ReplyDelete