111–120 of 191 posts
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?
> 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 d…
We recently ported nbdkit to Haiku and it was a pleasant experience dealing with the developer. However I never actually used Haiku (just reviewed and applied patches).
> 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.
There's also the aspects of form follows function, and mechanical sympathy. The use of a tool should strongly guide its shape and design, and similarly, a user should be able to develop an intuition about what the tool is good for and what it's not good for, so they can use it to maximum effectiveness, and not be frustrated when it can't cope with a problem it's not designed for.
> 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…
We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid).
The distinction has to be made between good software and well-written software. It is very possible to have well-written bad software and awfully-written good software.
I think realising this, is what makes a junior into a senior. Having the confidence to not always do what that little birdy in your head says :)
Customers buy software that solves problems, therefore good software solves problems. Customers buy good software, not well written software. These are not always mutually exclusive.
Slightly off topic, but has anyone tried Haiku? We recently ported nbdkit to Haiku and it was a pleasant experience dealing with the developer. However I never actually used Haiku (just reviewed and applied patches).
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?
Earlier quoted context omitted.
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…
The most common example I see is the password requirement that it must be between 8 and 16 characters... The 16 character limit is the main issue there... You know it has to do with the wya the data is stored.
> 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 d…
> 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…
Honestly this is my biggest disappointment as I get better as an engineer. No one except me seems to bother about simplicity, readability, maintainability (Ok a few of my colleagues do).