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

You can't design software you don't work on

seangoedecke.com

Post reply on HN
Print view View original

31–40 of 119 posts

Re: You can't design software you don't work on

#31

Post by whstl »

johnfn wrote: post #15
eviks wrote: post #8

> For instance: In large codebases, consistency is more important than “good design” But this is exactly the type of generic software design advice the article warns us about! And it mostly results in all all the bad software practices we as users know and love remaining unchanged (consistently "bad" is better than being good at least in some areas!)

I don’t know. At my place a lot of cowboy engineers decided to do things their own way. So now we have the random 10k lines written in Redux (not used anywhere else) that no one likes working with. Then there’s the part that randomly uses some other query library because they didn’t like the one we use in 95% of the code for some reason, so if you ever want to work with that code you need to keep two libraries in you…

GP is talking about "consistently bad" being worse than "inconsistently good". Not defending any inconsistency.

What you describe just sounds "inconsistent AND bad".

Re: You can't design software you don't work on

#32

Post by whstl »

tonyhart7 wrote: post #19
eviks wrote: post #8

> For instance: In large codebases, consistency is more important than “good design” But this is exactly the type of generic software design advice the article warns us about! And it mostly results in all all the bad software practices we as users know and love remaining unchanged (consistently "bad" is better than being good at least in some areas!)

Yeah its called the expectations, consistently bad is predictable software that has "good" and "bad" parts in unpredictable

> software that has "good" and "bad" parts in unpredictable

Software that has only "bad" parts is also very unpredictable.

(Unless "bad" means something else than "bad", it's hard to keep up with the lingo)

Re: You can't design software you don't work on

#34

Post by whstl »

kayo_20211030 wrote: post #4

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Constructio…

> The software engineers' body of knowledge can change 52 times in a year

Nah, those changes are only in the surface, at the most shallow level.

There's always new techniques, materials and tools in structural engineering as well.

Foundations take a lifetime to change.

Re: You can't design software you don't work on

#35

Post by jkaptur »

There are two extremes here: first, the "architects" that this article rails against. Yes, it's frustrating when a highly-paid non-expert swoops in to offer unhelpful or impossible advice.

On the other hand, there are Real Programmers [0] who will happily optimize the already-fast initializer, balk at changing business logic, and write code that, while optimal in some senses, is unnecessarily difficult for a newcomer (even an expert engineer) to understand. These systems have plenty of detail and are difficult to change, but the complexity is non-essential. This is not good engineering.

It's important to resist both extremes. Decision makers ultimately need both intimate knowledge of the details and the broader knowledge to put those details in context.

0. http://www.catb.org/jargon/html/story-of-mel.html

Re: You can't design software you don't work on

#36

Post by kayo_20211030 »

whstl wrote: post #34
kayo_20211030 wrote: post #4

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Constructio…

> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.

Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.

Re: You can't design software you don't work on

#37

Post by Scarblac »

glitchc wrote: post #23
kayo_20211030 wrote: post #4

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Constructio…

It sounds like you are making the argument that there is no established way to generate good software. If that's the case, then software isn't engineering, but rather art . The former requires established/best practices to be called a discipline, while the latter is a creative endeavour.

I think we know how to reliably make good software. E.g. NASA manages.

The problem is that doing it like that is much too expensive and too slow for most businesses.

Re: You can't design software you don't work on

#39

Post by RaftPeople »

whstl wrote: post #34
kayo_20211030 wrote: post #4

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Constructio…

> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.

> Nah, those changes are only in the surface, at the most shallow level.

Very strongly disagree.

There are limitless methods of solving problems with software (due to very few physical constraints) and there are an enormous number of different measures of whether it's "good" or "bad".

It's both the blessing and curse of software.

Re: You can't design software you don't work on

#40

Post by pixl97 »

Scarblac wrote: post #37
glitchc wrote: post #23

Earlier quoted context omitted.

It sounds like you are making the argument that there is no established way to generate good software. If that's the case, then software isn't engineering, but rather art . The former requires established/best practices to be called a discipline, while the latter is a creative endeavour.

I think we know how to reliably make good software. E.g. NASA manages. The problem is that doing it like that is much too expensive and too slow for most businesses.

>and too slow for most businesses.

A lot of this is because while a 'good' business is waiting for the 'good' software to be written, some crappy business has already written the crappy software and sold it to all the customers you were depending on. In general customers are very bad at knowing the difference between good and bad software and typically buy what looks flashy or the sales people bribe them the most for.

Post reply on HN