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

41–50 of 119 posts

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

#41

Post by Sankozi »

"In large codebases, consistency is more important than “good design”" - this is completely opposite from my experience. There is some value in consistency within single module but consistency in a large codebase is a big mistake (unless in extremely rare case that code base consists entirely of very similar modules).

Modules with different requirements should not have single consistent codebase. Testing strategy, application architecture, even naming should be different across different modules.

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

#42

Post by makeitdouble »

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've been thinking about this a lot. 2~3 years is a long time, long enough to have a pretty good grasp on what a code maintained by 50~100 does in pretty concrete terms, come up with decent improvement ideas, and see at least one or two structural ideas hit production.

If the person then stays 1 or 2 more years they get a chance to further refine, but usually will be moved up the ladder Peter Principle style. If they get a chance to lead these architecture changes that company has a chance to be on a decent path technally speaking.

I'm totally with you on the gist of it: architects will usually be a central switch arranging these ideas coming from more knowledgeable places. In the best terms I see their role as guaranteeing consistency and making sure teams don't impede each other's designs.

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

#43

Post by snoman »

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

My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with.

I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success rates than iterative refactoring of a working system over time.

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

#44

Post by WillAdams »

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…

John Ousterhout has been addressing this one class at a time at Stanford for a while now, and has scaled up to a book:

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

Video overview at:

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

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

#45

Post by austin-cheney »

wduquette wrote: post #14
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…

You’re speaking of implementing yet another system of a familiar kind, I.e. a new project. The OP says that generic design works for new projects. He’s mostly talking about designing new features to be added to an existing system, in which case the design has to be contingent on the existing system.

Software developers like to think they are special. They aren't. Software, from a planning perspective, is not much different than physical construction.

When it comes to extending an existing application it really comes down to how well the base application was planned to begin with. In most cases the base application developers have no idea, because they either outsourced the planning to some external artifact or simply pushed through it one line at a time and never looked back. Either way the person writing the extension will be more concerned with the corresponding service data and accessibility than conformance to the base application code if it is not well documented and not well tested in a test automation scheme.

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

#46

Post by jpollock »

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

This isn't really about software quality, it's about the entire organization.

Consistency enables velocity. If there is consistency, devs can start to make assumptions. "Auth is here, database is there, this is how we handle ABC". Possible problems show up in reviews by being different to expectation. "Hey, where's XYZ?", "Why are you querying the database in the constructor?"

Onboarding between teams becomes a lot easier, ramp up time is smaller.

Without consistency, you end up with lots of small pockets of behavior that cause downstream problems for the org as a whole.

Every team needs extra staff to handle load peaks, resulting in a lot of idle devs.

Senior devs can't properly guess where the problematic parts of fixes or features would be. They don't need to know the details, just where things will be _difficult_.

Every feature requires coordination between the teams, with queuing and prioritizing until local staff become available.

Finally, consistency allows classes of bugs to be fixed once. Fix it once and migrate everyone to the new style.

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

#47

Post by eviks »

shayway wrote: post #18
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…

It's essentially the same problem as https://xkcd.com/927/ [How Standards Proliferate]

So following that silly comic you'd ban utf-8 because it breaks consistency? (even though in reality it beat most other standards, not just became 15th)

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

#48

Post by jpollock »

snoman wrote: post #43
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!)

My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with. I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success r…

If improving a portion of the codebase makes it better, but inconsistent...

migrate the rest of the codebase!

Then everyone benefits from the discovery.

If that's difficult, write or find tooling to make that possible.

It's in the "if it hurts, do it more often" school of software dev.

https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

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

#49

Post by Sankozi »

Waterluvian wrote: post #17
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 feel like “be consistent” is a rule that applies very broadly. There’s absolutely exceptions and nuances. But I think when weighing trade-offs, program makers by and large deeply under-weigh being consistent.

I have opposite experience. Consistency is commonly enforced in bigger corporations while it's value is not that high (often negative). Lots of strategies/patterns promoted and blindly followed without a brief reflection that maybe this is a bad solution for certain problems. TDD, onion/hexagonal architecture, SPA, React, etc.

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

#50

Post by johnbcoughlin »

snoman wrote: post #43
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!)

My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with. I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success r…

if you have some purported improvement to a codebase that would make it inconsistent, then it's a matter of taste, not fact, whether it is actually an improvement.
Post reply on HN