JT’s Blog

Cowboys in an Agile World

My buddy Chet just did a blog post here about Pro’s vs Hacks in software development.  Since I’ve often considered myself a bit of a hack, I took some offense at his usage of ‘hack’.  But the phase ‘hack’ or ‘hacker’ has many different connotations.  I prefer a more traditional definition.  Turning to the Jargon DB for the definition of hacker, I like the first definition:

A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users’ Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.

From my view point, the traits of a hacker are more in line with a development pro.  A true professional will want to fully understand the inner workings of the systems they deal with.

In his post, I feel Chet is really referring to Cowboy Coders.  From here:

Cowboy Coders are programmers who write code according to their own rules. They may be very good at writing code, but it doesn’t generally follow the standards, processes, policies, or anything else derived from the group. Cowboy Coders work well alone, or in the old-style CaveProgrammer environment, but they rarely, if ever, work well in a team.  Often times, they are a burr in the saddle that keeps the team from getting positive work done…. CowboyCoders are identified more by their attitude than by their circumstances. CowboyCoders prefer — nay, insist! — to avoid standards, processes, and policies, and hate working with others.

The problem Chet is facing is that Cowboys can become very good at delivering immediate business value.  Our partners in the business world are not software development professionals.  Their only desire is working software.   But what is “working” software?  Is it a body of code cranked out by a cowboy which has a lengthy bug/patch process in QA and fails when implemented in production?  Or professionally developed software, where QA testing becomes more of a verification of business requirements?  Where code sails through QA, into production, and rarely has bugs.  The cowboy way of changing one thing and unknowingly breaking another?  Or the professional way, where changes rarely have unintended consequences?  The problem is, how do you explain the difference to someone who is not a software development professional.  If we were building widgets, we could quantify the cost savings behind a quality program.  But we are not building widgets, we rarely have a repeatable process.  Hence, the dilemma. A colleague/mentor of mine has often stated about 70% of your code should be for addressing the non-optimal path.  30% for the perfect world.  70% for exception handling, logging, decision branching, etc.    Take fetching a record from the database for an example.  The cowboy will just fetch the record and continue on.  While the professional will ask, what should I do if the record is not found?  To be honest, I feel this ratio might be a bit low.  It doesn’t even address code written for unit testing.

On the other hand, the cowboy will view this ratio as absurd.  They will complain that it is too much code to develop and maintain.  Who needs unit tests?  Proper exception handling and logging is time consuming.  Is it better to work late hours patching and re-patching in the QA cycle?  Even the best QA testing is only going to catch a small percentage of defects.  Use of the software in production is where the unaddressed fringe cases will be revealed.  So, is having longer QA cycles and a high number of production defects a better approach?

Personally, I feel the cowboy way is an unsustainable approach.  It ultimately leads to a system that is unstable and difficult to maintain.  The result is a house of cards, that becomes increasingly difficult to change for evolving business requirements.  While the cowboy short cuts can payoff early, in the long run, they cost you more.

But again, our business partners are not software development professionals.  We are the software development professionals. Many of us face the same dilemma that Chet does.  How do you get your business partners to understand best practices in software development?  Used properly, the practices of Agile and Scrum can help.  The very first bullet point of the Agile Manifesto has the words Individuals and Interactions.   As software development professionals, we often view this as a way for *us* to get a better understanding of the business requirements, so we can deliver better software.  But the inverse is also true.  Agile is not just about understanding the business better.  It stresses collaboration.  And in a collaborative environment, there will be a give and take of information.  This applies to both parties involved.  Through collaboration, we can share our knowledge of professional software development with our business partners.

Chet used the example of storing a credit card.  Our business partner may have the requirement to store the card in the customer’s profile.  Their focus is on the customer experience.  It is unreasonable for us to expect our business partner to understand the complexities behind the PCI regulation.  But we do.  This is something that could easily be addressed in a daily stand-up meeting.  A brief discussion could explain the PCI requirement to store the card number encrypted, and to restrict access to the data from non-essential personnel.

The Agile approach stresses teamwork and collaboration and creates an environment for self organizing teams.   The team will define its own standards and processes.  Because of this contrast, true cowboy coders can be a cancer in an Agile world.  An Agile environment will become an uncomfortable place for those who wish to remain cowboy coders.  It is not an environment for those who do not work well in a team.  The overall development of the Agile team can be hindered by the presence of cowboys.

I’d like to think this is a rare situation where a cowboy cannot be turned around into a productive member of an Agile team.  Looking back, I’ve been a Cowboy coder.  But that was early in my career, and in environments that allowed it.  And if anything, it was from my own ignorance of Agile methods.  As I learned more about Agile methodologies, I accepted them more and more.  Today, I am convinced of their value in driving the success of an application development team within an organization.

My advice for Chet is to continue following the philosophies behind Agile.  Focus on building the team and partnering with the business.  Like the great and powerful Oz, Cowboys thrive in environments which are closed.  Continue perusing an environment of openness and collaboration.  Through the light of openness and collaboration, business partners will gain understanding of best practices in software development and the cowboys approach will lose credibility.

This entry was posted on Tuesday, April 28th, 2009 at 11:04 am and is filed under Uncategorized. The entry is tagged under agile, scrum. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.