GUIs are built at least 2.5 times

> "This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable."

[1] https://wiki.c2.com/?SecondSystemEffect

Lean manufacturing doesn't really imply much about the day-to-day work of the factory designers and their interactions with their stakeholders, except to say that when bugs (or inefficiencies) happen a developer should fix them to get the "factory" moving again.

Which is a different story to "how do you design a greenfield factory?" and "how do you design the widgets produced by the factory that will entice consumers to buy them?" and many other important aspects. If we compare to Toyota, your software team is responsible for designing the cars, building a factory from scratch for said cars, running the factory and getting cars out the door, improving the cars based on consumer feedback, improving the factory based on bugs/inefficiencies/internal feedback, while making all of the above profitable. It's a whole range of responsibilities and tasks that need to be managed differently.

    > I have made GUIs many, many times and my best case scenario goes something like:

    > 1. A design has been made, everyone loves it. Detailed drawings have been made.
    > 2. The devs are told to Make It
    > 3. The devs Make It, exactly to spec
    > 4. Everyone looks at it and everyone hates it
    > 5. So many meetings. So much stress. This Is Terrible! What To Do?
    > 6. A new design is made. So much better! Detailed drawings are made.
    > 7. The devs are told to Make It
    > 8. The devs Make It, exactly to spec
    > 9. Everyone looks at it and They Do Not Love It
    > 10. So many meetings. So much stress. This Is Terrible! What To Do?
    > 11. Someone suggests in one of the many, many meetings what amount to basically minor changes, moving something, changing some colors, changing some text, something like that.
    > 12. The devs Make It, exactly to spec
    > 13. Nobody’s happy. But nobody hates it.
    > 14. The devs are pissed.

The best experience I have ever seen: Have the internal customer team hire a semi-technical fresh grad. They are the primary dog-fooder of the new app. Force them to do their job only using the new app (as much as possible). They give lots and lots and lots of immediate, direct feedback to the devs. You can slowly iterate to something reasonable. The secret that makes mid-level managers upset: Don't plan; allow it be built organically, especially if your audience is internal.

Another thing that I have noticed: Some people are just way, way, way better at designing and implementing GUIs. I have no idea how to filter for these people, but "you know it when you see it".

Every feature every variant ever possible configuration and all future potential states. Don’t care about how it looks or how it feels just put it all there. Build out as much of it as possible, as fast as possible, knowing it will be thrown away.

Then, whittle away. Combine, drop, group, reorganize, hide, delete, add. About halfway through this step it becomes clear what I really should have been striving for the whole time—and invariably, it’s a mile away from what I started out to build.

One I have that, then I think step three stays about the same.

This isn’t really a critique of lean development, but after a decade of trying to do things leanly, I’ve just accepted that it’s not how my brain works