16

"The dumbest mistake is viewing design as something you do at the end of the process to ‘tidy up’ the mess, as opposed to understanding it’s a ‘day one’ issue and part of everything." - Tom Peters

Comments
  • 2
    Design has no effect on backend, and only minimal, if any, bearing on APIs.
  • 7
    @Root that depends on what you put into the word design :)

    You can design a database, or an api or a solution involving multiple third party services.

    And that kind of design is most definitely affecting backend and api’s.

    Even UX design can affect backend as it might decide what types of call you need, if some information should be bundled for efficiency instead if being separate calls.

    Visual design or ui is another matter that should have little impact if you have already done ux design.

    Also, you can design for security ;)

    So I definitely consider design a day one (or even 0) priority.
  • 2
    If it’s UI design and not product design, I personally fix it at the end after everything else is build around it. Just properly separate logic from UI, and be prepared to throw awwy all UI components.

    Doing the same now, finalizing all the logic and core flow on React web app, and will throw all UI components to implement React Native app.
  • 3
    That quote hits it home even with regard to UI design specifically, and you need to look no further than the usual horrible Linux GUIs to understand why.

    Linux devs tend to first do the backend because that makes sense for scripting on a server OS. The GUI is an afterthought and CLI wrapper, and that breeds horrible UIs.

    If a usable GUI is the goal, the GUI has to be the first thing, not the last, and the backend must implement the GUI afterwards.

    Sorry for being blunt, but people who really think that "UI design" is about "making it pretty" are simply not qualified to have an opinion on UI design.
  • 1
    @Fast-Nop CLI is a UI too
  • 0
    @electrineer But a CLI designed to be feature oriented, not task oriented. That's a completely different approach.
  • 1
    @Fast-Nop imho CLI only adds to your point. A prime example for trainwreck "design" still is Git.
  • 1
    @VaderNT Full ACK, Git has managed to even fuck up the CLI. But that's because it's meant primarily for interactive use, unlike most CLI tools.

    The big mistake was not defining a clear intended workflow, but throwing together every feature that anyone anywhere may ever have wanted.

    The funny thing is that exactly this is one of Torvalds' C++ criticisms. And then he went ahead to create the C++ of the VCS world. Yeah sure mate.
  • 1
    @Fast-Nop haha, interesting, I hadn't thought of it that way. That sounds about right.

    I figured that Git's terminology isn't defined (nor communicated) well at all. Like "stage", "staging area", "index" and sometimes even "cache" referring to the same thing. Or that trees and commits exist, but also "sorta kinda" tree-ishes and commit-ishes. Vague shit.

    That Rube Goldberg machine has supposedly "won the vcs wars". Shoot me now.
  • 1
    @VaderNT It's why I like the combo SVN+Tortoise which my company uses. The only metaphor that you have to remember is how a file directory works. BOOM, easy.

    Version control is a fucking helper tool for development and should not derail into a wannabe-science like gitology. I want to be able to use it even after 3 months of non-usage, given that I'm not just coding, but also doing specification engineering and shit.

    Sure, SVN is unsuited for projects that have some thousand devs world-wide (like the Linux kernel), but for the vast majority of all projects, Git is an error-prone overkill.

    Also, Github's success is the living proof of how shitty Git's UI really is.
  • 0
    @Fast-Nop oh is all this salt towards the built-in GUI tools that noone uses? You can use tortoise also with git, which makes it super simple.
  • 0
    @electrineer Uhm... no. Flat out "no" to all of your points.
  • 1
    @Fast-Nop
    > Version control is a fucking helper tool for development and should not derail into a wannabe-science like gitology.

    So much this. How many times have I read "you need to un-learn other vcs to grok Git" - excuse me, that alone makes it a bad tool.

    Plus Linus said, whenever he was unsure with a decision he looked at SVN and did the opposite. And it shows. That spite has blinded Linus, and somehow everyone else is fine with broken windows.
Add Comment