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

21–30 of 119 posts

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

#21

Post by fogleman »

> The kinds of topic being discussed are not "is DRY better than WET", but instead "could we put this new behavior in subsystem A? No, because it needs information B, which isn't available to that subsystem in context C, and we can't expose that without rewriting subsystem D, but if we split up subsystem E here and here..."

Hmm, sounds familiar...

Bingo knows everyone's name-o

Papaya & MBS generate session tokens

Wingman checks if users are ready to take it to the next level

Galactus, the all-knowing aggregator, demands a time range stretching to the end of the universe

EKS is deprecated, Omega Star still doesn't support ISO timestamps

https://www.youtube.com/watch?v=y8OnoxKotPQ

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

#22

Post by tonyhart7 »

redrove wrote: post #20
tonyhart7 wrote: post #19

Earlier quoted context omitted.

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

So we should all write bad code to keep it predictable? raising the quality of the codebase is unacceptable under this premise.

"So we should all write bad code to keep it predictable?"

its true and false at the same time, it depends

here I can bring example: you have maintaining production system that has been run for years

there is flaw in some parts of codebase that is probably ignored either because

1. bad implementation/hacky way

2. the system outgrow the implementation

so you try to "fix" it but suddenly other internal tools stops working, customer contact the support because it change the behaviour on their end, some CI randomly fails etc

software isn't exist in a vacuum, complex interaction sometimes prevent "good" code to exist because that just reality

I don't like it either but this is just what it is

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

#23

Post by glitchc »

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.

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

#24

Post by atrettel »

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…

Reading that particular section made me think of the tree swing cartoon [1]. I agree that the best engineers have likely been on the ground making concrete changes at some point, watching bricks being laid as you said, but I have encountered quite a few supervisors who seemingly had no idea how things were being implemented on the ground. As the post says, people on the ground then sometimes have to figure out how to implement the plan even if it ignores sound design principles.

I don't view that as a failure of abstraction as a design principle as much as it is a pitfall of using the wrong abstraction. Using the right abstraction requires on the ground knowledge, and if nobody communicates that up the chain, well, you get the tree swing cartoon.

[1] https://en.wikipedia.org/wiki/Tree_swing_cartoon

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

#25

Post by ilaksh »

This is also the type of thing that makes having separate software architects that aren't actually maintaining the software generally a nonsensical idea.

There are too many decisions, technical details, and active changes to have someone come in and give direction from on high at intervals.

Maybe at the beginning it could make sense sort of, but projects have to evolve and more often than not discover something important early on in the implementation or when adding "easy" features, and if someone is good at doing software design then you may need them even more at that point. But they may easily be detrimental if they are not closely involved and following the rest of the project details.

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

#26

Post by benoau »

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…

Ugh I remember a "senior" full stack dev coming to me with various ideas for the backend - start use typeorm instead of sequelize and replace nestjs with express, for the tickets they would work on, despite having no experience with any of these. The mess of different libraries and frameworks they left in the frontend will haunt that software for years lol.

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

#27

Post by 7402 »

> if you come up with the design for a software project, you ought to be responsible for the project’s success or failure

I think this should also apply to people who come up with or choose the software development methodology for a project. Scrum masters just don't have the same skin in the game that lead engineers do.

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

#28

Post by kayo_20211030 »

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.

That's true. I do. I consider it a creative art, with some disciplinary adjacency to engineering. The creative sculptor has to know the material stone in order to make anything good with it. But, construction engineering is creative too; just different.

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

#29

Post by nullorempty »

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

In 30 years in software dev, I am yet to see any significant, detailed and consistent effort to be extended into design and architecture. Most architects do not design, do not architect.

Senior devs design and architect and then take their design to the architects for *feedback and approvals*.

These senior devs make designs for features and only account for code and systems they've been exposed to.

With an average employment term of 2 years most are exposed to a small cut of the system, which affects the depth and correctness of their design.

And architects mostly approve, sometimes I think without even reading the docs.

At most, you can expect the architects to give generic advice and throw a few buzzwords.

At large, they feel comfortable and secure in their positions and mostly don't give a shit!

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

#30

Post by kayo_20211030 »

atrettel wrote: post #24
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…

Reading that particular section made me think of the tree swing cartoon [1]. I agree that the best engineers have likely been on the ground making concrete changes at some point, watching bricks being laid as you said, but I have encountered quite a few supervisors who seemingly had no idea how things were being implemented on the ground. As the post says, people on the ground then sometimes have to figure out how to…

I agree with you. But, talk too long or too fulsomely about "abstractions" or "principles" and you'll lose the brick layers. They're paid by the course, generally. Trust them to make the site adjustments, but always verify that it's not a bad-bad-thing.
Post reply on HN