6 Comments

Summary:

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,” […]

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.

  1. I think a better metric to use to measure engineering is feature delivery. The development team should be building towards goals established by the leadership – certain number of features, scalability goals, etc. Laying out dates and delivering the requested features by those dates is the most meaningful metric. Consistent communication should accompany the deadlines so that engineering informs you of issues up front before they happen.

    The problem with monitoring your developers using Code/Test metrics is that it doesn’t equate to the bottom line – just how well their code matches your guidelines. Sales metrics correspond directly to revenue and marketing deliverables should translate as well based on your ARPU. Engineering is the same – they should be able to deliver important features quickly and on target. The development team could be writing perfectly tested code that changes the background color of your website.

    The engineers are also going to respond better to pressure to make deadlines and deliver features than to write tests for their code. If you have to pester them to test their code, then you haven’t hired the right engineers.

    In the end, if you feel like you need better insight into the development process you need to hire a quality engineering manager. Having someone you trust in place who understands how the development is done and can run design and code reviews will give you the best control over your engineering team.}

    Share
  2. I agree wholeheartedly. I actually had something in the original article that mentioned how you could wire this into planning software to show how these metrics could be tied into feature delivery, but for space reasons that was cut out. To give context to the post, I think you are correct for medium to large teams; initially it might not be feasible to hire a quality engineering manager when you are just starting up. My point was that these metrics are helpful when you are working with much smaller teams of only a few people in the entire company, like you would find in a startup. If you are the president of a small company and cannot afford to put a QEM in place this is a way to hold your developers to account without micromanaging.

    Thanks for the comments.}

    Share
  3. Shoot, this is my bad.
    Chris, do you want to elaborate on the more important sutff in a Chapter 2? Looks like our readers would benefit. (Guess who isn’t a developer?)
    best, carleen}

    Share
  4. I’m sceptic about this advice, Chris. Tests and coverage reports are great tools, but it’s not the panacea you’re suggesting it is.

    The problem with accountability in code is that all software projects are unique. You never implement the same software in the same way twice. Therefore it is difficult for someone who is not a software engineer to tell if the engineers are doing well or not. There are several metrics that can help, such as bug count and severity, number of features delivered, lines of code, number of classes, number of test cases, test coverage, project velocity (as in Extreme Programming), etc. All of these give a different view of the status of the project, but it takes an expert to know what the metrics mean. Nothing beats having a good software engineer on the team, especially when the projects become bigger and more complex. Even if you can’t afford one right now, it should be a high priority. You’re risking to lose a lot of time and money if you prefer to hire three programmers fresh out of college instead of one good software engineer.

    The problem with accountability in software development is a tough one. What you’re suggesting is a tiny part of a possible solution. If a CEO would just look at the code to test ratio without knowing anything more about software engineering, he’d be micromanaging, which is just what we’re trying to avoid. He’d risk that the engineers optimize for the metric instead of delivering the software that eventually will make money for the company.}

    Share
  5. Martin just nailed it.
    When i came up with an idea worth to transform it to an actual company, I made sure i would partner with the right developer. I know the basic on coding and could develop nice skills in this department but i shouldn’t do that since I’m better used in other department.
    So I took my partner based on what I needed the most to take off with the idea.
    I trust my partner, in fact we trust each other do elevate ourselves to the highest standard in designing/developing/marketing and management, he is the guy who will have to check the performance of the developer we hired and report to me if there is something that’s not working.
    That way I don’t need to worry about this stuff since I know there is someone who got my back in this field.}

    Share
  6. I would caution anyone using the “test metric” as a way to manage software development. As stated, this is not bottom line driven, so a perfect score can still be a drain on your budget. Also it’s only natural to “game the system” – if I’m measured on bug rates, then I’m going to write very little code a day and spend most of my time testing it. This leads to 5 year IT projects…

    It is worthwhile to look into Agile methods for managing software development. Agile ties the success of the software to the bottom line, or as close as is possible. The focus is on short release cycles, that produce usable software – like a new version every two weeks. The project won’t be complete, but you have something that works, and if you change direction and scrap the last iteration you’ve only lost a few weeks of time. Better than 6 months of development to find you and the developer didn’t understand the goals in the same way, and you find you have nothing.}

    Share

Comments have been disabled for this post