Informal greedy algorithms
Let's loosely define a greedy algorithm as one that always takes the locally best step. In surprisingly many algorithms, this turns out to be optimal.
The idea of a greedy algorithm makes for a useful informal mental model. I try to keep it in mind when prototyping: as soon as I'm done with a chunk of work, find the subsystem that is farthest from being respectable, and do the next chunk of work on that subsystem.
There is no reason why this should always be a good way to prototype, and indeed it's sometimes not. (Perhaps, e.g., the system has one lynchpin that needs to be very good before anything else can work at all.) But I've found this rule to be far more useful than it has a right to be. A few notes:
- The standard agile advice to race to the MVP is a sort of special case of this development algorithm, at least if you grant that non-existing subsystems are least respectable.
- It's nice to have habits that check our lazy, rationalizing impulses. Both individually and in team settings, it's easy and dangerous to find excuses not to work on the thing that's on fire.
- You can also view this approach as a combination of (i) using a multiplicative model to evaluate your system and (ii) supposing that one should get that value as high as possible as quickly as possible. This is a simplistic, but quite realistic, view of things.
If I ever need to make a messy room respectable in limited time, I (i) close my eyes for a second, (ii) open them and see what looks worst, (iii) fix that, and (iv) repeat until I'm out of time. This is like that, but for software. It's not always optimal, but it's unreasonably effective.