Accountability in Code

All founders need to have accountability from their employees. This is important for two reasons: first, because managers need to be able to delegate tasks to team members and expect that they will deliver on your expectations; second, to avoid that founders’ curse known as “micromanagement,” which every employee dreads. Accountability only works when there is clear metric that you can use to measure delivery on your expectations. For many jobs this is a straightforward proposition. For salespeople, the metric is their quota. For marketers it might be growth in website traffic or a mailing list during a product promotion. But holding programmers to account for deliverables is a more difficult thing to do.

Programming is almost a dark art — even to people who do it. Conveniently, many programmers and managers are in agreement that discerning productivity metrics is just not simple, or even, impossible to do. You just have to hire the best, trust they’ll get the project done, and then ask for more funding when it arrives late, over budget and full of bugs. I disagree with this assertion. You can establish metrics to measure your development team’s productivity — in fact, I think you can get more even accountability out of your engineers than you get out of others in your organization.

The trick is to use existing web apps that force your developers to be accountable, simply by doing what they already do anyway — write code! I am talking about integrated testing. And I recommend two open-source development frameworks that make testing especially easy: *Ruby on Rails* and *rcov.*

*Ruby on Rails.*
Rails makes testing a top priority and you can use it to your advantage as a manager. (Other competitive frameworks like Erlyweb (Erlang) or Jifty (Perl) don’t offer testing as a tightly integrated feature of the framework.)

*What is testing, and why is it important?*
Testing is writing programs for your programs — programs to verify that your application code will work. When managing developers, you want to make sure they document their code, but there are no good standards for documentation, which creates communication problems and adds to your coders’ burden (the opposite of what you’re trying do in establishing accountability). Rails lets developers write automated tests to document their code. Everyone can see if the code is working or not, by observing if it the Rails tests ‘pass’ or ‘fail’. So testing is a great way to relieve the burden of documentation and reduces bugs at the same time.

As a founder/manager, you don’t want to review each test, which is time consuming. But if your developers are using Rails you only need know this simple command: *”Rake Stats.”*

Run the “Rake Stats” command and you’ll get a quick view of where your developers are: how much they have tested; what is working or not; and by extension, how much they have documented.

The most important statistic is the *”Code to Test Ratio,”* which will tell you the percentage of code that has been proofed, say 1:0.3, meaning 30% of the project. That is poor. Professional developers should test 100%, or even at a 1:2, 1:3 ratio. The point is, you set the metric for evaluating your developers’ poductivity when you set the Code to Test Ratio = accountability.
NOw you no longer need to ask vague questions like “how ready do you feel it is?” (Anytime there are feelings involved, someone is going to get hurt, right?)

There are other testing tools out there that provide various productivity metrics to you, and that integrate well with open-source development frameworks, like *Watir* and *Selenium.* For even more granularity in Rails, you’ll want to use the *”rcov”* command.

But using any of these will foster instant–and independent–accountability between you and your developers, allowing you, as founder, to focus on things other than micromanagement of your engineers.

loading

Comments have been disabled for this post