quality of non decreasing velocity

About the "quality of non decreasing velocity" (Q_cv) concept. (http://peripateticaxiom.blogspot.com/2009_05_31_archive.html)

That model states that in any project the velocity can increase or decrease depending on the quality. Q_cv is a threshold such that, if your base code quality is higher, then your velocity will be increasing, and if lower, it will be decreasing.

You can figure out easily some empirical evidence of about being under the Q_cv: do start doing "quick and dirty" bad code, and because of the bad quality, in the long run, maintenance will be very difficult, slower and eventually much more dirty.

Mathematically: dV/dt ~ Q -Q_cv
This is a nice mathematical way to say that sacrifice the quality means being slower in the long run (perhaps being quicker in the short term).

I would say that fitting over the Q_cv threeshold means being in the area of sustainable quality.

Objections?
Pick up one of them, or add yours :)


1) "the models works (if it works) only in the long run, and it doesn't say what is, and how you can measure, the Q_cv, so how can you know if it worth the effort?"
2) "suppose I know Q_c, I also know I'm not able to fit in the over Q_cv/sustainable quality level [area], [thus I know it does not worth the effort].
3) "quality is perceived as aesthetic, and not pragmatic."
4) "in the short term, quality means being slower, particularly if you are not used to. Refactoring, unit test and mocking needs time and skills"
5) may be you can have empirical evidence that being the wort is the quality, the higher is the negative impact to the velocity, but it does not prove that there really exist this Q_cv threeshold, i.e. an area of sustainable quality.

Commenti.
Andrea (cui ora ho dato diritti di scruttura sul documento):
Io ho dei dubbi sul fatto che aumentare la qualità rallenti nel breve periodo.

Quello che costa è l'apprendimento di una
tecnologia o di una metodologia. Una volta appreso non costa più.
Quindi non è che ad esempio il TDD ti rallenta. Ti rallenta solo finché
non l'hai appreso.

Luca:
1 comment about the "in long run". if today the team do a quick and dirty fix on one code area and tomorrow the team have to add a feature in the same code area, that it will be in the short run. so when you measure the velocity of the team working on a specific code area, than the velocity decrease immediately. Users are interested in a steady flow of features so quality do matters. here is an interesting post on the topic To Fix Or Not To Fix?: Another Good Question
1 more comment about " how can you know if it worth the effort?": should measure the number of new bugs, the velocity of the team and compare the velocity of another team implementing a similar feature (i.e. adding a new payment methods to the web apps).

About Andrea comment I do agree, the bottleneck when striving for quality is skills and talent, not time: hire the right person, create a team where skilled/experienced dev are the majority and so can quickly teach to newcomers. One post in topic: Turning Skills into Money