0

I'll try to further explain what I mean.

Imagine you are the boss of a company. You have to deal with the tradeoff between the quality of the code and the speed of producing it. Let's assume to measure the coding speed according to Agile Methodologies in Story Points

Let's consider the two extremes:

  1. Our developers spend a lot of time in formation without writing any line of code. They are getting certified. They know about every technology and pattern, they spend hour in thinking how to better implement something but the productivity goes to 0.
  2. Our developers go straightforward to the solution of the problems. They produce a lot of code, they respect the deadlines. But it's really poor quality. A lot of code smells and other problems which will slow down the code in a few time.

It' objective that both the two extremes are not optimal. So what's your suggestion and consideration for finding the optimal tradeoff?

Improve this question
6
  • 2
    How do you measure code production per week?
    – mouviciel
    Mar 20, 2014 at 13:20
  • 3
    You're on completely the wrong trail. Code quantity is not an asset, it's a liability. During a big, hairy rewrite, you can remove code for weeks on end and make progress that way. What you need to measure is story points, or however you measure whatever your application should accomplish.
    – Kilian Foth
    Mar 20, 2014 at 13:24
  • @KilianFoth: ok, I will update the question!
    – M.F05051985
    Mar 20, 2014 at 13:42
  • see also: Should I be bothered if my LOC/day ratio is too high?
    – gnat
    Mar 20, 2014 at 13:44
  • This question reminds me of this anecdote. In short: "It's hard to measure progress by lines of code"
    – mrjink
    Mar 20, 2014 at 13:47

1 Answer 1

Reset to default
3

None.

If you start measuring the quantity of code written, this would have negative effect:

  • If for you, more code is better, developers will start writing more code when it brings nothing useful,

  • If for you, less code is better, developers would condense the code they write, rendering it barely readable.

Metrics should be used very carefully.

  • Some of them may be useful when used correctly. This is the case of:

    1. Code metrics,
    2. Code coverage (code covered by tests),
    3. ABCDE-T model of technical debt,
    4. WTFs per minute during code reviews,
    5. Number of reported bugs,
    6. etc.

  • Some of them should usually be banished, since they do more harm than good most of the time. This is the case of:

    1. LOC,
    2. Number of comments per line of code,
    3. Number of lines of code per file,
    4. Number of commits per day,
    5. etc.

Ask yourself one simple question.

What is more important for you: (A) delighting your customers by shipping features they need early and at a reasonable price, or (B) have more or less code in the code base?

Improve this answer
2
  • You get what you inspect, not what you expect.
    – Encaitar
    Mar 20, 2014 at 13:39
  • Thanks, your suggestion is really wise, I've tried to update the question to avoid the concept of code measurement and replace it with deadline respecting and story points.
    – M.F05051985
    Mar 20, 2014 at 13:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.