Are we there yet? - or - Why software is so hard to estimate.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

I recently finished adding caching to ChatSpring. And while it was definitely worth it (giving a 4oo% performance boost in the best case), the actual work took about 4x as long as I had estimated.

I’d thought, “ok - this is simple, get and set the cache…big whoopee.” But I hadn’t really thought it through. This problem, like so many in software was like an iceberg. Most of it was submerged, hidden.

{BEGIN TECH STUFF}

You see, I can’t just cache the output and expire it when it gets too old… Instead, I have to cache a data structure that tells me when I need to do work and when I can skip it.

I knew that this would necessitate touching the cache at every point in the code that needs to turn on the “do work” mode. It’s ugly, but the only way to do it. And I did make a nice set of wrapper-classes so the code isn’t too interdependent.

But what I hadn’t thought about was that I have to be able to figure out the cache keys every time I touch the cache (I know, not exactly rocket-science). At most of these “touch points” only partial information is available, and that partial information is different at each point.

Which means lots of little, unique pieces of code that can’t be reused.

And lots of hoops to jump through to add cache tests to my unit test suite. (shhhhh! they’ll kick me out of the PHP club if they know I use unit tests)

{END TECH STUFF}

So why is software development just prone to this sort of underestimation? Could it be that I just didn’t know what the hell I was doing, since I’d never implemented that kind of cache before?

Probably a little bit of both, but I’m going to go with the former (big surprise, I know).

The problem is that despite all of our best efforts, code is dependent. The rock you throw into one side of the pond causes ripples all the way to the other side of the pond.

We try our best, I know, to make our components loosely coupled. We try to hide the details behind a public facing protocol. All of that is good, but it doesn’t get rid of dependency, it just pushes it all into one layer. Which isn’t much help if you’re building that layer.

In fact, I would argue that software, by its nature is highly dependent. Otherwise, how could you account for its brittleness? The human brain can have a spike driven through parts of it and keep limping along. But just try corrupting a few dlls and see how far you get. Under those conditions, the best we hope for is “graceful” failure.

Maybe the best thing we can do is treat our efforts towards loose-coupling like a diet. The diet doesn’t mean you don’t need food, but that you try to eat what’s good for you. Maybe we should only use the tight coupling that’s good for us.

And in the end, we can at least take comfort from the fact that the only thing worse than tight coupling is no coupling. The only thing that will make a project later than too much interconnectivity is to try to build it on an XML-driven rules engine flown down from the heavens on the back of Pegasus and glowing with faerie dust.