The bulk of my frustration lately is dealing with the concept of early optimizations that make sense. The idea came up in a recent discussion and I feel I should have challenged it. Once again, I’m developing for a very unique type of hardware that does require tight code, so there’s some unfamiliarity and apprehension involved. Still I wrestle internally with what seems to me like the wrong approach. In practice, any practice, are there any optimizations that make sense early on and don’t bite you after an iteration or two? I’ve run across a couple so far and I’m trying hard to bite my tongue. I guess what I really struggle with is the unfamiliarity I have with the platform as well as the unfamiliarity others have with the agile approach. It’s supposed to be about incremental improvement. That is you lay out the req’s in test form (or as a GSpec, wink, wink) spill out the first ugly solution (which in my case happens to be a shameless copy of existing code), and iteratively improve the implementation as well as the test. There is no getting it right the first time, or big round of cleanup and optimization at a later date. It’s all done at once, the interfaces being key.
I just got a green bar on a very tough piece of logic and I’m not satisfied with the implementation. I was driven down certain paths because of sensible optimizations. I now have the unfortunate task of undoing at least one of these sensible optimizations and explaining my changes. The project is very young so it’s not too big of a pain. The technology is new so I still stand the chance of being horribly wrong. However, my practice and my experience is yelling quite the contrary. That’s enough yapping from me. Time to refactor.