We coders have all kinds of definitions of simple code. To some, simple code is code they understand and read easily. Others believe simple code follows the coolest, most appropriate design pattern. Some crazy person may even say that simple code has the fewest characters. To attempt to settle that debate, Extreme Programming offers four subjective qualities of simple code: testability, browsability, understandability, and explainabilty.

To make these qualities easier to remember I suggest using the mnemonic TUBE.

Testable

  • Can automated test cases be written for each piece of functionality?
  • To pass the “test of testability” you should have tests which exercise both positive and negative functionality.

Understandable

  • Bob Martin puts forward some criteria in his book: Clean Code. When you look at a function, does it do exactly what you expect it to do? Is it immediately obvious what the code does?

Browsable

  • Can the code be browsed in an IDE? Can someone who didn’t write the code find pieces of functionality easy?

Explainable

  • I’m pretty sure the reason this is here twice is it’s because it’s so important. Can a different developer tell you what the code does?

If you code passes these four tests, congratulations! You just made your code fit in the tube. Remember: If the tube fits, make commits!

Special thanks to Abby Fichtner (@hackerchick) and Thomas Schultz (@daspecster) for providing peer review!

{ 0 comments }

The Trouble With Triangles

by Zachary February 20, 2010

The iron triangle has been redefined several times in the last few years. There’s Jurgen Appelo’s Iron Square, Jim Highsmith’s Agile Triangle, Max Pool’s Iron Line, and any number of other variations. At first glance, these seem like good thought models which will allow you to balance needs.
But There Is a Flaw.
The [...]

Read the full article →

On Retrospectives: Video Lunch and Learn at Covenant Eyes

by Zachary February 2, 2010

I had opportunity to discuss retrospectives in a presentation at work, so I recorded it and published the slides on slideshare.

Read the full article →

Project Teams? Product Teams? Which One’s Better?

by Zachary January 31, 2010

In agile methodologies there are two generally accepted ways to group teams: project teams and product teams. Project teams are generally focused exclusively on a well defined goal or objective, and have a completion date to meet and/or a budget to run out of. Product teams generally are intended to support and improve an entire [...]

Read the full article →

The REAL Reason We Automate Testing

by Zachary January 15, 2010

We were discussing implementation of an automated regression test suite, and this scenario kind of popped into my head. It’s funny, dagnabit.

Read the full article →

Unscaling Agile: When You Have More Products than People

by Zachary January 6, 2010

In some of the agile discussion groups I follow, people have been discussing how to scale out an agile product over multiple teams. These discussions are generally very informative and seem to lean in the direction of breaking product teams into feature teams for the product.
But what about when we have more products or components [...]

Read the full article →

Agile Development is Like CalvinBall

by Zachary December 21, 2009

I was reading a great article by Jurgen Apello called Managers Are Not Game Designers! I found the article to be amusing and informative, especially considering how at the office we’ve joked around about how we could make a collectible card game for how we do our development.
The most important element of his post is [...]

Read the full article →

The Iteration Social Contract: Knowing When to Change a Teams Direction

by Zachary December 7, 2009

One of the most attractive aspects of agile is its ability to allow you to change a teams direction when a business needs change. However there can be confusion about when it’s appropriate to change a teams direction. In this post I will attempt to discuss the iteration social contract, what threatens it, and how [...]

Read the full article →

Experimenting with Test Driven Development: BEHOLD The GUMBALL machine!

by Zachary December 2, 2009

Last weekend I got the itch to do some development again, so I built myself a gumball machine out of PHP. I haven’t built an actual interface for the machine, but I wanted to see if I could create a system using TDD that didn’t require a user interface at all. I normally build interface [...]

Read the full article →

Metrics are Hard: Rewarding Performance in an Agile Environment

by Zachary November 25, 2009

Recently I was reading a post by Matt Heusser titled Performance Improvement, not Process Improvement.
While I agree with the post I’m concerned with an assumption it appears to be making. It seems to be making the assumption that rewarding performance based upon metrics creates better overall performance. I don’t necessarily think this is true in [...]

Read the full article →