With that being said, I firmly believe that all software (given that one is not already deeply familiar with the domain) is/can/should be written three times to end up with a good product:

1. Minimal prototype. You throw something together fast to see it can be done, taking shortcuts and leaving out features which you know you will want later(tm).

2. First naive real implementation. You build upon the prototype, oftentimes thinking that there is actually not that much missing to turn it into something useful. You make bad design decisions and cut corners because you haven't had a chance to fully grasp all the underlying intricacies of the domain and the more time you spend on it the more frustrating it becomes because you start seeing all the wrong turns you took.

3. Once you arrive at a point where you know exactly what you want, you throw it all away and rewrite the whole thing in an elegant way, also focusing on performance.

(1) and (3) are usually fun wereas (2) fast becomes a dread. The main problem is that in a work context you almost never are allowed to transition from (2) to (3) because for an outsider (2) seems good enough and nobody wants to pay for (3).

I made webservice recently. To help me debug and test results, I asked AI to make me a simple CRUD web UI in Vue. Customer liked it, and it was kept in final version.

This UI was not even a prototype. There was no request, ticket or problem to solve. I just needed it to fix other problem, and it was kept as a bonus.

As mentioned humans are terrible at imagining things that don’t exist yet.

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

UIs are easily accessible to end-users and product-managers, and can allow people to focus on a subset of the requirements. The trap is to allow the UI perspective to direct the development process.

It is vital to set an expectation with customers that allows discussion about UI matters as part of requirements discovery, but where they expect it to churn. During early development UI should be rough and should churn constantly in response to changes of more foundational matters: the business requirements, the data model, concurrency matters, interactions with other systems and the deployment.

We could save on cost per iteration by avoiding the layout and styling pass until the very end. These interfaces are about communicating information. Plain text and basic form submissions work just as well as anything else when you're still trying to design site map and purpose of each page.

There's a direct correlation between the customer-developer distance and the number of iterations required to achieve an acceptable result. You can dramatically reduce the churn by requiring daily builds or screenshots to the customer. If your development process can't support the idea of iterating like this, you need to find one that can. If the actual customer can't handle that amount of traffic, create internal proxies or advocates.

I've only got this far and thought it was interesting. Firstly because I think it's partly wrong; a programmer definitely doesn't think of encrypted data binary blobs as the same as text, but secondly because I do wonder if a subclass of a string type that is "has leading and trailing whitespace removed" might be quite an interesting way to model your data. The object could do the strips on construct.

But here's the thing with "GUIs/UIs/UXs whatever":

The best UI/UX is created by a domain professional, who knows why and how it serves as the best designed tool for that domain - a tool made by a professional for himself and/or for other professionals in the same domain.

This is why Bloomberg terminal UI/UX is like it is for finance professionals, as are DAWs for music professionals, as are CAD tools for EE/architects etc. They act as the right tool for the right job.

Coders, (figma) designers, and other "implementers" (including management and "product owners"!) has to understand the business domain in order to fully manifest their craftsmanship talent. It is very hard to start and/or iterate UI/UX design if the implementers are not personally using the tool in some professional domain, and therefore know what is right and cool design and what is not.

If only.

However, when you are doing something specific for customers (not staff) - the design is important to get right early. However, even at a number of places I have worked, the structure is still wrong.

For example I worked for a company which has one UX designer. I will give him his props. He was good at GUI design and a whizz at css! Sadly, when he had "finished" the design, it gets passed over to the developers to implement the functionality around it. If something was not going to work functionally or a customer has changed the design... it is the developer that has to fix it. The UX guy has moved on to another project and the cycle repeats. It was wrong structure.

I found good results when a UX guy works alongside a Developer. As the UX guys works on the designs, it allows the developer to start building the business logic around it. It is all part of the development process, afterall. Sure, the UX guy is likely to make changes even from the customer but the developer is always aware and can adjust. A lot of the module work is likely to be small amendments.

Once the UX is finished then so is (mostly) the Module alongside Unit Tests or similar. It is simply a developer taking the UX project and adding the needed calls to the modules. It keeps the middle layer small, easier for further changes to the UI or the Module. etc.

- Patterns like "Pipes and Filters" and "Signals and Slots" are *not* related to the process of software development, they are about internal software architecture. It does not matter how much one iterates over GUI during development with client's feedback, software still takes some input, processes it, and returns some output. Also, calling "signals" "inputs" and slots "outputs" is weird: usually signals are processed by slot (this is the Qt framework terminology for events and event handlers for GUI), so it is more natural to think about signals as inputs and slots as something that produces outputs.

- From the same section:

> I don’t know if these patterns are in a book, or have a name, but if not, they are now in a blogpost Or yeah, it is good to write an article without trying to do literature search first.

The last part of the article that says that people need to feel things before they understand whether they like them or not, was good, but I guess, all nontrivial things are done iteratively.

Russian carpenters had a saying to the effect of "to do the job without tricks and let the measure and beauty to guide you". The primary skill here is not to do a thing, but to listen to what the thing itself is telling. (See also "The stone flower" by P. Bazhov).

Or, in the article's terms, things you've built but have yet to receive the feedback "that's shit" so that they can be iterated on.

Discovery is fundamentally different from assembly (as in the 'factory' metaphor). And innovation (= new product product) is fundamentally about discovery (whether product/market fit, or product/user fit). Therefore, new product development is fundamentally an iterative process.

Any org trying to force-fit a 'get it right the first time' mentality on discovery/innovation has discovered (no pun) just how common failure is...

One objection was that the text scrolling was line by line and Steve said “Can’t this be smooth?”. In a few seconds Dan made the change. Another more interesting objection was to the complementation of the text that was used (as today) to indicate a selection. Steve said “Can’t that be an outline?”. Standing in the back of the room, I held my breath a bit (this seemed hard to fix on the fly). But again, Dan Ingalls instantly saw a very clever way to do this (by selecting the text as usual, then doing this again with the selection displaced by a few pixels — this left a dark outline around the selection and made the interior clear).

The faster you get real user feedback, the better. Decades ago, that meant coding first -- which sucked.

So we evolved.

Wireframes, pixel-perfect designs, clickable prototypes -- tightening the loop and cutting costs at every step.

Today, tools like Figma make that process even faster and more accessible. Build it in Figma, using UX-approved components and brand-approved styles, and you get something ready for feedback -- fast. (Plus, you save developers from wasting time coding something just to find out it’s wrong.)

Every front-end project should start with a clickable, usability-tested prototype before it ever hits a dev's backlog. It’s not rocket science. Skipping this step isn’t "moving fast," it’s just wasteful.

Examples of UI designs which should be copied everywhere.

GNOME 3+, Apple iOS, Windows XP/8/11, SimCity 3000+

Examples of UI designs for which you need to STOP IT NOW!

This is a similar situation to when websites would be designed in Photoshop and the translated into "pixel perfect" HTML.

I get the frame but I don't think arguing the co-opting of Cockburn by the MBA crowd gets us anywhere.

Think about it. GUI - Graphical User Interface - a concept taken from HCI Human Computer Interaction. I think that describes Peek and Poke in BASIC pretty well 50 years ago though nobody attributes those to Dartmouth. It also describes AI at present around the world.

But HCI is lossy. Why?

Exploding n-dimensional dot cloud vectors of language leveled by math are exactly why I fear that GUI should have died with CASE tools as a hauntological debt on our present that is indeed, spectral.

The world doesn't need more clicks and taps. Quite the converse: less. Read Fitts. You don't run a faster race by increasing cadence. You run a faster race by slowing down and focusing on technique. Kipchoge knows this. Contemplative computing could learn too but I'm not sure waiting on the world to change works.

Imagine a world where we simply arrived at the same kind of text interfaces we enjoy now whether they benefit from the browser or are hindered by it. We just needed better, more turnkey tunnels, not more GUI! We sort of have those from meet:team:zoom, but they suck while few realize why or can explain the lossy nature of scaling tunnels when many of us built them impulsively in SSH decades ago for fun.

The present suffers from the long-tail baggage of the keyhole problem Scott Meyers mentioned twenty years ago. Data science has revealed the n-dimensional data underlying many, if not most, modern systems given their complexity.

What we missed is user interface that is not GUI that can actually scale to match the dimensionality of the data without implying a 2D, 2.5D, or 3D keyhole problem on top of n-dimensional data. The gap from system-to-story is indeed nonlinear because so is the data!

I'd argue the missing link is the Imaginary or Symbolic Interface we dream of but to my knowledge, have yet to conceive. Why?

It's as if Zizek has not met his match in software though I suspect there's a Brett Victor of interface language yet to be found, (Stephen Johnson?) because grammatology shouldn't stop at speech:writing.

Grammatology needed to scale into Interface Culture found in software's infinite extensibility in language, since computers were what McLuhan meant when he said, "Media" and I'm pretty sure "Augmentation is Amputation" is absolute truth if we continue down our limited Cartesian frame - we'll lose limbs of agency, meaning, and respond-in-kind social reciprocity in the process, if any of those remain.

The very late binding (no binding?) we see in software now is exactly what research labs were missing in the late sixties to bridge from 1945 to 1965 and beyond. I can't imagine trying to do that with the rigid stacks close-to-metal we had then.

I hope I'm not alone in seeing or saying that the answers should be a lot closer-to-mind now given virtualization from containers to models and everything in-between.

One can only hope.

* Software development is design rather than manufacturing.

* Software manufacturing is CI/CD.

* The Toyota Production System (TPS) starts with an idea for a product, and not with building the product.

* Design is a core part of the TPS.

* Building the assembly line is part of TPS.

Sadly the essay argues against Lean Software Development by arguing that it says exactly the opposite.