10 ms·

GUIs are built at least 2.5 times

248 points by mpweiher 1y ago

bonki 1y ago
I have only skimmed the text but regarding GUIs specifically the list in the end is spot on. 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).
- dustingetz 1y ago
  i would add that the reason no product manager wants to pay for #3 is because historical attempts to do so have overwhelmingly resulted in cost/schedule overruns; did-not-finish outcomes are common. Let he who believes otherwise demonstrate so with his own money, this is called a startup and note that virtually all startups fail i.e. run out of some critical resource without finishing! So what is a wisened product manager to do? No easy answers here - simply look to the industry to see what the average outcome is. And it is not for lack of trying. in my opinion software delivery is not a solved problem. but it is really hard to make money as a software delivery expert by going around and saying that you don’t know how to deliver software.
  - bonki 1y ago
    I hear what you're saying but my experience is that dwelling in #2 without seeing the bigger picture does very often just as much result in cost/schedule overruns, because shoving certain features or trying to improve certain aspects just collides with the status quo and sometimes cannot be easily accomplished if things are built "wrong" to begin with (wrong often just meaning that they were based on then-relevant prerequisites/assumption which are no longer relevant). Also, the cost of maintenance is often just not taken into account, which means that in the end you have to spend way too much time to shoehorn a half-baked solution into the status quo which has the appearance of delivering what was requested (but doesn't always, because you had to compromise, leaving everybody unhappy) while taking way too much time and at the same time just piling more bloated poo on top of what's already there, making maintenance in the long run even harder. I can't count how many times I've been in a situation where implementing something shouldn't have taken more than 30 minutes but because the codebase was in a not-so-good(tm) state took several days instead. This piles up exponentially, resulting in frustrated developers, a worse product and cost/schedule overruns. In a perfect world, code should improve over time, not deteriorate.
- blitzar 1y ago
  4. Now you arrive at a point where you really know exactly what you want, you throw it all away and rewrite the whole thing in a better more elegant and performant way.
  - mattnewton 1y ago
    Number 4 is “huh I wonder if I should rewrite it in rust” ;)
- mandevil 1y ago
  "Plan to throw one away. You will anyhow."- Fred Brooks, _Mythical Man Month_ A software engineering book written decades before I was born- my college assigned us the 25th Anniversary Edition- and yet I re-read it every few years and find some new way to apply its lessons to my current problems.
  - mpweiher 1y ago
    "If you plan to throw away one, you will throw away two" -- Craig Zerouni, via Programming Pearls: Bumper Sticker Computer Science https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf
    - actionfromafar 1y ago
      Is that better or worse? (Let's shelve for a minute if worse is better.)
    - js8 1y ago
      Maybe you will, but maybe not. Hence the title - 2.5 attempts sounds about right.
- pjbster 1y ago
  Hard agree. (2) is all about building out the test suite; once you have this (3) becomes a cake walk. I've worked in a lot of places where end to end testing is performed manually by a SIT team who absolutely do not like to re-run a test once it's been passed. These people hate the idea of (3) and will overestimate the costs to the PM in order to avoid having to do it.
  - jbverschoor 1y ago
    Time for a new team. Also sounds like your customers are the testers. In other words: fire the “team” (SIP)
- barrell 1y ago
  Personally, I’ve never found this lean methodology to work for me. I have a bit of a mantra that I’ve found works really well for me: “Put everything on the screen”. 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
  - breckenedge 1y ago
    Sounds like sculpture. Or “add lightness.” My brain works the same way.
- mrheosuper 1y ago
  from the PM perspective, it makes little sense to transform from 2 to 3. Those devs had spent weeks/months for this app, now they want to throw it all away ?, that means throwing money through windows. Also, the risk that the new app may not work like before, or missing deadline, etc. A safe bet would be reiterating (2)
  - bonki 1y ago
    I explained in another comment why it isn't throwing money out of the window. In my experience, it often costs a lot more money in the long run to not do it. The underlying problem is that most companies don't really think mid- or long-term and are happy with chasing fast money and eventually throwing it all away anyway because the product isn't competitive anymore and/or maintenance becomes too expensive. These are problems which definitely can be mitigated, but it requires a good team.
- mbreese 1y ago
  I agree completely with the idea of building something 3 times. As I get older, I tend to compress things more into 2 iterations, but that just because I like to think I’m getting better at coding, so step two is less pressing. I think of the three iterations in these terms: 1) You don’t know what you’re doing. So this iteration is all about figuring out the problem space. 2) You know that you’re doing, but you don’t know how to do it. This iteration is about figuring out the way to engineer/design the program. 3) You’ve figured out both what you’re doing and how to do it. So now, just build it.
throw93849494 1y ago
I think agile approach to iterative building is kind of obsolete with AI. There is no "12th step agile fast process", with all stakeholders involved. Instead you get experts throwing slop over the wall to stakeholders, to see what sticks. 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.
- lukaslalinsky 1y ago
  Curious, which AI tool are you using for this kind of simple UI prototype?
grebc 1y ago
The only metaphor I’ve come across that is relatable to non-software people is building a house(in particular Australia because we do it so badly). As mentioned humans are terrible at imagining things that don’t exist yet.
- drdaeman 1y ago
  Any engineering surely works as an analogy - be it mechanical, electrical, chemical or anything else.
  - Doxin 1y ago
    I feel like building a house and programming are the only kinds of engineering where the customer can change the project halfway through and not get laughed out the room
    - grebc 1y ago
      It’s not only customer requirements that it works well for. Ever started prepping a site for a concrete foundation and run into rock as your levelling?
      - mindok 1y ago
        Yeah - next door didn’t enjoy the arrival of the rock breaker!
        actionfromafar 1y ago
        I like when they just give up and a huge natural rock sits in the front desk with a table top or something.
    - fifticon 1y ago
      erh, the option with the house, sounds rather expensive? my day-to-day work regards professional building cost estimation software, and I would claim people try to do a lot of work to avoid having to do that. I'm not saying they don't sometimes end up doing it anyway, but in my perspective, the larger the scale, the more this is aggressively avoided as much as possible. Similarly, I encounter a lot of comparisons where "we" software people are told to be either more or less like the building people. What I do see though, is that building people perpetually tend to miss out on a lot of data optimisations / pipelines in the building project flow. They keep talking about wanting to do this, but in practice end up entering a lot of data from scratch multiple times. One of the culprits I see, is that the people who should have shaped the data for this, have no economic motive to do so - "why should we do that, it will only be a problem for X other people at a later stage we are not involved in".
selcuka 1y ago
Also related [1]: > "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 https://wiki.c2.com/?SecondSystemEffect
andyferris 1y ago
I agree the better analogy is that software itself is the factory. We should aim to create lean software (well factored into simple, reliable, modular components dealing with manageable chunks of data at a time). 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.
webprofusion 1y ago
Agree with the idea but does anyone else find the text really hard to read? Not sure if it's the font or writing style.
- renewiltord 1y ago
  Another 1.5 times to go.
- selfhoster11 1y ago
  For me, part of it was the font.
throwaway2037 1y ago
This part is genius: > 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. I have similar experience. I think the real issue with GUIs: You have technical people building something (mostly) for non-technical people. Imagine developing a GUI for an internal app that the purchasing or accounting department uses. Most of your internal customers are non-technical. They don't think like devs. Plus, many devs have awful communication skills, especially with non-technical users, so large gaps in expectations can emerge. 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".
- altacc 1y ago
  I refer to it as "designed by programmers". It's so prevalent that the Silicon Valley TV show used this as one of it's story lines. When I worked for a consultancy in early internet days I also often repeated "the customer doesn't know what they want until they see what they don't want". People weren't used to web GUIs and there weren't the common patterns we see today, so it wasn't until they had a half working version they could actually give feedback, so getting early feedback was essential to reduce the frustrating of building something that is immediately changed. It still applies today but less to do with usage patterns and more to do with missing requirements the customer forgot to tell you about.
lukaslalinsky 1y ago
This was very hard to read and I wasn't even sure what is the conclusion. One thing I didn't understand, how does one disagree with agile dev processes, which are mostly built on top of the fact that many things, especially UX, you can't know in advance, so you have to build something small, get feedback, then either scrap it or improve it. The process described here sounds exactly like someone spending weeks if not months designing the GUI, then devs spend weeks or months implementing it, without any cross-communication, so it's kind of obvious it needs to be fully re-done so many times. People started switching to agile dev specifically to shorten the feedback loop and scrap bad ideas faster.
- mrkeen 1y ago
  > so it's kind of obvious it needs to be fully re-done so many times. But it hasn't really caught on in the management layer. Sure, they use all the right Agile buzzwords, but they still put features A, B and C into the plan, and ask questions like "when will B be finished?" "Finished?". Nah - we're the stewards of 14 bugs-as-a-service. We won't so much "finish B" as much as we'll transition to becoming the stewards of 15 bugs-as-a-service.
  - breckenedge 1y ago
    This precisely. They treat development (programming) as the slowest part of the process, but that has not been my experience since Figma came out. I’ve not seen agile done right since it arrived, we’re just doing waterfall with sprints.
cturner 1y ago
UI concerns need to be in service to the full set of requirements and the data model. 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.
bob1029 1y ago
A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. 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.
- hapticmonkey 1y ago
  This has been my experience as well. Something about the human brain just makes it very bad at observing a mocked-up screen layout and understanding how well it works in practice. Apply that to an entire application with multiple functions and the problem increases exponentially. Experience helps speed things up. But rapid iteration with a fast feedback loop is the best practice. Design is not doing the start of the loop, it’s doing the entire loop. Repeatedly.
  - lupire 1y ago
    Predicting video from a still image is a fraught task. Predicting interaction from a linear video is another fraught task. It would be surprising if someone had the ability to do this.
- pydry 1y ago
  Outside in development helps here too.
- mpweiher 1y ago
  It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices. It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development. Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards building the UI in code, rather than from data. There are good local reasons for doing this, but it does seem to push even more strongly towards a waterfall-y development process (design does pretty mockups, throws over wall)
robertlagrant 1y ago
> So imagine a pipeline that takes in encrypted text and the first “filter” decrypts the text, the second takes the decrypted text and strips away the beginning and the end, the third takes its input and sends it in an email. From a programmers perspective, we might think of these inputs and outputs as the “same” because they are text, however, in meaning, they are very different. 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.
- pjc50 1y ago
  It's just a description of InputStream/OutputStream type classes. You can have an EncryptedStream as well. There's something to be said for having objects that are just "a string (or number), but having had its prerequisites enforced and validated". Especially in unicode land.
0xCE0 1y ago
The article is poorly written. No clear message, topics jumped weirdly, and the overall style is like written by teenager/intern trying to be as impressing as some professional. 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.
- mindok 1y ago
  100%. Designers in love with white space should not design UIs for engineers (or anyone who lives their professional life in Excel). Lots of margin, padding, drop shadows, ‘round-lg’ etc might look pretty, but when you can only fit two numbers on a page it doesn’t help.
- CorrectHorseBat 1y ago
  I don't know about other professional tools, but EDA tools for chipdesign are like they are because electrical engineers and the vendors are 20 years behind in how to develop software.
- bonki 1y ago
  I agree wirh your general statement but I don't agree about DAWs specifically. Many DAWs (used to) have terrible UX.
sgt 1y ago
[flagged]
zombot 1y ago
> GUIs are built at least 2.5 times If only.
masfoobar 1y ago
I have worked for a number of different software companies over the years. For most of them, there were no dedicated frontend or UX designers. It is mostly backend devs who had enough/decent skills at frontend, whether it be GUI apps or Web apps. 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.
- bonki 1y ago
  That is 100% my experience as well.
quantum_bit 1y ago
I think the author could be more concise and also confuses multiple things in the article. I'll provide just a couple of points: - 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.
curtisszmania 1y ago
[dead]
ape4 1y ago
Maybe the next revision of this article about GUIs should include some images
Mikhail_Edoshin 1y ago
That "feels right" thing is "the quality without a name" from "The timeless way of building" by Christopher Alexander: it is "fitness for the purpose" or, perhaps, "being true to its own nature". It is both very real and very elusive. 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).
hyperpape 1y ago
It's weird that the author is bothered by the concept of waste being applied to software, because when people talk about waste in software development, one of the main forms of waste is inventory: the effort put into building software that has not yet been used. 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.
aanet 1y ago
I wasn't sure where the author (Patricia) was going with the whole 'GUIs are built >= 2.5x'.. but by the end, I agree. 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...
mmphosis 1y ago
I think most ui is borken by design possibly for perpetual income reasons. HyperCard, vb, and other easy to use and accessible builders are dead even though this what people really want. If I want a blue menu bar, I need to code markup!?!, but to stop me from creating blue menu bars, today I am forbidden from having a menu bar anyways. Crazy ideas and creatively built prototypes seem to have no place in the private ManagerFactoryClass. 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).
- bob1029 1y ago
  > I think most ui is borken by design possibly for perpetual income reasons. I don't know how the incentives really play out anymore. It's definitely self-interest in a lot of places. I have a new theory that some user interfaces are made to be janky on purpose such that the users are constantly bathed in cortisol and made easier to subjugate with the other dark patterns. The UI/UX for Azure instantly comes to mind as an example. By the time I've been able to ascertain that my VM is actually running, I have forgotten about the five other things I wanted to verify wrt billing, etc. Eventual consistency for something like this appears to me as an intentionally user-hostile design choice, especially in the case of Microsoft with their vast experience and talent pools.
  - rustcleaner 1y ago
    >I have a new theory that some user interfaces are made to be janky on purpose such that the users are constantly bathed in cortisol and made easier to subjugate with the other dark patterns. Sounds like bullshit... I believe it!
  - bloomca 1y ago
dbg31415 1y ago
Feedback loops are critical. 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.
- njx 1y ago
  Absolutely agree — getting real user feedback early is everything. Tools like Figma have been amazing for that. For folks who are still in the idea exploration phase or want to rapidly prototype low-fidelity flows without getting bogged down in design details, https://Wireframes.org https://Wireframes.org has been super useful. It combines traditional drag-and-drop wireframing with AI-generated layouts from simple text prompts, which helps get something testable in front of users really fast — even before pixel-perfect designs are needed. It’s a great way to tighten that feedback loop even further, especially for solo founders or early teams.
rustcleaner 1y ago
Siemens NX 10, KDE 3.5, Windows 2000, SimCity 2000 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!
xnx 1y ago
Modern web UIs and the tools to create them are so bad that a billion dollar companies (e.g. Figma) emerged to make an entirely separate system to make non-functional UIs. This is a similar situation to when websites would be designed in Photoshop and the translated into "pixel perfect" HTML.
davidthewatson 1y ago
Maybe. 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.
jyounker 1y ago
I wish the author would go back and read the Poppendieks' books on Lean Software Development. The Popppendieks make the following points: * 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.

248 points by mpweiher 1y ago

I have only skimmed the text but regarding GUIs specifically the list in the end is spot on. 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).

dustingetz 1y ago
i would add that the reason no product manager wants to pay for #3 is because historical attempts to do so have overwhelmingly resulted in cost/schedule overruns; did-not-finish outcomes are common. Let he who believes otherwise demonstrate so with his own money, this is called a startup and note that virtually all startups fail i.e. run out of some critical resource without finishing! So what is a wisened product manager to do? No easy answers here - simply look to the industry to see what the average outcome is. And it is not for lack of trying. in my opinion software delivery is not a solved problem. but it is really hard to make money as a software delivery expert by going around and saying that you don’t know how to deliver software.
- bonki 1y ago
  I hear what you're saying but my experience is that dwelling in #2 without seeing the bigger picture does very often just as much result in cost/schedule overruns, because shoving certain features or trying to improve certain aspects just collides with the status quo and sometimes cannot be easily accomplished if things are built "wrong" to begin with (wrong often just meaning that they were based on then-relevant prerequisites/assumption which are no longer relevant). Also, the cost of maintenance is often just not taken into account, which means that in the end you have to spend way too much time to shoehorn a half-baked solution into the status quo which has the appearance of delivering what was requested (but doesn't always, because you had to compromise, leaving everybody unhappy) while taking way too much time and at the same time just piling more bloated poo on top of what's already there, making maintenance in the long run even harder. I can't count how many times I've been in a situation where implementing something shouldn't have taken more than 30 minutes but because the codebase was in a not-so-good(tm) state took several days instead. This piles up exponentially, resulting in frustrated developers, a worse product and cost/schedule overruns. In a perfect world, code should improve over time, not deteriorate.
blitzar 1y ago
4. Now you arrive at a point where you really know exactly what you want, you throw it all away and rewrite the whole thing in a better more elegant and performant way.
- mattnewton 1y ago
  Number 4 is “huh I wonder if I should rewrite it in rust” ;)
mandevil 1y ago
"Plan to throw one away. You will anyhow."- Fred Brooks, _Mythical Man Month_ A software engineering book written decades before I was born- my college assigned us the 25th Anniversary Edition- and yet I re-read it every few years and find some new way to apply its lessons to my current problems.
- mpweiher 1y ago
  "If you plan to throw away one, you will throw away two" -- Craig Zerouni, via Programming Pearls: Bumper Sticker Computer Science https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf
  - actionfromafar 1y ago
    Is that better or worse? (Let's shelve for a minute if worse is better.)
  - js8 1y ago
    Maybe you will, but maybe not. Hence the title - 2.5 attempts sounds about right.
pjbster 1y ago
Hard agree. (2) is all about building out the test suite; once you have this (3) becomes a cake walk. I've worked in a lot of places where end to end testing is performed manually by a SIT team who absolutely do not like to re-run a test once it's been passed. These people hate the idea of (3) and will overestimate the costs to the PM in order to avoid having to do it.
- jbverschoor 1y ago
  Time for a new team. Also sounds like your customers are the testers. In other words: fire the “team” (SIP)
barrell 1y ago
Personally, I’ve never found this lean methodology to work for me. I have a bit of a mantra that I’ve found works really well for me: “Put everything on the screen”. 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
- breckenedge 1y ago
  Sounds like sculpture. Or “add lightness.” My brain works the same way.
mrheosuper 1y ago
from the PM perspective, it makes little sense to transform from 2 to 3. Those devs had spent weeks/months for this app, now they want to throw it all away ?, that means throwing money through windows. Also, the risk that the new app may not work like before, or missing deadline, etc. A safe bet would be reiterating (2)
- bonki 1y ago
  I explained in another comment why it isn't throwing money out of the window. In my experience, it often costs a lot more money in the long run to not do it. The underlying problem is that most companies don't really think mid- or long-term and are happy with chasing fast money and eventually throwing it all away anyway because the product isn't competitive anymore and/or maintenance becomes too expensive. These are problems which definitely can be mitigated, but it requires a good team.
mbreese 1y ago
I agree completely with the idea of building something 3 times. As I get older, I tend to compress things more into 2 iterations, but that just because I like to think I’m getting better at coding, so step two is less pressing. I think of the three iterations in these terms: 1) You don’t know what you’re doing. So this iteration is all about figuring out the problem space. 2) You know that you’re doing, but you don’t know how to do it. This iteration is about figuring out the way to engineer/design the program. 3) You’ve figured out both what you’re doing and how to do it. So now, just build it.

throw93849494 1y ago

I think agile approach to iterative building is kind of obsolete with AI. There is no "12th step agile fast process", with all stakeholders involved. Instead you get experts throwing slop over the wall to stakeholders, to see what sticks. 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.

lukaslalinsky 1y ago
Curious, which AI tool are you using for this kind of simple UI prototype?

grebc 1y ago

The only metaphor I’ve come across that is relatable to non-software people is building a house(in particular Australia because we do it so badly). As mentioned humans are terrible at imagining things that don’t exist yet.

drdaeman 1y ago
Any engineering surely works as an analogy - be it mechanical, electrical, chemical or anything else.
- Doxin 1y ago
  I feel like building a house and programming are the only kinds of engineering where the customer can change the project halfway through and not get laughed out the room
  - grebc 1y ago
    It’s not only customer requirements that it works well for. Ever started prepping a site for a concrete foundation and run into rock as your levelling?
    - mindok 1y ago
      Yeah - next door didn’t enjoy the arrival of the rock breaker!
      - actionfromafar 1y ago
        I like when they just give up and a huge natural rock sits in the front desk with a table top or something.
  - fifticon 1y ago
    erh, the option with the house, sounds rather expensive? my day-to-day work regards professional building cost estimation software, and I would claim people try to do a lot of work to avoid having to do that. I'm not saying they don't sometimes end up doing it anyway, but in my perspective, the larger the scale, the more this is aggressively avoided as much as possible. Similarly, I encounter a lot of comparisons where "we" software people are told to be either more or less like the building people. What I do see though, is that building people perpetually tend to miss out on a lot of data optimisations / pipelines in the building project flow. They keep talking about wanting to do this, but in practice end up entering a lot of data from scratch multiple times. One of the culprits I see, is that the people who should have shaped the data for this, have no economic motive to do so - "why should we do that, it will only be a problem for X other people at a later stage we are not involved in".

selcuka 1y ago

Also related [1]: > "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 https://wiki.c2.com/?SecondSystemEffect

andyferris 1y ago

I agree the better analogy is that software itself is the factory. We should aim to create lean software (well factored into simple, reliable, modular components dealing with manageable chunks of data at a time). 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.

webprofusion 1y ago

Agree with the idea but does anyone else find the text really hard to read? Not sure if it's the font or writing style.

renewiltord 1y ago
Another 1.5 times to go.
selfhoster11 1y ago
For me, part of it was the font.

throwaway2037 1y ago

This part is genius: > 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. I have similar experience. I think the real issue with GUIs: You have technical people building something (mostly) for non-technical people. Imagine developing a GUI for an internal app that the purchasing or accounting department uses. Most of your internal customers are non-technical. They don't think like devs. Plus, many devs have awful communication skills, especially with non-technical users, so large gaps in expectations can emerge. 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".

altacc 1y ago
I refer to it as "designed by programmers". It's so prevalent that the Silicon Valley TV show used this as one of it's story lines. When I worked for a consultancy in early internet days I also often repeated "the customer doesn't know what they want until they see what they don't want". People weren't used to web GUIs and there weren't the common patterns we see today, so it wasn't until they had a half working version they could actually give feedback, so getting early feedback was essential to reduce the frustrating of building something that is immediately changed. It still applies today but less to do with usage patterns and more to do with missing requirements the customer forgot to tell you about.

lukaslalinsky 1y ago

This was very hard to read and I wasn't even sure what is the conclusion. One thing I didn't understand, how does one disagree with agile dev processes, which are mostly built on top of the fact that many things, especially UX, you can't know in advance, so you have to build something small, get feedback, then either scrap it or improve it. The process described here sounds exactly like someone spending weeks if not months designing the GUI, then devs spend weeks or months implementing it, without any cross-communication, so it's kind of obvious it needs to be fully re-done so many times. People started switching to agile dev specifically to shorten the feedback loop and scrap bad ideas faster.

mrkeen 1y ago
> so it's kind of obvious it needs to be fully re-done so many times. But it hasn't really caught on in the management layer. Sure, they use all the right Agile buzzwords, but they still put features A, B and C into the plan, and ask questions like "when will B be finished?" "Finished?". Nah - we're the stewards of 14 bugs-as-a-service. We won't so much "finish B" as much as we'll transition to becoming the stewards of 15 bugs-as-a-service.
- breckenedge 1y ago
  This precisely. They treat development (programming) as the slowest part of the process, but that has not been my experience since Figma came out. I’ve not seen agile done right since it arrived, we’re just doing waterfall with sprints.

cturner 1y ago

UI concerns need to be in service to the full set of requirements and the data model. 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.

bob1029 1y ago

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. 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.

hapticmonkey 1y ago
This has been my experience as well. Something about the human brain just makes it very bad at observing a mocked-up screen layout and understanding how well it works in practice. Apply that to an entire application with multiple functions and the problem increases exponentially. Experience helps speed things up. But rapid iteration with a fast feedback loop is the best practice. Design is not doing the start of the loop, it’s doing the entire loop. Repeatedly.
- lupire 1y ago
  Predicting video from a still image is a fraught task. Predicting interaction from a linear video is another fraught task. It would be surprising if someone had the ability to do this.
pydry 1y ago
Outside in development helps here too.
mpweiher 1y ago
It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices. It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development. Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards building the UI in code, rather than from data. There are good local reasons for doing this, but it does seem to push even more strongly towards a waterfall-y development process (design does pretty mockups, throws over wall)

robertlagrant 1y ago

> So imagine a pipeline that takes in encrypted text and the first “filter” decrypts the text, the second takes the decrypted text and strips away the beginning and the end, the third takes its input and sends it in an email. From a programmers perspective, we might think of these inputs and outputs as the “same” because they are text, however, in meaning, they are very different. 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.

pjc50 1y ago
It's just a description of InputStream/OutputStream type classes. You can have an EncryptedStream as well. There's something to be said for having objects that are just "a string (or number), but having had its prerequisites enforced and validated". Especially in unicode land.

0xCE0 1y ago

The article is poorly written. No clear message, topics jumped weirdly, and the overall style is like written by teenager/intern trying to be as impressing as some professional. 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.

mindok 1y ago
100%. Designers in love with white space should not design UIs for engineers (or anyone who lives their professional life in Excel). Lots of margin, padding, drop shadows, ‘round-lg’ etc might look pretty, but when you can only fit two numbers on a page it doesn’t help.
CorrectHorseBat 1y ago
I don't know about other professional tools, but EDA tools for chipdesign are like they are because electrical engineers and the vendors are 20 years behind in how to develop software.
bonki 1y ago
I agree wirh your general statement but I don't agree about DAWs specifically. Many DAWs (used to) have terrible UX.

sgt 1y ago

[flagged]

zombot 1y ago

> GUIs are built at least 2.5 times If only.

masfoobar 1y ago

I have worked for a number of different software companies over the years. For most of them, there were no dedicated frontend or UX designers. It is mostly backend devs who had enough/decent skills at frontend, whether it be GUI apps or Web apps. 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.

bonki 1y ago
That is 100% my experience as well.

quantum_bit 1y ago

I think the author could be more concise and also confuses multiple things in the article. I'll provide just a couple of points: - 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.

curtisszmania 1y ago

[dead]

ape4 1y ago

Maybe the next revision of this article about GUIs should include some images

Mikhail_Edoshin 1y ago

That "feels right" thing is "the quality without a name" from "The timeless way of building" by Christopher Alexander: it is "fitness for the purpose" or, perhaps, "being true to its own nature". It is both very real and very elusive. 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).

hyperpape 1y ago

It's weird that the author is bothered by the concept of waste being applied to software, because when people talk about waste in software development, one of the main forms of waste is inventory: the effort put into building software that has not yet been used. 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.

aanet 1y ago

I wasn't sure where the author (Patricia) was going with the whole 'GUIs are built >= 2.5x'.. but by the end, I agree. 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...

mmphosis 1y ago

I think most ui is borken by design possibly for perpetual income reasons. HyperCard, vb, and other easy to use and accessible builders are dead even though this what people really want. If I want a blue menu bar, I need to code markup!?!, but to stop me from creating blue menu bars, today I am forbidden from having a menu bar anyways. Crazy ideas and creatively built prototypes seem to have no place in the private ManagerFactoryClass. 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).

bob1029 1y ago
> I think most ui is borken by design possibly for perpetual income reasons. I don't know how the incentives really play out anymore. It's definitely self-interest in a lot of places. I have a new theory that some user interfaces are made to be janky on purpose such that the users are constantly bathed in cortisol and made easier to subjugate with the other dark patterns. The UI/UX for Azure instantly comes to mind as an example. By the time I've been able to ascertain that my VM is actually running, I have forgotten about the five other things I wanted to verify wrt billing, etc. Eventual consistency for something like this appears to me as an intentionally user-hostile design choice, especially in the case of Microsoft with their vast experience and talent pools.
- rustcleaner 1y ago
  >I have a new theory that some user interfaces are made to be janky on purpose such that the users are constantly bathed in cortisol and made easier to subjugate with the other dark patterns. Sounds like bullshit... I believe it!
- bloomca 1y ago

dbg31415 1y ago

Feedback loops are critical. 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.

njx 1y ago
Absolutely agree — getting real user feedback early is everything. Tools like Figma have been amazing for that. For folks who are still in the idea exploration phase or want to rapidly prototype low-fidelity flows without getting bogged down in design details, https://Wireframes.org https://Wireframes.org has been super useful. It combines traditional drag-and-drop wireframing with AI-generated layouts from simple text prompts, which helps get something testable in front of users really fast — even before pixel-perfect designs are needed. It’s a great way to tighten that feedback loop even further, especially for solo founders or early teams.

rustcleaner 1y ago

Siemens NX 10, KDE 3.5, Windows 2000, SimCity 2000 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!

xnx 1y ago

Modern web UIs and the tools to create them are so bad that a billion dollar companies (e.g. Figma) emerged to make an entirely separate system to make non-functional UIs. This is a similar situation to when websites would be designed in Photoshop and the translated into "pixel perfect" HTML.

davidthewatson 1y ago

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

jyounker 1y ago

I wish the author would go back and read the Poppendieks' books on Lean Software Development. The Popppendieks make the following points: * 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.