Risk Budget
September 18, 2008 – 3:03 pmWard 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?
6 Responses to “Risk Budget”
Just to reiterate my usual point – thanks to git-svn and bzr-svn, there’s no point in arguing against Subversion; I happily coded all of my Google Summer of Code Project using Bazaar, though CiviCRM ‘proper’ is hosted in a Subversion repo. The `bzr push`es on my side were seen as `svn commit`s on the other, any everybody was happy.
As what am I working on this week – upgrading two DrProject sites from 1.2 to 3.0, getting the epiphany that the upgrade script must’ve worked for somebody, so if it’s not working for me, then maybe I should try PostgreSQL 8.2 instead of 8.3 (just the right idea, as it turned out), these kinds of things.
By Shot on Sep 18, 2008
If those people you speak of were using git, svnmerge would be totally unnecessary. Just something to think about.
And I think you can only count buildout + virtualenv as 1.25 new things. virtualenv just gets out of your way, letting buildout do its thing. Once you set it up, you never think about virtualenv again (well, you have to activate it, but that’s what scripts are for).
Have you set yours up yet?
By Jeff Balogh on Sep 19, 2008
I’m concerned that your post implies that technical debt is a bad thing that comes from poor design. Some debt is good because it lets you move quickly and quickness is very very good. I never advocate bad design. However one must often choose limited design, good for the moment, but that which becomes tomorrows debt to be managed with all other development obligations.
By Ward Cunningham on Sep 19, 2008
@Ward: thanks for the clarification — yes, debt can pile up because you didn’t need X back then, but do need it now. I owe the government money right now because they changed the rules, not because I went out and spent more
@Jeff: yes, I’ve set it up. Have you got Eclipse + PyDev to play nicely with virtualenv yet?
By Greg Wilson on Sep 19, 2008
This post rings true for the GSoC project we just wrapped up. I’m not sure how the risk math would have added up, but we were building on top of a fairly complex dependency which was still being developed, switching from svn to git, applying OOP in python for more or less the first time, etc. The risk budget would have been quite large for this project. As it turned out, the student pulled it all off quite well.
I guess what I’m saying is that the budget would have to be commensurate to the people involved, just as the time estimates are for any project.
By Rob Kirkpatrick on Sep 19, 2008
With Subversion 1.5, with built-in support for merge tracking (something which really should be there from the day one, but hindsight and all that…), so need for svnmerge should be reduced if you can use new version.
And while I think that moving to distributed version control system, and in particular Gir has many advantages (better working against third party project, feature/topic branches, working in groups, bisecting history to find bugs, amending commits and division between committing and publishing, etc.) I recognize that changing SCM is not without costs. Especially that there might be additional cost because some of tools that have support for Subversion (Trac issue tracker, TortoiseSVN integration with MS Windows shell, etc.) doesn’t have Git support, doesn’t have official Git support, or support works differently that you used to.
By Jakub Narebski on Sep 21, 2008