Ward Cunningham coined the phrase “technical debt” to describe the situation where poor design and/or implementation results in developers paying “interest” in the form of extra maintenance or other work that doesn’t add value for users. Inspired by that, I’ve started asking my students to think about the “risk budget” for their projects. Everyone is familiar with budgeting time: if you have X hours to do something, the individual times for the tasks making up that something had better not exceed X. If they do, you have to move the deadline back (i.e., get more time), cut features (i.e., reduce the time required), or get help (which is really just another way of getting more time).
Similarly, any given project can only “afford” to take on a certain amount of risk. Trying out one new tool is a good idea—you have to keep learning just to keep up— but three? Uh oh: thanks to network effects, the odds of one of them being broken or interacting badly with other things you’re using is more than three times greater. The only way to compensate is to ask for time in the schedule to deal with—well, you’re not quite sure yet, but something’s bound to come up. Even the best managers find it hard to say “yes” to requests like that.
For example, some of my students are porting DrProject to Django this term, while another group is moving the Online Marking Tool (OLM) to Ruby On Rails. In both cases the platform is new to the students, and in both cases, one student in the group has argued that we should use Git instead of Subversion for version control. There’s no data showing that one makes programmers more productive than the other (strong opinions, yes, but data, no), so which one should we choose? The answer has to be Subversion, because it’s the one that minimizes the risk of the project failing. It may not be as shiny right now as the distributed version control systems all the cool kids are using, but moving to a new platform is risk enough. (In fact, since the Django port is using virtualenv, buildout, and svnmerge, all of which are new to most participants, we’re already over-budget on risk.)
So: what are you working on today? How much risk have you taken on? How does it compare to the risk in the last project you were part of, and how well did that go?