While creating and developing ALL-IN-1, I wrote down my first law of software development – “Any product not used by its developers ain’t worth squat.” In building our system, we depended on ALL-IN-1 to coordinate the work among the developers. We used our product every day. When we looked at our internal and external competitors, it was clear that the developers of the systems were not users. Our competitors systems were neither useful or usable as a result.
Over the years, I accumulated other laws of software development and of business. While laws are a bit presumptuous, principles or heuristics just don’t have the same level of pithiness.
The following are the current collection of laws with a little bit of explanation.
- The usefulness of any product is directly proportional to its use by its developers. The Southern Version of this law is: “Any product not used by its developers ain’t worth squat.”
- The version 1.5 of any application product is a replacement for whatever the current desktop metaphor is.
- When in doubt about what do to next, start at the end goal and work back to the present. This law is a derivative of Russ Ackoff’s Idealized Design where Russ points out that in artificial intelligence terms it is very difficult to do forward chaining to solve a problem. Backward chaining works much better.
- Words mean something but almost never the same thing to different people. Words are the ultimate abstraction. A movie is never as good as the book. A product never looks like the specification.
- When the process you are doing isn’t working, reverse the steps. Most of us learn a change process that Bob Biller describes as bedrock – hold a system steady for long periods, make massive changes all at once, and then bring the system back to steady state. Biller describes a better process for environments which change rapidly – swamp mode. Here you make small changes all the time, much like you would traverse a swamp.
- If you are agonizing over picking the optimum choice from a list, implement all of them (move from either/or to BOTH/AND). Time after time I see software engineers spend days to weeks trying to figure out by themselves (without involving real users) what is the best choice. By implementing all of the possible ways (usually takes far less time building than trying to decide), choice is preserved until you do get the product in front of real users.
- If you can’t decide which option to pick, pick any of them and get started, but be specific. Ken Olsen’s variant: When in doubt JUST TRY!
- Produce your product or service every day even during development. Worry about real problems, not artificial ones. Keep the sense of urgency high. Keep the focus on producing value high. Get paid for the product that is produced. Enable continuous improvement.
- Never assume you are the top or bottom application. Assume the computer is a valid user too. This law is a reminder to make sure that all of the functionality you implement can also be used by other developers.
- Open architectures always win, particularly plug in architectures. The power of others being able to add value provides far more rapid growth than your own development team. Imagine our surprise when we did the Aldus-Adobe merger when we revealed our respective product revenue streams. Industry pundits estimated the size of the photo editing market at $15M. With their plug-in architecture, Adobe was generating >$250M a year – and no one knew.
- Integrating applications are a bitch – ALL-IN-1, PageMaker. You are at the mercy of every other developer and their product release cycles that you are trying to integrate with. Filters are always out of date. Testing is a combinatorial impossibility. The V1 integrating application always looks terrific, but the lifecycle costs of continuing to maintain the product are horrendous. This law is all about dependency management. V1 attracts a hot market if done right; but things get combinatorially harder in future versions.
- Integrating applications always suck. They are never good at any function. The balance of integration versus good functionality versus interaction with other programs always gets done wrong (there is never a right mix for a large enough audience).
- When developing a comprehensive system specification which includes APIs, always develop the authoring tool as well. Authoring tools are always left out in a race to get the product out, but it is the authoring tool which points out the holes in your API and system definitions.
- Messages and communications are not media neutral. The translation between media helps sharpen your ideas and content. There is a two way flow between what you are trying to communicate and the form you communicate it in. For example, the thesis student projects are generated in multiple media at the Institute of Design – slide show, video, brochure, and 16 page paper. Doing the thesis in multiple media helps the student understand their ideas much better. If you want people to edit for ideas and content do it on a crummy printer (low resolution and fidelity). To edit for typos, do it on a laser printer (high resolution and fidelity). If you want business executives to understand product concepts do sketches and storyboards, not high resolution prototype applications.
- Ends/Means Confusion. When you are with a customer it is easy to focus on Ends. When you are not, you get immersed in Means. Picking the customer(s) is the art form to developing a successful product. Find tangible surrogates for the development team to always have the customer present in any design or product development activity.
- If an organizational function or role is not represented in a meeting, their input will be sorely missed. It’s not who is present that is important; it’s who is missing.
- Life is a medium scale number problem. Large scale number problems can be treated statistically. Small scale numbers can be treated analytically. Most wicked and difficult problems in business are medium scale number problems. Most professionals convert a medium scale number problem into a large scale number problem and try to sub-optimize everything. Goldratt brilliantly showed how to convert a medium scale number problem into a small number problem with his Theory of Constraints.
As I shared the list of laws with colleagues, Andy Cargile graciously added the laws that he has accumulated to the list:
- Whenever you are brainstorming for solving a problem, always do one pass at reframing the problem and solving it orthogonally.
- If you have to explain how to use the interface to the user (who has basic knowledge), it’s not designed well enough yet.
- Open systems are a bitch in practice – in “theory” everything “should” work with everything else. Or, the equivalent: have the vendor prove the compatibility of their “open system” instead of you.
- In evaluating products, you have to “build” something similar in each one (versus just playing) or you’ll miss the gotchas.
- The first people to talk to in redesigning/enhancing an app is the customer service (answer line) folks. They can point out all the problems (without trying to fix them).
- Committees can’t create good names. Corrollary: Margaritas can (get away from the day to day work environment).
- If one person says it sucks, get a second opinion. If two say it sucks, you have some problems to deal with. If three say it sucks, it sucks.
- Beware the functional demo to executives (they’ll plan to ship it in a week).
- In estimating, it’s the tasks you forget that kills the schedule, not the individual task estimates being off.
- Let the resource doing the task tell you how long it will take.
- Have your mom test a system for you (or other completely uninvolved and uninitiated person); you’ll learn something.