Education vs. Technologyby Rob Galanakis on 16/10/2010
I was listening to NPR a couple weeks ago and there was a story about this school in Tanzania that had lots of speeding traffic in front of it and a dozen or two children were being hit every year. Apparently, the government had repaved the road in front of it, which resulted in much faster vehicle traffic, but neglected to put in a footbridge or traffic light. And apparently not enough people were being injured and killed to make it an immediate priority. The focus of the interview was a group who raises awareness about these sorts of conditions, and was at the school educating the students on foot traffic safety.
The whole situation had some analogues to software, and three in particular stood out:
1. Positive changes can reveal unexpected conditions.
In this instance, I wouldn’t call it a simple cause and effect. The effect of the cause is a few degrees removed. This change was sort of like ripping out a ton of bad code and then finding all the edge cases you didn’t account for (including software that relied on the ‘bad’ behavior in the old code). Society, like software (or rather, the people that write it), has a remarkable way of adapting to non-ideal conditions. I like to think of it as many fragile, ad hoc connections, that paving something (a road literally or a codebase figuratively) destroys. Amazing as it may seem, life and data has trudged on through these harsh circumstances. When you rewrite a system, you can probably estimate how long it will take to mimic functionality with the new system. But it is almost impossible to figure out how many systems it impacts indirectly. Make sure you budget time for these sorts of things, or you’ll quickly lose the will and capital needed to do those important refactorings and systems rewrites.
2. Biggest fires need to be fought first.
As cold as it may seem, the Tanzanian government doesn’t have the resources to spend to on the infrastructure needed to fix this problem. That includes investigating, planning, and implementing the solution, whatever it is, and dealing with the consequences (maintenance, lost traffic, whatever). From Western eyes, which have so many resources, and litigate injuries so widely, this seems out of whack (and I can’t really justify it and play the pluralist- I feel emotionally wrong and intellectually absurd doing so). But for less severe circumstances, it should serve to remind us that we often need to make hard decisions about what needs to get done. That means having to ignore people’s problems sometimes in order to achieve a greater goal. Developers in less structured environments (cough, games) can often lose sight of this. On the other hand, it is sometimes OK to do the unsanctioned extra work to do something you feel strongly about, and I know and you know you’re going to do it anyway, so there’s no point in telling you that, I suppose.
3. Education can impact things much faster than technology.
This was certainly the point that made the biggest impact on me. The person being interviewed (a male Westerner, of course) explained that, if the Tanzanian government decided to build a footbridge today, it would still be months before anything was done. However, in one afternoon they could educate a few hundred students. They could provide road safety education to all the students by the time the government put up one footbridge, very likely (my extrapolation, not his).
Education is obviously a very important piece of the puzzle for working with broken tools and systems. It is, though, something we often ignore or put off in the pursuit of better tools and procedures. In fact, I’ve often discouraged education about some things so that the problem could continue to be in the forefront! How Machiavellian! And sometimes it isn’t a bug, it is an entire broken workflow. We need to make education a first order concern in tools development. And I don’t mean how to use a tool- that is something easily taught by users, to each other. I mean, providing a system of documentation for hacks, workarounds, known issues, etc. And, it must be said, the workflow for this system of documentation needs to be problem-free and as easy to use as email@example.com