Search This Blog

Loading...

Thursday, November 29, 2007

Writing Maintainable Code Considered Harmful

The boss has a new assignment for XYZ. He calls XYZ into his office. His face is grim. Just as XYZ 's seat barely warms he breaks out a news to him, with a panicky tone: "Mr. XYZ, ABC is leaving our company next month, so I'll assign you to take over his responsibility. You know, we need to push our software out the door next month also, so I need you to cover his code as much as possible. Please, our financial future is depending on this product, so make sure you don't blow it! "

Upon hearing the news, XYZ is startled and overwhelmed. ABC is a star programmer, that's what everyone thinks. And now he's leaving now? Just before the software launches? Is he nuts? He works here for a full 5 year, starting from day 1 when the project was initiated, and now...and now he's leaving everyone else behind?

The project that the team is working on is a huge one, and a hard one as well. Throughout the 5 hard years, there were constant specification changes, numerous false starts, financial setbacks, threats of uncertain project sponsorship etc. Despite this, all of the original team members-- and that include XYZ- stayed together with one another. There were many storms the group weathered through, many disappointment that the team faced together, until now.

Working with someone for 5 years, XYZ knows ABC is a highly efficient and smart programmer. He beats everyone to dust in every conceivable metric, including the number of lines of code written, number of features churned out and the volume of applauses received. He's just damn smart, so smart that no one really knows how his code works. No, he doesn't bother to do unit test, saying that unit test is taking away his time, so this makes his code extra mysterious.

Now XYZ needs to cover the genius' code. It's an uphill battle.

Because ABC is going to stay on for another month, so he transfers his knowledge to him. But ABC code is very hard to understand. He needs to explain his logic over and over again. And he is quite pissed off with XYZ's inability to grasp his points. Finally, both of them give up. As long as the thing works, who cares!

And so.. ABC leaves happily after a month, and the product launches at the same time. The first few days are OK, the response is overwhelming positive. Everyone loves about the product, everyone talks about it. Even those who don't need it also buy a copy because it is considered unfashionable not to have the product.The team can't stop congratulating themselves, and some of them even start to believe that they are the next Bill. Even ABC, who left the ship is also receiving glowing recognition. Everyone is happy.

But good fortunes don't last. After a week a customer calls in, complaining that the mouse isn't moving after a few clicking. Then another customer calls in, saying that the app crashed in the midway of operations, and brought down the whole OS with it. That was not the most serious problem, however, the most serious problem was at that time he was also working on his Microsoft Word document and had not saved the document for a long time. Nothing is immune from the Murphy's Law. The product is of no exception.

So all of the developers are now busy cleaning their own mess. The bug reports are now coming in, like avalanche. And XYZ is especially unfortunate, because he needs to fix two persons bugs. But fixing bugs are never easy, especially when one has to fix other people's problems. The codebase of the star programmer, it turns out, is a lot more awful than the kitchen of restaurants. His code exhibits the following characteristics:
  1. Long, winding methods
  2. Duplicated logics and methods, scattered all over different places. Worse still, these logics are convoluted, or written with little or no thoughts. Because XYZ finds that it is very, very hard to understand his code, but very, very easy to rewrite the logic in a clearer manner once you understand them.
  3. Bundle the UI with business or calculation logics. Even if one needs to only change a text box to a combo box requires massive rewrites.
  4. Incomprehensible or irrelevant methods name. Do you know what does the method "CalculateTwoValues" supposed to do?
  5. Optimization! One can see a lot of optimization tricks there. Instead of computing the area of a polygon on the fly, he did the computation and stored it in a variable and updated the variable whenever needed. The only problem is, he didn't update the variable all the time, resulting in miscalculation of area in some places and correct calculation in other.
  6. Obfuscation. You see, the star programmer is really someone who concerns about Intellectual properties. So, he persuaded the boss to obfuscate the .Net code using a third party tool. Not only that, to make sure that there is a last line of defense, he inserted a lot of incomprehensible but totally irrelevant logics to thwart the would-be hacker, just in case the obfuscation tool is not good enough.
  7. Hard coded values! This is the favorite. Instead of using a constant to denote a frequently used value or string, he litters his code with his magic strings and magic numbers.
They are just many, many more. The more XYZ understands his codebase, the harder his curse is on him. He can't stop wishing that the star programmer should stay on to clear his mess. XYZ feels like dying. The absence of unit tests means that XYZ needs to modify the code at his own risks. But the more the bugs are fixed, the more the problems surfaced. And the bosses, colleagues and users start to notice. To make things better, they start to notice XYZ personally. They start to compare the maintenance engineer and the original developer. Everyone is wondering how can XYZ be so incompetent. Only XYZ knows the truth. Only he knows that ABC's code is not thoroughly debug and poorly written. Only he knows that it is not fair to compare him to ABC and if such a comparison can be made, he's a better programmer in terms of bringing long term utility to the customers and the company.

After fighting the awful codebase for half a year, XYZ can't take it anymore. So he resigns in disgrace. But the damage is done, everyone knows him as THE spoiler who spoils an otherwise beautiful product. XYZ has a hard time to find another decent job, so he finally ends up sweeping streets for a living.

Meanwhile, ABC continues to thrive. He hops from one company to another, steps up the salary level, continues to write fast features and leaves the maintenance problems to others.

This strategy works very well for ABC. No wonder he considers writing maintainable code as harmful.

Follow up post: writing maintainable code considered harmful(2)

17 comments:

Mike said...

Wow. I have followed ABC before. It always amazes me when I see really horrible code that is horrible for the purpose of making it hard to maintain.

Mike

Soon Hui said...

Mike,

I think the existence of ABC is not so much of his problem, but rather, he might be lacking of proper education in software development. His manager should prevent such a situation to happen in the first place.

Jacob said...

Oh blah. Blame ABC all you like (there's certainly enough to blame), but XYZ brings trouble on himself by being willing or able to communicate. There's other developers at this theoretical shop. XYZ needs to learn how to ask their opinion and solicit their advice so that they are aware of what he's dealing with. It isn't like the code base is lacking clear examples of ABC's incompetence (since bugs are being traced back to his code). Seriously, no team works in that much isolation. If everyone knows XYZ as the spoiler chances are there's some truth to it.

And frankly, even if XYZ is the best coder on the planet, his lack of communication skills and inability to convince his team of his concerns is troubling enough that I'd question hiring him on that basis alone.

RobM said...

Blame XYZ for taking on the mess.

Blame the boss a dozen times for creating a culture where XYZ can't say "no" or "help" or "something isn't right here".

Blame the boss a dozen times again because when ABC asks for special consideration (avoiding unit tests because 'he's a star' and so-on) the boss didn't say "Interesting theory. No. End of discussion why are you still in my office?".

Esteban said...

I really enjoyed the story, but I have to agree with the comments, if everyone knows XYZ as the spoiler, then it was his communications skills the problem, every single time he found a bug made by ABC he should have told the manager what is wrong and what changes he has made in order to reduce duplication, clean code, etc. This way not only the manager starts noticing how useless most of the ways to measure programmer productivity are, but also will start appreciatting XYZ skills, and even better, he will become the new Star programmer. EVERYONE makes their own destiny.

Orry said...

I wish I could say I hadn't been in this situation. Sadly I have. In some cases _my_ ABC hadn't even left the company before I was put into the XYZ position.

In my role as a web developer, I've seen so many badly written sites that make stupid decisions internally that cause things to not work as they should, but for some reason have never been noticed until 6 months after the site launched.

Brian Silberbauer said...

I think most of us have been in this situation, but we fail to mention the most used protection script when taking over somebodies code:

Diss the previous coder as loudly and as often as possible, preferably as soon as the IDE has loaded or as you see security take his swipe card away.

Management won't believe you at first, but once the code starts falling over those subliminal messages would have found a place to roost, as backup, get somebody else to 'help' you with the code so that you have these messages coming from another source :)

And yes, I'm sure we've all been on the flip side of this too: as soon as you leave a company, there is a 'dumping' time when everything is blamed on you.

Anonymous said...

Very interesting tale that rings of truth. I was ABC until I had to rework some code I had written months and months earlier. Never again.

I don't know how many times I've been XYZ (especially as a contractor).

But the message I take home is to recognize that in a permanent gig this is going to happen. Period. Eventually. Therefore the thing to do is to lobby ferociously that ALL code in the group gets periodic reviews with the unstated message being, "there but for fortune will you soon be". If I think there is a significant chance I may be called on to take over Fred's code when he gets hit by the bus on the way home, I'll be much less inclined to let sloppiness slip by with a "I'll never have to worry about it" callousness.

Enjoy,

-pmr

Anonymous said...

I don't really see how writing unit tests would change the situation. All the problems you have mentioned with ABC's code would happen the same even if he would have covered it with unit tests.

Unit testing does not protect you from writing ugly code. It might help later to clean it up by somebody else, but at the point of ABC leaving the company, situation would be exactly the same.

fsilber said...

Yes, but even though it is easier (for most people) to write bad code than good code, it is easier to write and unit test good code than to write and unit test bad code.

Bad code makes unit tests hard to write.

Anonymous said...

This is exactly reality. This is exactly how the programming world works. A start up I worked for had to deal with ABC's code - they had a partnership with company B and ABC was the superstar who could do no wrong. Our startup received a deliverable from ABC - then they had to open the box and see what was inside. What was inside was exactly what you described- ABC's career strategy.

don't forget that ABC also uses his power as a superstar to undermine anyone and everyone around him who might compete for a piece of his status. He especially targets XYZ, the one who writes good code and because ABC is a superstar, he BS sticks.

Yep this is exactly how superstars maintain themselves and how XYZs get fucked. Of course, if XYZ starts complaining about the code he inherited, it's chalked up to XYZ's inability to deal with ABC's brilliance and end of story.

The only real solution for ABC's is to start off on their own and let the density of XYZ's in the industry increase. IF you're good, quit. One developer or three can deliver value to the market place and earn a living, so just do it. This is the industry eating itself alive, and it's a beautiful thing to see, even if it's a little slow - no instant karma here.

What I would like to see is a enumeration of the ways asshole programmers screw other programmers over. Seems to me it's mainly through political maneuvering, character assassination and hording of knowledge.

You little story is truth in a nutshell. The long term effect is- when you join a "team", you've really just plunked down into a highly concentrated pool of people who haven't left the company....because they're ABCs and it's working OK for them.

Over time only reptiles and ABCs can take it, and that pretty well explains most environments.

The good developers (and good people) figure this out within a few years and either find some island of decency (good luck with that) or become janitors. Some janitors are developing value and will not always be janitors and some make the jump into a new business without a visit to janitor-land at all. The point is, the is a force that selects for assholes. It's just the simple truth.

Chris Pietschmann said...

This is like a bedtime horror story. But, I think we've all seem it.

Anonymous said...

You must admit ABC has good timing.

Soon Hui said...

The timing is not so hard to determine, after all. Just follow this rule: leave after finish a project. The you can be as good as ABC in timing for leave...:)

Matthew said...

In the past I have been ABC on many occasions because of time constraints. I prefer to be XYZ and work extra hard to accomplish the impossible by re-engineering the bad code, but not until after I make it abundantly clear that such a task is nearly impossible.

I was thrown under the bus as XYZ at my last job and I left to work for the competition and received a 15% pay increase in doing so.

Anonymous said...

I've also been ABC many times. When my boss asks "is it done yet" several times a day, I just code it to get done with it.

Wheaties said...

You touched my heart with this piece. Yes, I know it's well over a year old, maybe two but damn if it isn't where I am.