How not to comment code

I’ve often encountered the attitude that code or scripts should be commented to the extent that someone unfamiliar with the language being used can understand what’s going on. I most recently encountered this with a set of Ant build scripts I had developed.

Doing this would be bad.

Continue reading “How not to comment code”

Peopleware, Metrics, and Second-Order Effects

I bought a copy of the famous “Peopleware” book by DeMarco and Lister last week in a second-hand store. I haven’t been disappointed in it either. Anyway, in one of the chapters, they cite the infamous Glib’s Law:

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

Some time back, Jason Yip came up with a corollary to this which got dubbed (by others) as Yip’s Law:

Anything can be made measurable in a way that is inferior to not measuring it at all

This lovely piece of sarcasm is 100% accurate. As DeMarco and Lister points out, Glib’s Law does not say that anything can be measured in a way that is cheap, easy, or cost-effective. Typically, for something nebulous like productivity, what you actually end up measuring are second-order effects[1]. Now, there isn’t anything inherently wrong with this.

DeMarco and Lister make the very strong point that, for this measurements to be effective, they can not be given to management. This sits well with my experience. I, as an individual, can use impartial and incomplete metrics to highlight areas of weakness that I need to improve. Furthermore, I can do this without deliberately skewing the metric; after all, I know that the numbers aren’t fundamentally important.

However, the instant these figures get into the hands of management, they become something used to measure my productivity. I will start to have incentives to ensure that the numbers trend in a positive fashion. In other words, in order to get a better performance review (and the subsequent financial rewards), I have a strong interest in optimising the numbers. This invariably has a strong negative effect on productivity (Lines of Code, anyone?).

This is a corollory to Yip’s Law that I would like to add now:

Given the choice between not measuring and using an ineffectual measurement, management will always chose the ineffectual measurement, as long as it is cheap

The problem here is that managing by second-order effects is a management anti-pattern. People will optimise the second-order effect at the cost of the primary effect you are really interested in, and this will have serious negative effects. Using the Lines of Code example, developers start cutting-and-pasting large chunks of code rather than simply calling a method; this, in turn, causes defects to reproduce throughout the system[2], which lowers productivity because of the need to correct this. However, the impact of this on productivity can be hidden simply be cutting-and-pasting more code. 🙂

[1] A second-order effect is a symptom, not a cause. Managing via second-order effects is like placing a person with a fever due to the ‘flu into air-conditioning (or an ice-bath) to bring their temperature down.

[2] I’m really bad for cutting-and-pasting code. Whenever I do it, there will invariably be a syntax error that will prevent the code from compiling. Over the years, I’ve become convinced that this is a self-defence trick being played by my sub-concious. 😉

Test Driven Development is not bad, mkay?

Bucky, who seems to write a bile-ish blog, thinks that test driven development is bad because he doesn’t like compile errors in his code. Because of that, he suggests writing the interface first.

Continue reading “Test Driven Development is not bad, mkay?”

Refactoring vs Re-architecting vs Redesign vs Rewriting

In a comment on an earlier post Jon Eaves expressed concern that refactoring is being over-used as a verb. In particular, the line between refactoring and rearchitecting (or rewriting) was being blurred, and refactoring was being used as a label for any activity where you go back and do things right the second time. You know something? Jon’s right.

Continue reading “Refactoring vs Re-architecting vs Redesign vs Rewriting”

When offshoring can work

I can’t believe I’m writing about this, but here goes…

Offshoring is part of a continuing trend of economic displacement. In its current form, it’s been going since about the mid ’70s, when cheap bulk transportation (ocean-going cargo ships) combined with an increase in industrialisation in undeveloped countries (specifically: Japan and Taiwan at the time) started to result in manufacturing jobs heading to cheaper countries. This trend continued, and now the vast bulk of manufacturing work occurs along the Asian Pacific Rim (though I’d expect Africa to pick up if the political situation there ever stabilises).

Continue reading “When offshoring can work”

Learning communties – damn, they’re hard to grow

In many ways, the essence of my role at work is to foster a learning community. This is more than just a “learning environment” – all a learning environment does is to supply resources for learning. Essentially, it’s passive, just like any environment is.

Continue reading “Learning communties – damn, they’re hard to grow”