How perfectly sane people end up writing terrible code

http://techbeacon.com/how-terrible-code-gets-written-perfectly-sane-people

by mitchpron • 10 years ago

20 1 10 years ago

heisenbit• 10 years ago

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.

How perfectly sane people end up writing terrible code

Related Stories