Hacker News Reader

Comment by lmm | Hacker News Reader

Developers can certainly be guilty of doing refactoring that's just churn when the current code is actually fine, and that may partly be because they too have to justify their existence. The difference is that code churn and framework churn are less directly harmful to end users than design churn (because they don't mess with the end user's workflow so much).

View on HN

My point was you can do a lot of technical work that is 100% invisible to end users (except maybe performance gains) but results in a better or more stable product. So things that may not provide direct business value but provide it tangentially through more maintainable software, fewer and/or shorter maintenance windows, less unexpected downtime, etc. There is no corollary on the design side. Once the design is done, there's little reason for the designers to hang around.

This assumes that once the design is done it should not, or does not have to change. Like anyone, designers can be wrong, customers can end up using certain features in ways not intended, and using software in ways that are not ergonomic.

So in that sense, design can and should be fluid. Where I work, designers often meet with customers (some external, some not) and continually get feedback, which the developers act on. IMO stopping design as soon as development starts increases the chance of having a poor design, forever.

Sometimes it's not known that a design has flaws until things start coming together during a project and some workflows become more prominent (and painful) than others.

Reply on news.ycombinator.com