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

You're a Bad Programmer. Embrace It.

09.29.2010
| 76961 views |
  • submit to reddit

How many developers think they're good programmers? We're not. We're all fairly bad at what we do. We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we've spent years, in some cases decades, learning? We can't even type the syntax properly, so we have compilers that check and correct it for us.

Don't even get me started on the correctness of the logic in the code... I'm looking at a chart that shows failure rates for software projects. "Small" projects (about a year for 8 people) have a 46% success rate. That's almost half. Any longer project just plummets down to a 2% rate for projects costing 10 million or more. In other words, our projects nearly always fail.

We constantly write code that breaks existing features. We add features in ways that won't scale. We create features nobody wants.

In short, as an industry, we all stink.

You can fight this. You can summon your "inner lawyer", the voice in your head that always defends you and tells you how great you are. You can take the typical developer's attitude that "it's always someone else's fault". My seven year old does that a lot too.

Or you can embrace it. Admit it... humans aren't good at programming. It's a task that requires extraordinary complexity and detail from brains that don't work that way. It's not how we tick. We might enjoy programming, we might get "in the zone" and loose track of time, we might spend our nights and weekends writing code for fun... but after years of practice, we still need these crutches to prop us up.

Once you've embraced this bitter reality, you can start to move forward. Once you've admitted to yourself that you're a bad programmer, you can stop all the silly posturing and pretending that you're great, and you can look around and find the best possible tools to help you look smarter than you are.

If we know that anytime we touch code, we'll probably break something, then we can look around to see what catches functional breaks in code as quickly as possible? A good continuous integration system combined with a good automated test suite.

Creating a good test suite is a lot like working out though... we all know we should, but we rarely take the time to create a solid, workable test automation strategy. Something like Defect Driven Testing is a great place to start.

If you recognize that we all write the same fundamentally bad code that everyone else does, then you can look around at static code analysis tools.  If you're writing Java, I highly recommend FindBugs.

These tools flag common mistakes... really common mistakes. Things you can't believe you actually do. But somehow we do nearly every day. I've met many development teams who didn't think they needed static code anaylsis. But I've never run a tool like FindBugs without finding a real (read: not theoretical) problem in production code. They hadn't learned to embrace their badness yet.

If you don't know what code is being exercised by your manual or automated test cases, look at a code coverage tool. Cobertura is my favorite, but I'm a bit biased as I had a hand in getting it started. (Why isn't it listed on that Wikipedia page??)

If your team is constantly getting interrupted and pulled in different directions, try tacking smaller units of work. Time boxed iterations, especially the one week iteration, force you to tackle and complete smaller units of work. It's easier to push back on an "emergency" change if you can ask them to wait for only two or three days. If you're on a two month task, they won't wait.

Admit that you're a sorry sysadmin as well and script your deployments. Tools like rake  and capistrano are extremely powerful tools that can completely automate your development, testing, and even production deployments. Once it's scripted, it becomes incredibly easy to duplicate. You'll be amazed at how much time this one will save you.

Of course, if you've automated your code deployments, it'd be silly to keep typing in SQL commands by hand. Ruby on Rail's database migrations may have been the early leaders in this area, but there are plenty of other tools available today. One prominent tool is Liquibase. Here are two good articles with plenty of information. http://www.infoq.com/news/2007/05/liquibase-database-refactoring and http://java.dzone.com/articles/liquibase-hibernate.

How about customer interaction? Yes, we're bad at that too. (Ever used the phrase "stupid users"?) Try moving your specifications into a more precise, and even executable format. DSLs (Domain Specific Languages) provide a wide variety of ways to engage a customer with a precise, but understandable, langage.

There are a great many tools we can use to make ourselves look smarter than we are. Once we stop fighting against the need for the tools, and embrace them, we start looking like we're pretty good developers. I won't tell anyone you stink if you don't tell them about me. ;)

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

Jared Richardson replied on Fri, 2010/10/08 - 2:50pm in response to: Xebia Labs

Hi Xebia Labs,

Deployment automation is a great tool. Once you've created a script to deploy to a server, it can usually deploy to your desktop or a testing environment as well. It enables all types of "real world" usage and testing. This work just doesn't get done when automation is difficult. And again, as humans we're pretty bad at doing complex deployments by hand. Automating them is the best way to get ahead of the game and look smarter than we are.

Also, my fellow Agile Zone leader Matt Stine has posted a great article about build scripts that might also be considered in this thread. Build Scripts? We Don't Need No Stinking Build Scripts!

Carla Brian replied on Mon, 2012/06/25 - 6:54am

No one is perfect and born with great programming skills. Skills like this one can be learned from time to time through reading and practice. - Mercy Ministries

Comment viewing options

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