Live data from Hacker News

How to Design Software Good

haiku-os.org

101–110 of 191 posts

Re: How to Design Software Good

#101
post #58

Earlier quoted context omitted.

> You're right, we should update it, though. No, you really shouldn't, it's not a real problem. The only people who keep tallies of gender pronouns in documents are internet trolls; don't indulge the trolls. Anyway, switching up pronouns every other time breaks continuity and makes documents harder and painful to read.

No need to keep a tally; in 2018, any document that exclusively uses masculine pronouns for genderless subjects reads as outdated. When writing on technical topics, the chief concern is to be clear, accurate, and straightforward. Anything that might distract your reader is undesirable. By referring to “the user” as “he”, you’re already distracting roughly 50% of your potential readership (if you’re writing the docume…

> you’re already distracting roughly 50% of your potential readership

If by 50% you mean 100% of the women having trouble making it through an article with multiple instances of "he" not immediately followed by "or she", that's a pretty bold claim.

I suspect the key factor in people's inability to focus on the central point of the article lies in their political persuasion rather than the shape of their genitalia.

Re: How to Design Software Good

#102
post #62
post #55

I want to mention the classic book "The Design of Everyday Things" which shares a lot of points with this post, though not about software at all.

I read this book a few years ago and was really disappointed by the content. Apparently the version I read was the "revised and expanded edition", so maybe it just got worse with the update...

OT, but you are not alone - I also thought it wasn't that good as it was claimed. I've seen it recommended many times on HN.. I can't understand why. Now when I read the title, I immediately think of doors and handles.

Re: How to Design Software Good

#103

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

I'm reminded of, of all things, WW2 tanks.

The Russians built a huge volume of very low-quality tanks, expected to go for only a few hundred miles, and to win through superior numbers. Their crews were poorly trained. The designers suggested easy-win improvements, but the brass blocked the changes as it would have impacted production rates.

The Germans built the best-engineered tank the world had ever seen, but its design tradeoffs made it ineffective, and it arrived too late in the war.

Re: How to Design Software Good

#104

> Good Software Does Not Expose Its Implementation Excellent goal but way harder than people think. I would say it is not possible in the fullest.

The most annoying (and visible) example of this is people naming their programs after the language/toolset used. As a user, I need not care that your code is written with Go/Python/KDE/Gnome, so why name your program with it?

Re: How to Design Software Good

#105
post #56

Earlier quoted context omitted.

I agree this is very unusual. It's also somewhat annoying, for example I can't just send this to my Kindle to read it, and I can imagine other tools failing on this as well.

Which is more the fault of the Kindle than the authors. It's Docbook, a standard that was invented for the purpose of writing books.

Writing good software is hard I guess :)

Re: How to Design Software Good

#106

> Good Software Does Not Expose Its Implementation Excellent goal but way harder than people think. I would say it is not possible in the fullest.

The most annoying (and visible) example of this is people naming their programs after the language/toolset used. As a user, I need not care that your code is written with Go/Python/KDE/Gnome, so why name your program with it?

Half of those don't quite belong in that list.

KDE/Gnome are much more than implementation details: writing a program for either is using a certain design languages and sets of UX rules, and those are user-visible.

Re: How to Design Software Good

#107

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that…

> Clean code doesn't mean "no bugs" and "good software"

This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends.

I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess.

I don't care what your code looks like if you did not achieve a good end-product.

Re: How to Design Software Good

#108

Sorry to be a pedant, but the grammar and capitalization in this guide do not instill confidence. "How to Design Software Good" <- design well? "How will Your Users Do Their Work?" <- Seriously?

Maybe its meant to be tongue-in-cheek.

Or possibly a non-native english speaker.

Re: How to Design Software Good

#109
post #57
post #48

I saw a quick flash of unstyled content (in Firefox) where all the text was jammed into one paragraph with no breaks. And then the page rendered normally. So I glanced at the source code, and it surprised me to see that it was not a typical HTML document, but instead an XML document with a stylesheet. It is very rare to see a non-HTML page on the web, whether it is the XHTML serialization of HTML, or fully custom XML…

Once upon a time, the whole internet was going to be built this way!

Client side XSLT has one terrific advantage : it allows splitting up a page into dynamic and static parts. This allows you to cache almost-static-but-not-really pages very efficiently. E.g. a news paper front page with a “logged in as…” section top right, but otherwise equal content. Or HN comment pages for logged in users, which currently are uncached and can cause quite heavy load on the server for heavy threads, simply by virtue of people viewing it. I remember a situation where they explicitly asked: please log out when viewing this comment page—that shouldn’t be necessary.

Re: How to Design Software Good

#110
post #96

Earlier quoted context omitted.

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that…

>- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?

No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.
Post reply on HN