6 thoughts on “Accountability in Code”

  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.}

  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.}

  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}

  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.}

  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.}

  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.}

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.