Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Design Software Good

haiku-os.org

Post reply on HN
Print view View original

181–190 of 191 posts

Re: How to Design Software Good

#181

Post by kingdomcome50 »

ensiferum wrote: post #144
skohan wrote: post #134

Earlier quoted context omitted.

I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.

But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)

Without fully qualifying what “easier”, “good product”, and “good experience” mean as well as delineating project constraints such as time, business value, and life it’s not possible to truly have this discussion.

Even so, I am inclined to argue that in most cases the exact opposite is true. That is, it is actually “easier” to create a “good product” with a messy codebase, because in most cases “easier” and “good product” are understood by primary stakeholders to mean business value at this moment.

Re: How to Design Software Good

#182

Post by marcosdumay »

koonsolo wrote: post #178
marcosdumay wrote: post #172

Earlier quoted context omitted.

> General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. And that, of course, has it's exceptions too. Non-optimized stuff exist, and everything that isn't on the optimum line can be improved in some way without drawbacks. Besides, the optimum line is always moving.

So you optimized some code, cool! - How certain are you that you didn't introduce a bug? - Is it also running faster on this exotic platform that we still need to support? - Did it involve API changes? - Do we need to put this into production now, or wait for the next optimization to save some time? - How much time did we spend on this? Was there something else that would have made a bigger impact? In theory you can…

Just to point, my comment wasn't about code optimization (but can apply to it too).

Re: How to Design Software Good

#183

Post by senderista »

qzw wrote: post #119
MaxBarraclough wrote: post #103

Earlier quoted context omitted.

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 d…

Now for a different context: consider Russian cars vs German cars.

German cars still suffer from some of the same poor engineering instincts that handicapped their tanks and aircraft in WW2: an emphasis on complex designs, unproven innovations, and theoretical or lab-measured performance rather than simplicity and empirically tested performance and reliability.

Re: How to Design Software Good

#184

Post by Volt »

mort96 wrote: post #180
quakenul wrote: post #143

Earlier quoted context omitted.

It is a very good metric. To have baseline UX awareness is crucial for every developer on any team that sets out to build a great product, just like any effective designer has to be aware of physical limitations of his design space (for example speed of light, bandwidth) If your UX designers job is to point out that responsive UI is indeed important for your product, he is not actually doing UX design and you are lik…

You're assuming all products are apps or websites or something with a GUI. A product could be a library, or an OS kernel, or a web API, or any number of things, where knowledge of how to make a GUI with a good UX is completely irrelevant; or the programmer could be working on a very technical part; the engineers working on, say, Safari to optimize the javascript engine's performance similarly don't need any knowledge…

There's a UX for those things too. The users would be the consumers of the API.

Re: How to Design Software Good

#185

Post by Viliam1234 »

tonyedgecombe wrote: post #89
CathyWest wrote: post #80

> 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…

The end users aren't happy, they mostly hate the crap that is foisted on them.

They hate it, but they pay for it.

Perhaps you could make something they love instead, but if the production then costs 10x more, and they are only willing to pay 2x more, it does not make sense economically.

Re: How to Design Software Good

#186

Post by Viliam1234 »

xgbi wrote: post #90
CathyWest wrote: post #80

> 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…

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

It's funny how when you make a bug and then stay awake at 1AM to fix it in production, the managers will mostly remember the latter.

Now that I'm thinking about it... do the managers actually know the bug was caused by his "programming style"? Because, if they are under impression that he is fixing other people's mistakes... then it would make sense to pay him better than the rest.

> This is really some life-long questioning of mine: should I care about things or should I focus on politics

I guess you need both; and the exact proportion depends on the company.

> Aren't those on top of the pyramid the more "sharky" people that climbed the ladder not by pure skill ...

This already assumes that those on the top have climbed the ladder. As opposed to already starting somewhere higher than you will ever get.

Re: How to Design Software Good

#187

Post by CathyWest »

GuiA wrote: post #163
CathyWest wrote: post #101

Earlier quoted context omitted.

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

50% refers to the mix of male and female people who get distracted by this; in my experience as a technical writer who would always use “he” when I was less experienced, perhaps 70% of women and 30% of men? It was certainly one aspect of my writing I got a lot of feedback on. Changing that habit was fairly easy, and has entirely solved the problem. I’m not sure what’s political about pointing out that “the user” of e…

> 50% refers to the mix of male and female people who get distracted by this; in my experience as a technical writer who would always use “he” when I was less experienced, perhaps 70% of women and 30% of men?

But who were these people? I don't doubt that there exists a population such that half of it complains about lack of gender neutral language in technical writing, but it does not necessarily follow that the same half should also be arbiters of techincal writing style.

> It was certainly one aspect of my writing I got a lot of feedback on. Changing that habit was fairly easy, and has entirely solved the problem. > > I’m not sure what’s political about pointing out that “the user” of eg a computer system is not always a “he”, but if you want to bring the conversation there, have fun.

Back when the convention in English (and various other languages) was that male pronouns were used in mixed or unspecified situation there was no need to point this out, it was given by the convention. Pronouns with masculine grammatical gender being exclusively applicable to men is a recent innovation, without which the problem you are trying to solve wouldn't even exist.

These shifts in meaning can of course happen organically, but I find it very curious that this particular one happened at the same time as the rise of feminism in the 20th century. More extreme examples of the same politicised language is using "womyn" instead of "woman" in order to prevent it from ending in "man".

Re: How to Design Software Good

#188

Post by paulddraper »

carlmr wrote: post #139
Asooka wrote: post #110

Earlier quoted context omitted.

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.

That would be a nicer way to do it, but it doesn't contradict what I said.

Any halfway decent developer that wants single file optimization but doesn't want to author the source code in one file will do this.

See "Unity build".

Re: How to Design Software Good

#189

Post by mort96 »

Volt wrote: post #184
mort96 wrote: post #180

Earlier quoted context omitted.

You're assuming all products are apps or websites or something with a GUI. A product could be a library, or an OS kernel, or a web API, or any number of things, where knowledge of how to make a GUI with a good UX is completely irrelevant; or the programmer could be working on a very technical part; the engineers working on, say, Safari to optimize the javascript engine's performance similarly don't need any knowledge…

There's a UX for those things too. The users would be the consumers of the API.

Obviously, but the kind of UX discussed here is obviously that of graphical applications; nobody would say that a web API's or a compiler's UX is a "stuttering mess".

Re: How to Design Software Good

#190

Post by jplayer01 »

joosters wrote: post #104
emmelaich wrote: post #13

> 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?

Uh, it does matter though. If you're using KDE as a desktop environment, you might not want to pull in all the GTK dependencies just to run a single Gnome-based application when there's an equivalent one based on KDE. It's a common convention in Linux.
Post reply on HN