The Good, the Bad and the Ugly code

Not long ago, one of my colleaques asked me what is the way that helps me more to learn. My quick answer was “Through stories”. I was sure about it because I have an experience to confirm it. This experience was the talk that Rebecca Wirfs-Brock have given last year at I TAKE Unconference. It was my first attendence to a keynote talk, the first time I was in front of an international software craftman and the first time I saw code from international big projects like “NASA X-ray Telescope InFOCμs” and Javascript. She had presented the code while telling us stories about it and these two were not the only ones. I will do a quick summary of all of them and of what I have learned.

The Good: A Story of Consistent Error Reporting Evolution

With this story, Rebecca taught us how to deal with good code. By showing us how the code evolved with each sprint, what design decisions they took, what mistakes they made and how they solved them, she succeded to print into my mind the following quotes:

Sometimes if you want to see a change for the better, you have to take things into your own hands. – Clint Eastwood
Good code is its own best documentation. – Steve McConnell
Good code is not beautiful code. – Rebecca Wirfs-Brock
If the windows are not repaired, the tendency is for vandals to break a few more windows. – “The Broken Window Theory”, James Q. Wilson and George L. Kelling

More, for each quote there is a good coding practice to follow:

  • write simple and extensible code
  • eliminate even those tiny irritations like warnings
  • stick to the cycle “Create, test, refactor”
  • refactor also the testing code
  • keep in mind that the code should also be testable besides working as it supposed to
  • make your code consistent and easy to read by respecting the code local style

The Bad: Moodle e-Learning Platform

She presented that project as being a

Mess-View-Controller where some of the code is procedural, some is object-oriented, some global variables are used, and the database is a forest of related table.

This is the case when a programmer can become very easily frustrated and ready to give up. We all know that dealing with legacy code is one of the hardest parts of our job as software developers, but Rebecca has shown us that it can be done. Here is her recipe for safely changing and extending Moodle plaform:

1. Figure out how a similar activity is done
2. Then:

  •     Write a plugin (enrol or auth)
  •     Add a question type
  •     Add a custom user profile field type
  •     Override a class or function
  •     Hack the core

Our Bad: A refactoring experience

I found this story to be the most useful one. Even if the story is about a team’s experinces with refactoring their own bad code, its learnings can be applied also for refactoring someone else’s bad code. I see this story as a story of patience. Most of us, like the team from the story, want to transform bad code into good code just like that. And everytime we reach a dead end. Why? Because we are going to deep with many refactorings at once. The key it is to be patient and to take baby steps in order to:

Prepare code to be increasingly refactorable through a simple, continuous, and sustainable set of refactorings.

Each baby step it is a small improvement like:

  • writing a test
  • refactoring a test
  • change some code to work better
  • refactor into smaller chunks
  • untangle overly-complicated logic
  • remove dead code

and by adopting these practices in our way of coding we will reach bigger improvements. As Rebecca said, these actions are perfect to be done while freeing our mind from “background” problem solving.

The Ugly

These were the hard core stories. Most of us have dealed with bad code, but few of us have dealed with ugly code. Rebecca is one of the few. First, she has seen the ugly code, with bugs very difficult to find, originally written in MATLAB and translated in C for controling the NASA X-ray Telescope InFOCμs. Second, she knows about the technical debt from Javascript libraries which makes defining new and compatible functions a real pain. Third, she knows how to handle these two cases. I will let you find out how by watching her talk from I TAKE Unconference 2013.

The Good again

Writing good code is not easy. There isn’t a single right approach. What we can easily do is learning from experiences of software craftmen, like Rebecca. We are lucky to have the opportunity to listen to their practical stories and see how they are writting code. All we have to do is to join them in two weeks at I TAKE Unconference.

More from the Blog

Leave a Comment

Your email address will not be published. Required fields are marked *

    Your Cart
    Your cart is empty
      Apply Coupon
      Scroll to Top