Sysadmin Field Notes

December 19, 2005

So right now, we're suggesting removing persistence (at least the user visible kind), which is implemented rather oddly in our app, while we make some major data and object model changes that are going to be required by some new desired functionality.

If we leave in persistence while we do this conversion, there are a ton of things that will crop up that will make the conversion take longer, because we'll always have to sync the data model with the object model, and we have a lot of environments to deal with as well. So we can go a lot faster without worrying about persistence (plus, all the business rules need to be evaluated in the context of variable times between each steps if saving is allowed, greatly increasing the edge cases, analysis, and QA effort).

So we yank it, so we can go faster. Even if we put it in later (once the sweeping changes are done), the overall time will be less than just slogging through. Interesting idea; temporarily removing difficult functionality to get through a rough patch, then put it back in when things have stabilized. We're sure we can get more done in a year by doing it this way, rather than the slog-through-it approach.

So I see this as analogous to racing lines. The basic idea is that you slow down early in a turn when racing a track. The goal of course is to minimize the timewhen you are not flooring the gas pedal. So you slow down early to get slow enough to get around the turn, then floor it again.

This way you minimize the time lost, because when you come out of the curve, you are going faster, and the straightaways are longer than the curves.

Kind of the same thing; taking a small time hit on a small part of the course to maximize your performance across the whole course. Global maximums vs. local maximums. Tom (Thoughtworks PM I know) would be proud.