Sometimes you need to turn things into small, readily solvable problems

November 29, 2014

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:

The problem is that often you do not realise that this is even possible (due either to lack of knowledge or simply unconscious assumptions), making you seemingly stuck. E.g. you seem to not have realised that it was possible to not have the IKE dæmon responsible for everything, until it was pointed out.

How do you realise you have a blind spot, and then how do you go finding it?

By cks at 2014-12-01 13:58:16:

My view of the process is that it's not so much that I didn't realize it was possible as that I didn't try to think about narrowing the scope of my IKE problem until I did the first step for other reasons. Had I started by explicitly thinking about how to narrow the scope, I might well have asked myself if there was a way to split apart the GRE and IKE side of things and wound up in the same starting place. So I don't think this was a genuine blind spot as simply a general procedure I didn't try; I never said to myself 'this problem is too big, is there any way I can make it smaller?'.

I don't have any clever answers about real blind spots, what you get if you're already asking yourself 'how can I make this smaller?' and you can't see any way. My only idea would be to tell yourself that there's usually some way to make a project smaller and then reconsider everything that you think absolutely has to be included.

(Thinking about this in the context of my IKE project has caused me to also think about it in the context of my still-stalled metrics system work. This project desperately needs its scope narrowed so that I do something with it.)

Written on 29 November 2014.
« How I made IPSec IKE work for a point to point GRE tunnel on Fedora 20
TLS versions in connections to my spam-catching sinkhole SMTP server »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Nov 29 01:46:58 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.