Curves

The good news in software development is that lots of different things work. Unfortunately some things work better over the short term than they do on a regular basis. Some things work well enough to get by, but leave us falling short of what’s possible. We’ll look here at some of what works and what doesn’t. We’ll see if we can get a sense of the performance curve as we vary our practices.

It’s clearly possible to build systems, at least small ones, with very little up front design. It’s even possible to succeed, for a while. But if we look at productivity over time in such a system, productivity can be high at the beginning, rises for a while as the objects begin to help us, then levels off and finally declines as the system gets harder and harder to maintain. It looks like this:

Now let’s think a bit about productivity if we build up some design and infrastructure first - getting our objects “right”. We won’t get anything done for a while, but after that, we’ll really be able to crack along. It might look like this:

But productivity isn’t quite the measure we need. Let’s think about delivery of business value to the enterprise. We’re afraid that if we don’t do enough design and infrastructure up front, we’ll get wedged and won’t be able to deliver enough value. What do the curves showing delivered value look like?

Well, of course the guys with the quick and dirty solution start out looking good. They’re delivering value while we’re building our design and infrastructure. But then we really take off. They’ll be ahead to begin with, but we should catch up. especially as they tail off. It’ll look like this:

Now this is interesting, and it explains some things that are happening in the industry right now. The quick approach really does get product out there, and it builds value quickly. In essence, it grabs market share. Then productivity slows down and tails off. The designed solution can produce value more slowly at the beginning, but can go on longer.

It’s quite common in the e-Business world to do massive rewrites of the code. This picture is telling us why: they went out early with code that couldn’t sustain them long-term, grabbed market share, and used the income to build the system again. The trend, however, is to do that repeatedly. Once the culture is to build rapidly without design, the second system will have the same curve, and the third, and so on. It’s hard to change the culture.

Still, this is bad news for the design guys. They really can out-produce the quick guys over the long haul, but they don’t have market share. By the time they’re out, the quick guys have all the business, and at the business level, the game is all but over unless the quick guys stumble very badly.

The design guys are, however, more efficient than the quick guys, over the long haul. The quick guys are working with low-leverage solutions all the time, and they may well have to have several teams running in parallel to provide the output they need. The design guys can have a higher margin, but they still can’t get the revenue. Better software doesn’t win all that often. Look around you for evidence of that.

But that’s not the worst of it. Suppose that somehow the quick team could have come out of the blocks that fast, and never had their productivity curve fall off. We’ll call that Flat Productivity, and it looks like this:

If you could actually do this, it would be a killer strategy. You’d come out of the blocks fast, but you wouldn’t slow down. Let’s add this graph to the value chart and see what happens:

Whoa! The flat guys might go ahead and stay ahead essentially forever! Even if the design up front guys got a better slope, the flat guys would be ahead for a long long time. If we could find a way to do this, we could get to market early, and not get wedged by increasingly unproductive efforts due to our bad design.

It turns out that there is in fact a way to do this. Don’t have a bad design. As we grow the system, every time we discover a better way to have designed the system, we’ll change the system to be that way.

But won’t that change everything in the system? We can hear you crying all the way over here. Well, let’s look at that. What makes a change affect everything in the system. Clearly some changes don’t. We could change out our email system, and probably just a few email objects would have to change. We could change our file structure, and maybe just a few record definitions would have to change. We could connect to a different database, and maybe we’d just have to make some standard changes in our SQL generator.

“Oh, sure,” you say, “but you’re assuming that you have all the database usage centralized in one place. What if you have SQL all over the system? Then changing the database would be really difficult!”

“Doc, it hurts when I do this,” the man said, wiggling his shoulder.

“Then don’t do that,” replies the doctor.

Old joke, important lesson. If you keep your email system, your file structure, your database, all centralized, changing things inside those centralized objects will be pretty straightforward. In the olden days this was called high cohesion and low coupling. These days it’s called encapsulation, but it’s all the same deal. Put common functionality together in one place, and it will be easier to change when you have to.

So the flat design guys have a shot, if they keep their code really clean, and if every time they see that the design should be better, they make it better. Is there a defined process that works that way? You know there is.