Log in

No account? Create an account

Planning for A Future

At the urging of lasofia, I had dinner Friday night with Rocky Kahn and his girlfriend. As an aside, Rocky Kahn is one of the coolest names ever. He wanted to ask me questions about his software startup. During the dinner I came up with a reasonably coherent formulation of my design philosophy and decided to share it here. "So, what you're saying is design for the future," he asked. I paused. "No . . . . You won't know what the future is. Design for a future—if you are successful, there will be one," I said.

The central point is that if your project is successful, it will need to evolve. You won't have time to throw it away and create a revolutionary new version. If you are lucky, you may have a chance to throw away the parts that really suck and replace those. Design for evolutionary change: design for the ability to extend and replace parts of the system without having to redo the whole thing. Design for a system with evolutionary baggage because that's what you will get. As with most design philosophies, this involves striking a balance. There are several directions in which people seem to go too far.

The first is to over-design. It wastes energy to plan out capabilities of some subsystem that you don't need today only to find that by the time you do need them, the requirements are so different that your design (and possibly implementation) are wasted. In the most pathological case you can potentially spend so much energy designing that an otherwise successful product never gets off the ground. You can take things too far in another direction: deferring decisions too long because you are uncertain about the future so that your system balloons with complexity to support all the potential paths. Differing decisions that are cheap to defer is great. It's worth trying to find ways to make decisions that will reduce complexity. The final common failure is to under design: we won't need extensibility today and it can't possibly be harder to add later, can it?


not really relevant

Hi Sam - it's Amy, from Austin/LBj days. I was doing research on my 2nd novel and got a little sidetracked...even though I'm not coding, what you write about over-design is definitely relevant to the plotting I'm doing with novel-writing. Don't have your email so you'll just have to reply to this & I'll email it over.

Re: not really relevant

It's really good to hear from you


Re: not really relevant

Ask Sam about FXAPI. What your novel needs is a FXAPI - a storyboard or plot outline that you can constantly refer to *AND* make sure you update as you write. That way you can keep the big picture consistent and make sure the story still makes a coherent whole. There's nothing worse than an unintentionally inconsistent plot because the writer didn't do his homework.


Re: not really relevant

Hey JAB,

That does sound useful! I've re-written my plot outline/summaries at least 4 times and it has meant a completely annoying overhaul of the whole structure. How are you anyway? Email me off list if you want - hello |at| amyriley|dot|com.

A x

A need to know basis

Sam, what is FXAPI? It sounds like something I could use for my scripts as well...

A x

Re: A need to know basis

FXAPI was a design document describing how parts of a large banking
system interacted with each other. What Arley is saying is that a
broad outline acts as a wonderful tool for isolating one part of a
project from another. Once you know who the characters are, have
empathy with them, understand their basic motivations and what they
are trying to do, you can get to a point where one scene is relatively
isolated from another. This is less true for linear narrative than it is for software systems.

Re: A need to know basis

I sensed that was the case after I looked it up. It'd be useful for plotting....very useful, actually.