Computers only do what we tell them to do (at least today). Can they tell us anything in return? Is there anything we can learn from what we have told them? I think so, at least indirectly. Have you ever noticed that computer systems and people systems often have a lot more in common than is seen by the casual observer? If I were to guess, I'd say the reason is probably because we humans are involved in designing both of them.

Last column I was talking about the RISC Vs CISC development pendulum in computer architecture. I believe this hardware development cycle can be a metaphor for the development processes on the software side of computers as well. Start with a simple concept, and over time, modify it to better fit the ever changing real world and better handle your specific goals. When it becomes too difficult to continue to modify (the law of diminishing returns), start over with a cleaner, simpler design. Then modify the new design to better fit the once again changed world and handle your newer goals better, etc.

This sounds simple, but not many people can make it happen effectively. The first problem is that its often difficult to get the right "simple but workable" starting point. Too simple and it won't work at all -- too complicated and it will hide the issues to be resolved and become inflexible and extremely difficult to modify. The next problem is human nature -- we get too accustomed to the status quo and too afraid of change. This causes us to continue to patch the old system long after it should be scraped. We need to be able to unemotionally determine when it would be best to start over rather than continue to throw vast quantities of energy at a deteriorating design.

Really good designers also know how to KIS(S) well. They are able to Keep It Simple while staying focused on what's important. They have another specific skill that is not often talked about. I call it a long term memory.

It's human nature to attempt to ignore and forget failures. In many ways this forgetfulness helps us to bounce back and try again. But the successful individuals in life (regardless of their profession) learn to be selective in this forgetfulness. They can forget the pain and humiliation of the failure and still have a clear memory of the problem. It is necessary to learn from the failure in order to progress. What would happen to a football team that never analyzed what went wrong with their plays? I wouldn't expect them to gather many Superbowl rings. Too many system designers and programmers scrap an overworked or failed system without reviewing what went wrong with it. How they expect to build a better next starting point without this knowledge is beyond me.

There was a very interesting book in the early days of computing (before the RISC Vs CISC problems) called "The Psychology of Computer Programming". This is a groundbreaking book well worth reading today (if you can still find a copy). It is the first work I'm aware of that promoted the 'build one and expect to throw it way' programming view. In effect, the author was saying that for a really big project the best approach is to do a fairly simple prototype or pilot system, learn from it what works and what went wrong and only then build your 'real' system. Now before you get your hackles up, the book was written in the 60's and to the author 'really big' meant dozens to several hundreds of man years of effort.

With today's tools and people, and with more modest projects I would venture the author arguments would apply equally well to my point. Don't try to build the perfect system that will handle the company's business for the next twenty years. That is an impossible goal and will yield an impossible system. Instead, build the simplest workable system with enough flexibility to be modified to handle the inevitable requests for changes. You won't have as much personal ego invested in it and it will be easier to learn from its flaws when the time comes to scrap it and start the next cycle.

Perhaps most importantly, you will be building better, more responsive systems, and doing it at lower costs. After all, that's the real goal of computer systems and professional system designers and programmers as well.