Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Code Like Kudzu!

06.14.2010
| 9048 views |
  • submit to reddit

My technical brethren (and sistren) in the southern United States are probably more familiar with Kudzu than many of you, but it's a very fast growing type of vine. It's reputed to grow a foot a day when in perfect growing conditions. In the southern US, it has everything it needs to grow, so it does, at an insane pace.

How does that have anything to do with coding software? Step back for a moment and consider this question. What slows you down? When you are writing code, creating product, what factors can impede your progress?

Here are a few common impediments.

Requirements

Vague requirements force you to slow down and try to decide what the customer meant or wanted. This not only slows you down, history shows us that developers aren't that good at guessing what our customers expect.

What's the solution? I like using test automation to help developers ask the right questions earlier in the cycle. And I like using ideas like executable documentation (see cucumber for a great example) to let the end use help you write the tests before you start coding the feature. You can find more on Behavior Driven Development here and here.

Bugs

Fixing bugs is really annoying. Especially when you wrote them and I have to fix them. Anyone who has worked on a project of any size has been pulled off of "real work" to fix bugs. Isn't that fun? That's why so many developers fight to avoid being the person put on "bug patrol".

How do we avoid bug control? Use a technique that catches bugs quickly, and puts the "credit" at the feet of the developer who wrote the bug. When you practice techniques like Test Driven Development, you'll be amazed at how many of your own bugs you catch. (You don't write bugs you say? Ask the co-workers who clean up your code about that...)

Then, by placing those tests into a continuous integration system, when any other team member introduces a bug and triggers one of the tests, they get the email asking them to fix it. Then you can spend your day writing new code instead of hiding in the break room, trying to avoid bug duty.

Compiles

So many teams get to work in the morning and check the results of the weekly or nightly build... then they dig in, fix the non-compiling code, then move on with their day. The truly awesome software developers (okay, probably just lazy software developers, but there's a lot of overlap in those two groups), they don't fix the compiles. They run a continuous integration system. CI (mentioned above in the section on bugs and tests) compiles your code after every change. Then, just like with the tests, the developer who broke the build, fixes the build. Fast feedback leads to fast fixes. And that removes the dreaded duty of fixing the nightly builds.

We could go deeper and deeper into these topics... meetings slow you down, so avoid long meetings by having short ones. Daily meetings last 10 minutes and help you eliminate the horribly 1 to 2 hour friday afternoon snorefest. Distractions (aka The Web) slow you down. Try Pair Programming to avoid the temptation to hit the tubez. (Except for DZone. It's okay to come here.)

The goal of each of these ideas are to remove a hindrance from writing code. What slows you down? Find a way to eliminate it! If you can work each of these practices into your work day, you might find, like kudzu, that nothing hinders your ability to move forward at an amazing rate.

I'm waiting for someone to create a shirt that says I Code Like Kudzu just for the regional appeal!

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

François Sarradin replied on Tue, 2010/06/15 - 7:30am

Your post is interesting, but I don't understand why using a pejorative picture to speak about something that bring a better solution. I must confess that I have such an approach: I like to think about "viral infection" metaphor as a metaphor. It means to me: to introduce new practices from the bottom, starting from one developer and expanding little by little among the other developers. But I don't want to tell it clearly, because of the negative impact it may have. And I don't think I want to wear a shirt that says "I'm a virus"!

In short, why not use a metaphor that adds value to the these agile practices? (Sorry, don't have example yet!)

 

Jared Richardson replied on Tue, 2010/06/15 - 9:39am in response to: François Sarradin

"Code like kudzu" was a catchy phrase intended to grab people's attention more than it was designed to be a perfect representation of great coding practices. I find that the hardest part (for me) is grabbing people's attention and getting them some basic exposure to the ideas. And since you read the article, I suspect it worked. ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.