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

81–90 of 119 posts

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

#81

Post by whstl »

johnfn wrote: post #56
whstl wrote: post #31

Earlier quoted context omitted.

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

I don't know what to say.

That’s a logic error. The claim was that "inconsistent but good" can exist, not that "inconsistent == good". Responding with one example where "inconsistent" turned out badly is a totally different claim and doesn't refute what GP says.

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

#82

Post by whstl »

tonyhart7 wrote: post #55
whstl wrote: post #32

Earlier quoted context omitted.

> 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

And I disagree.

My assertion is that software that has only bad parts is way more unpredictable than software that has both good and bad.

For multiple reasons: because "bad" is not necessarily internally consistent. Because it's buggy.

Unless, again, "bad" here means "objectively good quality but I get to call it bad because it's not in the way I like to write code".

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

#83

Post by kayo_20211030 »

whstl wrote: post #79
kayo_20211030 wrote: post #36

Earlier quoted context omitted.

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

> Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > 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. Same for software. > I don't want…

Then we're in violent agreement.

The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application, to a pace that's consistent with the pace of the system you're building.

> faulty assumption that they must apply it all immediately

No truer word was ever said. Everyone is attracted to shiny things.

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

#84

Post by johnfn »

whstl wrote: post #81
johnfn wrote: post #56

Earlier quoted context omitted.

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

I don't know what to say. That’s a logic error. The claim was that "inconsistent but good" can exist, not that "inconsistent == good". Responding with one example where "inconsistent" turned out badly is a totally different claim and doesn't refute what GP says.

Who said that I only had one example? I just listed one so you'd have an idea of what I was talking about. I could give you like a hundred. This is a heuristic I've developed over a lot of time working in codebases with inconsistencies and repeatedly getting burned.

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

#85

Post by whstl »

kayo_20211030 wrote: post #83
whstl wrote: post #79

Earlier quoted context omitted.

> Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > 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. Same for software. > I don't want…

Then we're in violent agreement. The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application , to a pace that's consistent with the pace of the system you're building. > faulty assumption that they must apply it all immediately No truer word was ever said. Everyone is attracted to shiny things.

Ah nice, then yes, we agree!

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

#86

Post by tormeh »

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…

It's an infuriatingly accurate sketch. A team should usually have responsibility for no more than one service. There are many situations where this is not possible or desired (don't force your kafka connect service into your business logic service), but it's the ideal, IMO. More services mean more overhead. But someone read a blog post somewhere and suddenly we have four microservices per dev. Fun times.

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

#87

Post by emerent »

johnfn wrote: post #56
whstl wrote: post #31

Earlier quoted context omitted.

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

You're getting a lot of pushback in the comments here and I don't understand why. This is exactly right. Stay consistent with the existing way or commit to changing it all (not necessary all at once) so it's consistent again, but better.

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

#88

Post by myth2018 »

bitwize wrote: post #70
QuercusMax wrote: post #65

Earlier quoted context omitted.

I don't think I've ever worked on a project that had "system analysts". You might as well say "this is what happens when you don't allow sorcerers to peer into the future". Best I've ever had are product managers who maybe have a vague idea of what the customer wants.

Well, that's just the problem, innit. In decades past, systems analysts performed a vital function, viewing the business and understanding its information flows as a whole and determining what information systems needed to be implemented or improved. Historically, in well-functioning information-systems departments, the programmer's job was confined to implementation only. Programming was just a translation step, goi…

I worked for a somewhat large bank that used to do this "system analysis" job at its beginnings. Don't recall how they called this process step, but the idea was the same. Besides the internal analysts, they used to hire consultancies full of experienced ladies and gentlemen to design larger projects before coding started.

Sometimes they were hired only to deliver specifications, sometimes the entire system. The software they delivered was quite stable, but that's beyond the point. There sure were software issues there, but I was impressed by how those problems were usually contained in their respective originating systems, rarely breaking other software. The entire process was clear enough and the interfaces between the fleet of windows/linux/mainframe programs were extremely well documented. Even the most disorganized and unprofessional third-party suppliers had an easier time writing software for us. It wasn't a joy, but it was rational, there was order. I'm not trying to romanticize the past, but, man, we sure un-learned a few things about how to build software systems

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

#89

Post by kevinlearynet »

The best applications I've ever been a part of building, measured by user satisfaction, are those where the engineers:

1. Value simple, effective systems

2. Understand all use cases, because they use it

3. Have enough freedom to fix small things as they find them

#3 is controversial sometimes, but I believe this flexibility and creative freedom for devs leads to much happier people and much better products.

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

#90

Post by octorian »

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…

The last time I worked on a project that actually had all these roles, "architect" basically meant someone who sat in meetings all day and played very little role in the actual software development of the project.

There were plenty of times where it would have been useful to have someone providing real architecture/design guidance, but no such person functionally existed.

Post reply on HN