Live data from Hacker News

How to Design Software Good

haiku-os.org

171–180 of 191 posts

Re: How to Design Software Good

#171

I am not sure I agree with all of this. I worry that the article encourages you to dumb-down software so that your users feel completely helpless. That is the opposite of what you should do. Your users should feel enabled and encouraged to explore and experiment. Sometimes they may encounter jargon, but if it ultimately helps them gain a better understanding if they choose to research it more, I think it's helpful. T…

I really love this philosophy. Thank you for taking the time to share.

Many developers can see the value in open source software. This philosophy claims even more value (user freedom/liberty) can added to groups outside developers by creating "open implementation software". The practicality and feasibility of this design philosophy are one story (that is probably not worth arguing over without evidence). The idea of empowering users to understand the implementation at even a rudimentary level resonates with a lot of frustrations I've had as a babied user of some software. I will try to design with this philosophy on my next personal project and see how it works!

Re: How to Design Software Good

#172

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

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

Re: How to Design Software Good

#173
post #68
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…

Also cannot read with dark reader. My eyes! -.-

This is XML, Dark Reader works for HTML only.

Re: How to Design Software Good

#174

Earlier quoted context omitted.

We need an "it" that can be applied to a person.

English has had one for a long time, “they”. Elitist prescriptivists who wanted English to be Latin because of bizarre linguistic fashion tried to purge it, but never did from general use, and prescriptivism, especially on points that have never aligned with common usage,has fallen out of favor, so there is little reason not to use it now but adherence to a particularly archaic elitism.

It’s useful to have a singular and plural form, required probably not.

Re: How to Design Software Good

#176
post #145

Earlier quoted context omitted.

I bet the cost/benefit for the company is positive, and as long the clients are happy and paying, how this guy works is irrelevant. he was rewriting a huffman compression algorithm by himself because he's bored and he wants to learn and experiment. I bet is not a good life he's living. There's a great disorder in working from your home at odd hours, it's not healthy. He would be happier working normal, fixed hours, a…

> There's a great disorder in working from your home at odd hours, it's not healthy I'd be curious in hearing you elaborate on this. I've been in a WFH setup like this for about 4 months, and while I enjoy it right now I do wonder if it'll be something I might regret after 2-3 years on this schedule. My primary reasons for working like this are that: 1. I hate being in the corporate office environment, it feels very…

I did the WFH for a year, and while the freedom is enjoyable it is very easy to slip into working very late going into 'hermit mode'. You have to be very diligent in training yourself to be productive during normal hours so you can be social in the evening.

My new situation is categorized as flexible office hours. I go into the office 2-3 days a week, enjoy good rapport with the people I work with, then WFH on Mondays and Fridays (typically). I find this to be a good balance - I have enough structure Tuesday to Thursday that I can continue this trend Monday and Friday.

Re: How to Design Software Good

#177
post #40

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

I kind of feel that you just read the title here. It's not talking about the 'fullest': An example of this would be if a music composition program has an easily-reached maximum song size because the code monkey who wrote it used a 16-bit variable instead of a 32-bit one. *While there are sometimes limitations that cannot be overcome*, the actual code written and the architecture used when it was written should have a…

I'm sure we agree 99%.

Re: How to Design Software Good

#178

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…

> 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 improve things without drawbacks, but in practice you always have to make the right trade-offs.

Re: How to Design Software Good

#179
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)

I would love to do the following experiment:

- One coder writes his product with a high quality code base.

- Another coder sits next to 3 users of his product, and hacks stuff in as fast as possible.

I would bet on the 2nd one for having the better user interface.

Re: How to Design Software Good

#180

Earlier quoted context omitted.

> the UX was a stuttering mess. Is that a good metric to judge a developer, though? Good UX requires either formal training in the field, or a very gifted individual. In my opinion it has very little to do with the quality of either the code or the developer.

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 of what good UX means for a graphical interface.

Apple and Google shouldn't fire their best compiler/JIT writers just because they write lousy GUIs.

Post reply on HN