3rd July 2015
ci quality qa code
Did you know that people tend to recycle unused sheets of paper, but tend to throw used paper in the bin? Or that people are more likely to throw away a crushed drinks can, while they'll recycle a pristine one? It turns out that we make very weird decisions about what to re-use.
During an experiment, marketing professor Remi Trudel noticed a pattern in what his volunteers were recycling versus throwing in the garbage. He then went through his colleagues' trash and recycling bins at Boston University for more data.
He found the same pattern, says NPR's Shankar Vedantam: "Whole sheets of paper typically went in the recycling, but paper fragments went in the trash."
Same type of paper, different shapes, different bins.
Trudel and fellow researcher Jennifer Argo conducted experiments to figure out why that might be. Volunteers received full pieces of paper as well as fragments, and they also received cans of soda.
"After the volunteers had drunk the soda, when the cans were intact, the cans went in the recycling," Vedantam tells Morning Edition host David Greene. "But if the cans were dented or crushed in any way, the volunteers ended up putting those crushed cans in the trash."
It's a really interesting phenomenon. You can read more about it in the original NPR piece, or listen below:
What does this have to do with anything?
It's no secret that the most successful agencies are those which can commit to delivering quality software without crumbling under deadline pressure. We typically have ten to twenty simultaneous projects in our studio, and there are huge levels of potential technical debt, all of the time. We constantly need to make decisions about when to invest time into our core software and infrastructure, and a large part of recognising that investment is in re-use of our existing code.
Since our very early projects at FARM, we have followed a model of build, adapt, extract; where we first build bespoke software, adapt it to fit more than one project, then extract it to it's own repository for future re-use. And, like all software companies, we struggle with this. A given code module might be just too specific to the needs of project for which it was written, or adapting it to serve multiple projects would stretch the code to breaking point. It's a difficult problem to address, but a very important one.
In this environment, where the adapt and extract stages are often initiated by our developers independently of any 'big picture' strategy, it's interesting to consider what drives those decisions. Often we look at code which solves 90% of the problem at hand, yet we choose to rewrite, rather than re-use. Why is this?
I think there are some interesting unconscious decisions people make. In the same way people make snap decisions about what to recycle, I think most programmers develop a mental heuristic for what constitutes 'good' code, and quite often those decisions don't appear to be rational. There are a few things which I look for:
READMEwhich doesn't actually describe the project.
requirements.txt, and sensible naming conventions.
A lot of these factors are very easy to assess. In the same way an experienced developer can 'eyeball' a source file, with practice you can 'eyeball' at this level of abstraction, too. The first three items above are easy to develop a gut feeling for (less so the final one), having read enough code. Just like the blank sheet of paper is more likely to be recycled, the package that looks pristine is more likely to be reused.