
How perfectly sane people end up writing terrible code - mitchpron
http://techbeacon.com/how-terrible-code-gets-written-perfectly-sane-people
======
heisenbit
> Focusing on poor metrics such as “issues closed” or “commits per day”

Well, issues closed is meaningful if the issues are truly closed. Definition
of done. Also I watch commits per day not because is it terribly meaningful
but I see who may be stuck and could use some help. Having some semi stable
commit culture allows to detect developers decoupling from the rest of the
team (nothing wrong with feature branches if the feature is not fear or ego).

Especially at the beginning of a project - a situation the author is referring
with short/medium term - there is not much data at all. Closing, really
closing the first things can help to get moving and counting is building a
sense of progress. After leaving the harbor it is of course better to focus on
the final destination and measure progress with respect to that.

Metrics are just measurements. Whether they are poor depends on what they are
used for. Some metrics I watch - but I would not hold anyone accountable for
them. These are intelligence like water-cooler talk. Invaluable at times and
often simply noise. And then there are other metrics that one is held
accountable for - time, budget, quality, delivered value.

In theory Agile should align these but there are often challenges that either
make it impossible to do or make is impossible to prevent the measurements to
exert an unhealthy influence on the project culture.

> Ignoring proven practices such as code reviews and unit testing

Unit testing is not always cheap. The author is remarking that unit testing
was missing. From what I understand this was a re-engineering case where
implementation language changed. Having unit tests to read may have helped him
but that would have been an expensive way of documenting code. What really was
missing that may have helped with the re-engineering would have been end-to-
end tests. Writing such test cases for the old system and thus building a good
basis for the new system maintenance.

It is unclear what the original budget was. A lot of code used these days was
never meant to survive so long - just a quick hack to get going - MVP called
these days. Conversely a lot of code that is written today for the long run
will quickly end up in the dust bin. A lot of the mess we see today is due to
the lack of planning. But then planning has been proven also darn tricky.

