I recently read an excellent post on patience and respect from Andrew Sharp, suggesting the radical idea of trying to empathise with the much-maligned whoever-wrote-this-steaming-pile-of-code-that-I-now-have-the-misfortune-of-having-to-work-with instead of the usual cursing of the previous author’s name, professionalism, family, and very existence in a bout of barely contained nerd-rage.

This is often quite embarrassing when you realise the previous author was you, but this isn’t the only reason to stop the practice of flaming the authors of rotten code.

Yes, this post is basically a rehash of Andrew’s post, but as it resonated with me I felt compelled to write down my perspective on the topic. His is concise and beautifully written, but mine briefly teases SharePoint, so take your pick. :D

The situation

You open the code. It’s worse than you thought. Your face falls as you flick through the files you need to change, and see one or more of the following:

• Classes with thousands of lines.
• Methods with thousands of lines.
• Nested ifs so deep you need to scroll horizontally to find the end of the arrow.
• Constructors with 17 arguments.
• Regions.
• No trace of automated testing. Or of even having been manually tested.
• Code that only works due to some obscure side-effects.
• Code that only works on Tuesdays.
• Liberal sprinklings of Thread.Sleep.
• Object Oriented code where all object members are static.
• No.respect_for.the_law().of.demeter()
• SharePoint involved somewhere.
• Incredibly clever code featuring an abstract factory pattern to produce strategies which are injected into commands applied with double dispatch using the visitor pattern, proxying through to WCF calls batched into units of work and persisted using an EF entity data model. You can’t help but think this is overkill to print FizzBuzz.

The initial reaction

• WTF!?!?
• No seriously; WTF?!!?!?
• What were they thinking?
• What an unprofessional jerk!
• How do they sleep at night?!?!
• I’ve got to post this to twitter. Everyone will get a good laugh at this.
• Oh, and I’ll blog it! There’s another couple of hundred people to pour scorn and ridicule on this deserving schmuck!
• Even better, I’m posting this to thedailywtf.com!

Stop! Hammertime!

What exactly are we doing here? We’re all puffed up with self-righteous indignation, but what is this vehement response going to accomplish? Shame an incompetent person out of programming, thereby ridding the glorious profession of software development of one of those rare dullards that somehow slip into the ranks of the brilliant, intellectual master-craftsmen and women that dominate the industry? (In case it isn’t clear, that sentence carries a <sarcasm/> tag :P).

Probably not. All we’re doing is stroking our own egos, delighting in someone else screwing up for a change, and further fostering the culture of competitiveness, elitism and macho-attitudes that seem to keep popping up in our industry.

Sure, short-term you may feel better for venting, but adding to the bile on the internet is a bit like peeing in the dam that supplies your own drinking water.

So what could we do instead?

Consider the context

Let’s take a deep breath, then start thinking about why this code stinks. It is important to realise that people are generally trying to do good work. There are probably valid reasons the code you are currently staring at seems wrong, and most of them probably have nothing to do with trying to spite you.

• The author is inexperienced.
• The author does not have experience with that particular problem.
• The author is trying a new approach in an attempt to learn.
• The author doesn’t know about a language feature, pattern, or project convention.
• The author was working to an insane deadline that would cost the company millions if the feature wasn’t out the door in 33 minutes.
• The author was actually confronted with worse code, and did substantial tidy up of a whole bunch of classes and extracted the most ugly bit to a place where it could be refactored later (i.e. where you currently need to modify ;)). The reason you are not currently fighting another 3 fires is because of the work they did.
• The author knew the code wasn’t perfect, but it wasn’t obvious at the time how else to factor it.
• The author just seperated from their long term partner, they have a parent in hospital, their car was smashed by an uninsured driver, their bank just increase its mortgage rate and their pet just died in a tragic canoeing accident. They had trouble concentrating on the code they wrote that week.
• The author implemented a bunch of awesome classes, and this one.
• The author wrote the code in a way that was perfect at the time, it’s just that times have changed.
• The code is actually really good. We just don’t see the beauty of it.
• The author made a mistake. You may remember making one or two of these yourself in your younger days.
• The author was forced at gunpoint to write the code by a rogue PM who was also holding the author’s family hostage, dangling them precariously over a vat of potent hydrochloric acid while screaming “add another responsibility to the class or they all get it! Add more regions and superfluous comments! And CLOSE THAT CLASS FOR EXTENSION!!! DO IT!!!1!”

None of this means the author is a bad person, and yet us programmers seem to take perverse delight in opening some code and sniggering “WTF?!!? What were they thinking?” while firing up our favourite blame tool. Maybe it just makes us feel better about all the cruddy code we’ve written?

Opportunities

Instead of dwelling on the negatives, let’s look at the opportunities the code has given us to do some more constructive things than suggested by our initial reactions.

• If this is public code, we could contact the author, thank them for being brave enough to share the code in the first place, and constructively suggest alternate approaches, explaining the rationale for doing so and being careful to keep the person and the code separate (e.g. favour “this class could use a factory to create this instance” or “we could use a factory…” over “you shouldn’t create this here, use a factory”. This helps get past people’s natural tendency to become defensive, and prevents you from slipping into flame mode.)
• If you work with the person, maybe consider how collective ownership applies, and think about how the team can improve things in future.
• If you can see how the code ended up in its present state and what to do about it, take the general concepts (not the personal attack) and blog that, post it to a programming mailing list, conduct a brownbag session at work, present the general principles at your local usergroup, talk at a conference, get on a podcast, start a podcast. Teach it. Educate. Play a small but valuable part in lifting the community and advancing the practice of programming.
• Think about how APIs or patterns could change or be used to prevent the problem. Release an open source project that makes getting it right easy and obvious (as well as an explanation of why this approach works).
• Practice giving criticism in a constructive, respectful way. This is a skill worth developing.
• Recognise that there is no perfect, tech debt-free solution, and think up of lots of ways to fix the problems you see in the code. This will help you to improve both your coding and your perspective. Combine this with aforementioned blogging, presenting, teaching etc.
• Encourage the author. Programming is hard; praising anything good about the code and encouraging them to try improvements can give them more confidence to tackle future problems more creatively. It’s amazing what being freed from the fear of failure can do.
• We could, hmm, I dunno, maybe FIX THE DARN CODE AND MOVE ON WITH OUR LIVES!!! ;)

Why bother?

Because programming culture seems filled with large egos, worthless competitiveness, negativity, and cults around celebrities which discourage both creative thinking and challenges to the status quo. And yet we also have many examples of selflessness and generosity: people pouring hundreds of hours into OSS projects, donating their time to usergroups and mailing lists, and blogging stuff they learn so that others may benefit. Let’s spend more time on these positives within the dev community. By focusing on the opportunities finding “bad” code gives us, I believe we can get a community where:

• People can ask honest questions without being told to “RTFM n00b”.
• People spend more time discussing different approaches than defending previous ones.
• People can post sample code or OSS projects without being ripped apart and mocked, but instead given constructive advice and congratulations for having the guts to risk failing in public.
• All people can contribute; not just the loudest, most extroverted, most confident personalities. A more diverse group of people will provide more diverse ideas and innovations.
• Failure starts to be considered a wonderful thing, as even a single failure is an opportunity for many people to learn and improve as developers.

Please leave your flames and ad hominem attacks in the comments. ;)