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

51–60 of 119 posts

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

#51

Post by kayo_20211030 »

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.

NASA is a bit of an outlier. In the 50's through the 70's any failure, particularly a failure involving the loss of a life, would have been a national catastrophe; a blow to national prestige. So, they were super careful that it didn't happen. The spent-cost was irrelevant compared to the reputational value at stake. Honestly, it was a wise investment given the operative quid pro quo in those days. Maybe they still do good software, I don't know, but I suspect that the value at risk today makes them more cost averse, and less sensitive to poor software.

"Business" runs the same calculations. I'd posit that, as a practical matter, most businesses don't want "good" software; they want "good enough" software.

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

#52

Post by roguecoder »

The problem isn't programmers: it is cheap-ass executives obsessed with compliance.

Good software designers are facilitators. They don't tell people how to build software, but say "not like that" by making the technical requirements clear. They enable design to constantly change as the needs change.

It has been a long time since I've been at a company willing to actually employ someone in that roll. They require that their most senior engineers be focused on writing code themselves, at the expense of the team and skill-building necessary for quality software.

Instead we get bullshit like "team topologies" or frameworks that are more about how the company wants to manage teams than they are about how well the software works. We get "design documents" that are considered more important than working code. Even the senior engineers that are around aren't allowed to say "no" if it is going to interfere with some junior project manager's imagined deadline.

Software companies are penny-wise and pound foolish, resulting in shittastic spaghetti messes with microservice meatballs.

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

#53

Post by roguecoder »

augustk wrote: post #11

In the best scenario the developers are also active users of the software they produce. Then a design flaw or an error that affects the users will also affect the developers and will (hopefully) motivate the latter to correct it.

XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.

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

#54

Post by lkglglgllm »

fogleman wrote: post #21

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

Wngman.

Number of softwares not supporting iso8601, TODAY (no pun), is appalling. For example, git (claiming compatibility, but isn’t).

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

#55

Post by tonyhart7 »

whstl wrote: post #32
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

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

that's why I write the first parts of my comment

your example is just bad code that unpredictable

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

#56

Post by johnfn »

whstl wrote: post #31
johnfn wrote: post #15

Earlier quoted context omitted.

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

I didn’t really get into it, but I think that most decisions which are not consistent are made with some feeling of “I will improve upon the existing state of this ugly codebase by introducing Good Decisions”. I’m sure even the authors of the Redux section of my code felt the same way. But code with two competing standards, only one good, is almost always worse than code with one bad standard. So breaking with consistency must be carefully considered, and the developers must have the drive to push their work forward rather than just leaving behind an isle of goodness.

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

#57

Post by roguecoder »

austin-cheney wrote: post #6

I completely disagree with almost the entirety of the article. It’s all about prior experience building large things many times yourself, not using some framework or other external abstraction. When you have done this many times you absolutely can design a large application without touching the code. This is part planning and risk analysis experience and part architecture experience. You absolutely need a lot of expe…

Why are you rewriting the same application a second time?

I've personally yet to have a situation where that comes up. And every application I've ever worked on has its architecture evolve over time, as behavior changes and new domain concepts are identified.

There are recurring patterns (one might even call them Design Patterns), but by the time we've internalized them we have even less need for up-front planning. Why write the doc when you can just implement the code?

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

#58

Post by roguecoder »

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…

This is where an architect is useful, because they can ask "why?"

Sometimes there is a reason! Sometimes there isn't a reason, but it might be something we want to move everything over to if it works well and will rip out if it doesn't. Sometimes it's just someone who believes that functional programming is Objectively Better, and those are when an architect can say "nope, you don't get to be anti-social."

The best architects will identify some hairy problem that would benefit from those skills and get management to point the engineer in that direction instead.

A system that requires homogeneity to function is limited in the kinds of problems it can solve well. But that shouldn't be an excuse to ignore our coworkers (or the other teams: I've recently been seeing cowboy teams be an even bigger problem than cowboy coders.)

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

#59

Post by yunnpp »

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…

The author never really defines "consistency" anyway. Consistency of what?

I've never seen consistency of libraries and even programming languages have a negative impact. Conversely, the situation you describe, or even going out of the way to use $next_lang entirely, is almost always a bad idea.

The consistency of where to place your braces is important within a given code base and teams working on it, but not that important across them, because each one is internally consistent. Conversely, two code bases and teams using two DBs that solve the same problem is likely not a good idea because now you have two types of DBs to maintain. Also, if one team solves a DB-specific problem, say, a performance issue, it might not be obvious how the other team might be able to pick up the results of that work and benefit from it.

So I don't know. I think the answer depends on how you define "consistency", which OP hasn't done very well.

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

#60

Post by mmis1000 »

nullorempty wrote: post #29

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

> 2 years

I feel it's already enough to rewrite a big part of subsystem or change the whole thing into shit (depends on maintainer).

Software today moves quite fast. 2 year is sometimes difference between a new company and a dead company

Post reply on HN