Seven From Skip Walter’s Laws Of Software Development

Skip Walter designed successful software products for over three decades. Here are 7 laws from his list of 18 laws of software development.

Seven From Skip Walter’s Laws Of Software Development

Skip Walter has been designing successful technology product for more than three decades; when he was working on All-In-1 at DEC in the early 1980’s he start to codify his Laws of Software Development. His list currently stands at 18; here are three important ones to consider:

4. 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.

Ackoff’s Idealized Design model anchors you in the customer’s current operating reality. I think too often we attempt to implement a visionary solution without leaving at least a trail of breadcrumbs from where the customer is today to where you will take them.

15. 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. Examples:

• 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.

This is a very subtle point: design the form of the prototype for the kinds of feedback that you are seeking. There is a lot of value in “low fidelity” prototypes if they provide enough fidelity on the aspects of the design you want prospects to review and comment on.

17. 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.

Whether you are starting without them, perhaps because they have not been hired yet, or want to avoid arguments you are more likely planning to start over or merely postponing the argument to when any changes will be more expensive. Sometimes this may be because you want to present another group with a fait accompli; they are likely preparing their own set of surprises for you if you make a habit of it.

Four from Andy Cargile

Walters included an additional 11 Laws from Andy Cargile in a separately numbered list. Here are four more that I think are critical:

1. Whenever you are brainstorming for solving a problem, always do one pass at reframing the problem and solving it orthogonally.

Looking at a problem from different angles can help you get unstuck, in particular assume that you have an unlimited amount of one or more constrained resources (e.g. money, time, headcount, expertise,..) may allow you to discover a different approach. Making a list of things that you know won’t work can also help a team avoid getting stuck.

4. In evaluating products, you have to “build” something similar in each one (versus just playing) or you’ll miss the gotchas.

I think this is how established companies, and even other startups, are blindsided by other startups. Sometimes the approach is so different that it takes a commitment to actually building something with a new tool to really understand the strengths and limitations. The other real risk that you may have a very strong assumption of about all that a customer needs to consider a solution complete and by deleting one or more elements that some customer’s don’t need you may unlock a novel approach.

5. The first people to talk to in redesigning/enhancing an app are the customer service (answer line) folks. They can point out all the problems (without trying to fix them).

This is one of many good reasons to always involve the support personnel–who are naturally closes to the customer’s current operating realty–in any product or feature planning.

9. In estimating, it’s the tasks you forget that kill the schedule, not the individual task estimates being off.

Implementing a “pipe cleaner” version of the project, small but containing enough requisite variety to give you an understanding of the full problem, is one way to prevent these oversights. A waterfall approach may find itself in an unrecoverable situation if the task that was overlooked occurs late in the development process but requires preparation or support earlier in the process (e.g. testing a certain operating mode for the software or hardware).

Related Blog Posts

• First Seven Questions Any Product Plan Should Answer
• Applying Akin’s Laws of Spacecraft Design To Startups
• Six More from Akin’s Laws of Spacecraft Design
• 21 Great Questions for Developing New Products
• Key Questions to Answer Before Adding A Feature to Niche Software
• Oblique Strategies for Startups 1
• See What’s Missing: Careful Observation Key To Success
• Entrepreneurs Need To See With Newcomer’s Eyes And Ask Stupid Questions
• Consider What’s Changed And What You Bring To An Opportunity
• Checklist for Successful Products
• A Simple Checklist for Introducing a Collaboration Application