Hacker News Reader

Comment by pure-awesome | Hacker News Reader

What about updating the specification before updating the UI?

The more work you have to do to change anything in the UI, the more improvements you end up saying "no" to. Great UIs typically get that way via an enormous number of tweaks and improvements (both small and large) at every stage of the design and implementation process.

Early prototyping, designers and developers working together directly, continuous builds, frequent feedback from users—all of these things feed into this improvement process and make the end result better. I'd worry that formal specifications would have the opposite effect.

I understand what you are saying but I don't agree. As I wrote in a parent comment, should you want to change one thing, adjust the specification with the developers, agree with the stakeholders, implement. Done. This is just a spec to follow and reference.

Can you point to a successful commercial product built in this manner?

Not OP, but I’m not really getting what you are asking for?

As in, a commercial software product where a specification is maintained in parallel with the actual product.

Since you say “commercial” software I’m confused. Would that exclude medical software, aerospace software?

If what you are getting at is that it is not widely used/not used in anything “successful” and thus just a pipe dream, then I understand your concern. But that doesn’t mean it can’t be a useful strategy for some fields nor that it couldn’t produce more reliable systems.

I wouldn't exclude anything, but if the only examples of this are those kinds of highly immutable, mission critical software I think that would speak volumes about the practicality of maintaining a spec (the approach OP was pitching).

Reply on news.ycombinator.com