Am I alone in enjoying "adaptive" and "perfective" code maintenance? Dashing off new code is fun, but making bad code into good code is immensely challenging and satisfying to me.
I think it's hard to write beautiful code straight off -- it very rarely happens to me, anyway. So for me, writing beautiful code is mostly perfective maintenance anyway -- or do I misunderstand?
Agreed. I love cleaning out warts, fixing broken APIs and removing unneeded code. I love looking at the output at "git diff --staged" seeing lots and lots of red and very little green.
But that's just me - any maybe other developers in my team. For everybody else - marketing, sales, customers, end users - this is completely irrelevant. Nobody really understands this kind of work, much less actually sees a value in it.
Adding a blinking logo somewhere and you're the hero of the day. Exchanging 500 lines of bad spaghetti with 20 lines of beautiful art and you're wasting everybody's time.
But because I love this kind of work so much, I don't care. I'm in a position where I can do such things for fun an pleasure, so I'm doing them.
I like it, because I seem to have a knack for it and mostly because I enjoy working on things that no one else wants to touch. It's nice to have a degree of autonomy and not have to deal with working on a big team, even if it means not getting to work on new things.
Fixing old code can be a very satisfying experience. However this is usually tempered by management apathy for code maintenance. It's an invisible problem; nobody can see when you fix a piece of bad code unless it's causing a bug. This becomes aggravated when "25% of the people doing maintenance are students and up to 61% are new hires".
To management it's, at best, an "if it ain't broke don't fix it" attitude. At worst they consider programmers prima donnas. It's immensely frustrating trying to convince them of the utility of code maintenance, even when doing so pays dividends in future feature development flexibility and bug fixing.
I would love to see some strategies for convincing management of the virtues of maintenance.
You do that by understanding some of the tradeoffs involved and showing that you understand that maintenance for the sake of maintenance is usually a waste of time.
* If it was causing some immediate issue or had a bug that needed to be fixed you could justify it that way, but all too often someone wants to refactor something to make it "nicer"
* Code that's rewritten is going to have all new bugs of its own, those are going to end up wasting more time than the time spent on the initial rewrite.
* A lot of programmers will get the urge to rewrite something before they fully understand the system they're rewriting (and thus aren't qualified to do so). You might be 90% through rewriting it to be nicer only to discover that the remaining 10% doesn't fit with your design. There was some design requirement that you missed which caused the initial code to be so convoluted and "nasty" in the first place, because it was solving a tricky problem in some non-obvious way.
* In a growing business requirements change all the time, maybe you'll spend 6 months now rewriting some system to be nicer, but 2 years down the line it turns out that that system was inherently broken and has to be thrown away and replaced. So it would have been better to commit 1 month of time over those 2 years to keep it on life-support.
* Speaking of resource allocation: Is now the right time to do this, you probably have a 100 tasks with manpower to accomplish 10 of them. Maybe this is better done in half a year when you have more hires, or not at all if some of those other 90 things are more important.
But finally, if it's really the right thing to do just do it incrementally as part of other tasks. If it's really code you're working on all the time, and fixing certain issues saves you time down the line just make those fixes along with other tasks.
The only time I perform maintenance is when I'm adding a new feature. Before I add any new code I'll inspect the code that will be touched by the new code. If it's hard to understand or the abstractions are a bit wonky for what I want to add then I'll spend some time refactoring it. In this way your maintenance work is always done while delivering observable value to the business. You don't need to provide any justification for it. If it means you're going to take a bit longer to deliver a feature than expected you can just tell your boss that the code wasn't in the state that you expected when you gave an estimate. If you wrote the code in the first place it's fine as well. You can just say that the priority at the time was to get the feature out fast so there wasn't time to shine it up.
Refactoring is important and management should be convinced for this. Most managers also insist that the (physical!) desktops are kept clean. For the same reason code bases should be kept clean. The reason in both cases: Dirt slows down in the long run.
Thank you. I can never write the code I want first time - I always end up creeping to a solution, being unhappy with the way it works and so trying something else till it all fits right.
Give me a giant codebase I've never seen before that started bad and turned into a spaghettified mess, and you'll have a very happy developer on your hands :)
I now enjoy it, but from my understanding, it depends on the attitude the team and management has towards it. Maintenance during the earlier phases of a product is also very different from doing it in the very late phases, when you know all your efforts are going to just delaying its inevitable death.
All coding efforts are just delaying the product's inevitable death. Software lifecycles are shorter and shorter. A style of shoes has more staying power than most software.
Once at a wedding dinner in Asia I got in a lot of trouble for describing my job as "computer janitor/computer fireman". The table was filled with with people in my same line of work who where very proud of their jobs. My comment/silly joke was not taken nicely and got me into the dog house with the wife (Asian) for a good while!
Since then I've been proudly describing my job as software gardener.
Absolutely. One of the most satisfying tasks for me is transforming a big steaming pile of spaghetti code (be it procedural or, more often these days, design pattern infested OO code that involves a dozen classes just to print "hello world") to a simpler, elegant codebase with half the LOC.
same here. it's not only immensely satisfying, but you are guaranteed to have something beautiful to show for it without having to worry if the product itself is going to be worthwhile.
I think it's hard to write beautiful code straight off -- it very rarely happens to me, anyway. So for me, writing beautiful code is mostly perfective maintenance anyway -- or do I misunderstand?