Design Principles: When to Reimplement

This is another post about design. It’s about a principle which can apply fairly broadly; it could equally be about how to structure an API in a software system, or about how to handle a requirement in a business. Here it is in two flavors:

The software version

If your system’s dependency on another system cannot be expressed through a narrow, stable API, don’t depend on that external system — instead, reimplement it yourself.

The business version

If your business depends on some core function, and you care about the details of how the job is done, rather than just whether it’s done to some simple standard, don’t outsource that function. (i.e., FedEx needs to fly its own planes)

At first glance this may sound extreme; “reimplement it yourself” / “do it in-house” is a tall order for many things you may rely on. But in practice, this sort of decision can be life or death for your system. The reason is that, if you care about how a job is done in detail, you’re going to want to probe into it in depth; you’re going to want detailed controls over the individual steps of the task; you’re going to want to be involved in the day-to-day of the operations to make sure it’s done to your particular need. In terms of software, this means that you won’t be communicating with this system just via a narrow API like “write this data to a file;” you’ll be using complex API’s, bypassing API’s altogether to get internal state, and so on.

As this progresses, you gradually move from using the system to being intimately involved in it, debugging it, and ultimately needing to modify it to your particular needs. But crucially, if you don’t control that system, you can’t do that.

Now, this doesn’t mean that you shouldn’t consider outsourcing the job at first, and moving to in-house when your need to mess with the details grows. But if you’re going to do that, you need to recognize that the design constraints of working with this external system are going to shape your own design from the get-go, and even once you go in-house, the legacy of those decisions will be with you forever. If you are confident enough in the API that you believe that these design choices will be correct even afterwards, and that the changes you’ll make as you go in-house will simply be extensions to that initial relationship, great;  but if you suspect that your needs are going to end up being fundamentally different from the external system, you may want to bite the bullet and do it yourself from the get-go.

There’s an obvious risk in doing this, of course; it’s more expensive, takes more time and money, and doesn’t give you an immediate advantage over a competitor who outsources. But this risk can pay off if you know that you’re going to hit that transition point reasonably soon — that way, a competitor who built around the wrong outsourcing is suddenly going to find themselves in need of a massive redesign, while you’re revealing wonderful new features to the world.

Published in: on July 20, 2010 at 12:30  Comments (3)  
Tags: ,

Fallingwater, further thoughts

One interesting aspect of the structure of Fallingwater which I’m seeing much more clearly after building this model is how each level of the building has the logical structure of a “pool.” The floor layouts are open and in slightly irregular shapes, with edges and patterns which mimic the flow of water; the connections between levels, both inside the building and outside (through the various paths and balconies) indicate the natural way in which water would fall from one level to another in a natural system of pools on a cliffside. The windows serve to both open up the space and let in light, and to highlight this building / water relationship. (The model designer nicely used the same brick type for the water and the windows, which really makes this vivid) The river at the bottom simply seems to be the lowest level of this stacking. The overall effect is that the house is like a permanent (but oddly well-sheltered) camp in the hills.

I think I need to get out to Mill Run sometime and see this in person.

Published in: on July 6, 2010 at 15:18  Comments Off on Fallingwater, further thoughts  

Organic architecture

I’m spending part of this Fourth of July holiday building a Lego model of one of the great works of American architecture, Fallingwater. Building this is a fascinating process; it’s from a plan worked out by a professional, and he did an excellent job of conveying a lot of Frank Lloyd Wright’s key ideas in the building process. For example, one begins by building up the landscape; the point at which you begin building up the house proper is only clear in retrospect, the house grows out of the environment so seamlessly. Then you assemble a construction which is unambiguously “house;” but when you attach it to the already-laid foundation, the boundary again becomes confusing. The wall of the house could just as easily be a rock escarpment; the window, a waterfall.

It’s giving me a real appreciation for FLW’s work on this house. I need to walk around and look at some other houses and see how they handle the relationship of the structure to its environment; I suspect that a big part of the reason that so many suburban houses look, well, so suburban is that they have no clear relationship to it at all, and look rather like they got dropped on an otherwise empty lawn by aliens.

Published in: on July 5, 2010 at 15:02  Comments (6)  

A note on interface design

While reviewing some code today, a principle of software design somehow distilled itself to clarity in my head.

When designing your system, think of every major system1 upon which your own system directly depends2 as a bug.

By “think of it as a bug,” I mean that sooner or later, you are going to come to truly hate this dependency. It won’t do what you want, or it will turn old and crufty, or it will get outdated, or your system will outgrow it. Perhaps it already stinks. And therefore, think about what you are going to have to do to take it out and replace it with something better, and possibly not even having similar API’s.
Yes, you should have your code sufficiently factored and modular that such a replacement will be minimally invasive. But more importantly: if that replacement requires any change in the API’s3 by which the outside world is using your system, then there is something wrong with your design. Stop and fix that immediately.

1Both external dependencies and major subsystems of your own code. Both will suck in time, I promise you.
2If the systems upon which you directly depend have done this properly, you don’t need to worry about your indirect dependencies. If they haven’t, then you should consider replacing them now, because you are obviously dealing with the work of madmen.
3Or UI’s, if your software is at the top of its software stack. UI’s are just API’s for communicating efficiently with humans. (Or perhaps API’s are just UI’s for communicating with computers?)

Published in: on March 18, 2010 at 20:45  Comments (7)  
Tags: ,
%d bloggers like this: