Chapter 6: Discussion and Questions

[Scott]

Discussion and questions on CHP6 start here.

[Kye]

For many reasons, Project failure begins here. (p. 114)

This was surprising to read since we'd already gone beyond the chapter on requirements but makes sense after reading that the timeframe to close down the problem space is often compressed or slips. (great diagram for this on p. 119, fig. 6-2) I've seen this happen many, many times.

The nod to "browser-first" design on p. 128 is very forward-thinking! In recent years I've seen entire courses released that help designers transition from Photoshop webpage mockups to browser prototypes. Good work, Scott!

Is the open-issues list (p. 129-130) meant to help the PM shepherd the project through just the pre-spec phase or is it to be used throughout the project? I was a little confused because the text mentions dividing the list into pre- and post-spec priorities, but the last paragraph indicates the list should be a guide on progress toward spec-completion. Or maybe I just read it entirely wrong!

[Scott]

Hi Kye:

Regarding browsers - at the time it wasn't forward at all as most of my career had been spent building web browsers :)

The open issues list is meant to be for the entire project. I'm a big believe in lists, including a list of things that are somehow important but not on other lists (yet!)

[Ravi]

I had a couple of conversations last month on design with a senior manager and he thought the design process was a light switch - you can just turn it on and off whenever you like. As an ex-chemical engineer, I was surprised to find so many software professionals not having a basic understanding of the scientific method. We would perform dozens of experiments and use multi-million dollar equipment to analyze our results. Most of our experiments were failures but they allowed us to pivot quickly. The majority of our prototypes were "real world objects": thin films, adhesives, etc... I think it would be good for computer science graduates or software professionals learn how civil engineers, architects, artists, and other craftsmen approach the design problem.

Recently with the popularity of agile, A/B testing, I see a new type of problem with software teams. They work so quickly to ship software and don't spend sufficient time on solving complex problems which require more work in the design phase. I see teams taking a more incremental approach ( Bazaar approach dominating). This is another balancing act depending on the product, maturity, market, and numerous other variables.

My favorite parts of this chapter were the following:

1. Creating a set of checkpoints for the design process. I like the suggestion of having the team come up with the checkpoints.
2. Affinity diagrams are a must for organizing a large group of ideas
3. Use visual images where possible. It's a lot easier to agree with a picture than a set of words describing the interface or UI.

These are my suggestions for improving chapter 6.

1. What are some techniques that could be used for resolving conflict of ideas while brainstorming or creating the affinity diagrams?
2. Most engineers that I work with tend to "over engineer" during the prototype phase. What are some tactics that we can use to prevent this from happening.

[Scott]

Hi Ravi:

Fascinating that your chemical engineering background helps you to see something about software that people with software backgrounds don't see.

Most of our experiments were failures but they allowed us to pivot quickly.

Why do you think non scientists have such a misguided idea of what an experiment is? In all of the lectures I give about creativity and innovation this elemental concept is something many people stumble on - the simple idea you have to do things where you are unsure of the outcome in order to learn the information you need to solve a problem.

[Ravi]

Scott, as a scientist we were taught to review and reproduce the great experiments of the past. If you have a theory about how the world works, it's a basic rule of science that you need to test it with an experiment. If your experiment confirms the theory, great; if not, refine your theory and do some more experiments.

Why do non scientists have such a misguided idea of what an experiment is? When I worked as a scientist, I had terrific mentors that explained to me a variety of approaches for designing and executing experiments - failing fast, pivoting, seeking help, etc... One of my favorite quotes from my mentor was "if you don't know the answer, throw a bunch of models at it"


In the software engineering world, I've observed a lot of teams don't know what a "good development pace" looks like. You learn this by observing, working, and watching great teams. I've observed senior managers and VP's in the software world say the following: "we need to ship faster". For a junior developer or project manager with limited experience, he thinks that means less meetings, rework of code, etc... Scott, you've shown that the speed in software development is complex, interdependent with many variables.

So, I think non-scientists have this misguided idea because they haven't worked in/with great teams or had proper mentoring.

[Scott]

Thanks for writing this Ravi. There's a blog post for you to write based on this called "What Programmers Can Learn From Scientists" - you really should write it.