maintenance support coding

andrew moore has an interesting piece that i found on reddit tonight and it points to why supporting code that someone wrote is the best place to be a 'hero'.

citation one:

If you outperform stagnant, you're a hero

ok - let's be honest here: only egomaniacs are into being a 'hero'. while you, as the coder might think that when you refactor someone else's code you're being a 'hero' - the fact of the matter is that you are very close to being an arse.

what mr. moore should have provided is the caveat: make sure you understand the code that you're about to refactor.

at one point in time i was working with a development team and the new coder decided that he was going to be a 'hero' and refactored some code that:

• wasn't in the functional design
• he didn't understand
• related to a business function that was rarely used

so he 'refactored' the code and broke functionality at a third stage approval process when the application was in the final stages of being approved. i, as the testing co-ordinator had to take the results of the tests and show where the previous beta compiles passed a particular function and why the 'final' version did not.

the project manager took this to the developer and suddenly there was found a 'bug' that was 'dormant' in the code and was 'only found when the final tweaks' were made.

it was pretty obvious to one and all where the source of that 'dormant' bug had been and it was the last time that developer handed in a product that had any 'features' that were not explicitly called for inside the functional design.

so, for all you rockstar developers who are bone certain that you know what you're doing, i have a simple suggestion for you: don't be a hero.

all too many times, the 'hero' ends up being a 'zero' in the eyes of everyone else around them because their either look down their nose at the other coders who are doing their very best - or they are setting themselves up for one of those career destroying errors.

heros are an epic fail in a team work situation. if you want to be a 'hero' you can't be a team member.

citation two: Sometimes when I look at an installed base of code, I find places where there is useful information that is not being exposed. The database knows some statistics about the business that are not being given to decision makers. Sometimes this wasn't done before because it's not obvious when something is being built what kinds of statistical information it will collect. Sometimes it's not done because it's just not the lowest hanging fruit (yet).

ok - this is boderline stupidity clear and simple.

developers are not paid, nor are they often wanted to 'optimise' the decision making process. leave that to those that wear the ties, have the blackberries, and are on the giving side of the layoffs.

a developer's job is to write the code that they are given. the business analyst is the one that is to decide what and how the code should be written.

all a devleoper that writes 'heroic, groundbreaking code' is showing is that they have way too much time on their hands. their manager won't really like it - and all the managers that had been making decisions based on the previous iteration of the code won't like it either.

it goes like this: the sad truth is that ninety percent of the time when your boss asks you what your opinion is, if you're like me: you have to keep your mouth shut and just give him back what he or she is looking for. i've seen too much heartbreak because i answered honestly what my opinion is about a situation or to provide a solution.

if your solution is radical enough then they'll file you as a nutcase.

if you give them the same brain dead options that they came up with while they were on their power lunch with their friends - then you'll probably be able to keep your job during the next wave of layoffs.

heros are zeros in the business context because they alienate their coworkers.

'innovative' solutions are only looked for from coders inside start ups.