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

131–140 of 191 posts

Re: How to Design Software Good

#131

Post by hailk »

laythea wrote: post #115
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…

There is a very real truth to what you say, and I don't believe it is bad. 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…

For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.

Re: How to Design Software Good

#132

Post by skohan »

lou1306 wrote: post #129
skohan wrote: post #107

Earlier quoted context omitted.

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

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

The UX design is not something I would judge someone on, but UX as a function of UI performance definitely is. If the UI is hitching, non-responsive, or getting into strange and incomprehensible states without giving me any indication how or why, I place the fault of that on the developer who implemented it.

Re: How to Design Software Good

#133

Post by maxerickson »

tonyedgecombe wrote: post #92
bengale wrote: post #85

Earlier quoted context omitted.

Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on t…

I don't think you can turn it off like that. There are no Michaelangelos spending their day slapping emulsion on drywall.

Opportunity is not evenly distributed.

Re: How to Design Software Good

#134

Post by skohan »

fredrb wrote: post #126
skohan wrote: post #107

Earlier quoted context omitted.

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

> don't care what your code looks like if you did not achieve a good end-product. I do care if your code is a mess if other engineers have to maintain it.

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.

Re: How to Design Software Good

#135

Post by int0x80 »

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.

Also Russian fighter jets vs American/NATO, in the 70s-90s timeframe for example mostly. I love the excercise of comparing the 2 design styles: completetly different aproaches to the same problem, both very effective and elegant. Just looking at the surface (copckits) of it gives one a very good impression of the differences.

Really a lot of russian vs american style examples.

Also technical (engineering) books for example. Generally russian books where a lot more condensed, raw, pure numbers/formulae etc. American school was a lot more colorful, pictures, graphics, plots, diagrams. There were people that liked better the russian style, however I think the "prettier" one has prevailed.

Interesting subject I think.

Re: How to Design Software Good

#136

Post by pnongrata »

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…

I've worked with people like that, not exactly on my team. Managers loved him because he was always "committed", working late hours to fix bugs his own botched code created.

Re: How to Design Software Good

#137

Post by jalfresi »

barrkel wrote: post #114
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.

I don't think the goal is correct. In fact, I think the implementation should reflect the user's mental model. The closer the correspondence between the implementation's model and the user model, the less likely are surprises, bugs and limitations. 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 a…

Totally agree. From the angle of UX and usability, the more closely the interface reflects the internal model of the system, the more accurate the users mental model of the software will be.

Re: How to Design Software Good

#138

Post by CathyWest »

mathw wrote: post #84
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…

Nah they're not happy, they're just trained to think it's how things have to be.

You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work.

But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.

Re: How to Design Software Good

#139

Post by carlmr »

Asooka wrote: post #110
carlmr wrote: post #96

Earlier quoted context omitted.

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

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

Re: How to Design Software Good

#140

Post by dacracot »

doubletgl wrote: post #82

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?

I came here to say this. It's not that I believe someone who is poor at grammar could not be an expert software architect, but every article makes a first impression with the title, and this one failed.
Post reply on HN