Sometimes you need to turn things into small, readily solvable problems
If you've read my entry on making IKE work you may have noticed that the ultimate configuration I wound up with doesn't sound all that complicated or as if it took all that much work to create. Yet I've previously been strongly uninterested in trying to create more or less the IKE configuration that I wound up with, and I expected it to take a daunting amount of work (cf). What happened between those two points is not quite as simple as me being wrong about how much work it was.
I said (and meant) that what made this whole thing feasible was my realization that IKE didn't need to actually manage my GRE tunnel; it could just do IPSec keying alone. The vitally important thing about this was that it drastically reduced the scope of the project. The initial project was 'replace everything with IKE'. This was a dauntingly massive thing that was clearly going to go on and on before I got to a point where the new setup actually did anything. Worse, it might not even be possible, so I could be spending a bunch of effort on something that would fail outright. By contrast, the reduced scope project would clearly take much less time to yield results. It was also much more likely to succeed, since negotiating IPSec keys in kind of the core job of an IKE daemon; it would be quite weird if I could not use one to put IPSec on a particular traffic flow. With the scope of the project narrowed I could invest some time and get a relatively immediate payoff, and so I did. Then I could push the project a little bit further for another payoff, and then a little bit further still for another payoff, and by the end of things I had done most if not all of the initial project idea.
Based on my reaction here (and to other projects) I think one of my lessons from this particular experience is that I need to make this sort of shift more often. Faced with a big daunting project, I should look for ways to re-scope at least part of it into a small project that I can do easily and that will have an immediate payoff. This isn't just as simple as breaking the project up into separate steps; as with here, it may require rethinking what the project has to do so that you can narrow the scope to something much more modest. If you're lucky you can re-expand the project later, but you may not be.
(Of course if I look at this right this is not exactly novel. There's a whole collection of advice about turning large 'big bang' style projects into a series of incremental changes, and some of the stated reasons for this are that you start getting improvements from the work sooner and that this makes it less risky.)
Comments on this page:Written on 29 November 2014.