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

91–100 of 119 posts

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

#91

Post by octorian »

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.

Its also useful for developers to have a way of bypassing customer support to have direct visibility into what issues the actual users are experiencing. This can come in the form of browsing tickets, online forums, or social media.

Often something that's easily brushed off by a support rep will ring a bell in the mind of a developer who has recently worked in the area of the code related to the issue.

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

#92

Post by chanux »

neopointer wrote: post #76

Didn't read the article yet, but came here to say that I couldn't agree more with that sentence in the sense that the industry should stop making people "software architects", specially those that do not code at all but want to make design decisions. Software architect should be a role and not a position.

Don't want to generalize this to all but based on my experience I see it like this: The material architects build with is hollow Lego blocks. Engineers have to build with blocks that have complex machinery inside it.

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

#93

Post by wavemode »

bitwize wrote: post #62
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…

This is the kind of situation you get into when you let programmers design the business information systems, rather than letting systems analysts design the software systems.

No, this is the situation you get into when you have programmers build a system, the requirements of that system change 15 times over the course of 15 years, and then you never give those programmers time to go back and redesign, so they keep having to stack new hacks and kludges on top of the old hacks and kludges.

Anyone who has worked at a large company has encountered a Galactus, that was simply never redesigned into a simple unified service because doing so would sideline other work considered higher priority.

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

#94

Post by majormajor »

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…

Nobody wants to wait for those cycles to happen in the sorts of businesses that feature most prominently on HN. That flow works much better for "take existing business, with well defined flows, computerize it" than "people would probably get utility out of doing something like X,Y,Z, let's test some crap out."

Now, later-stage in those companies, yes, part of the reason for the chaos is because nobody knows or cares to reconcile the big-picture, but there won't be economic pressure on that without major scaling-back of growth expectations. Which is arguably happening in some sectors now, though the AI wave is making other sectors even more frothy than ever at the same time in the "just try shit fast!" direction.

But while growth expectations are high, design-by-throwing-darts like "let's write a bunch of code to make it easy to AB test random changes that we have no theory about to try to gain a few percent" will often dominate the "careful planning" approach.

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

#95

Post by [deleted] »

eviks wrote: post #47
shayway wrote: post #18

Earlier quoted context omitted.

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)

[deleted]

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

#96

Post by strogonoff »

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 some portion of the codebase would make it better, but inconsistent, you should avoid the improvement. Take note, file a ticket, make a quick branch, and get back to what you were working on; later implement that improvement across the whole codebase as its own change, keeping things consistent.

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

#97

Post by aidenn0 »

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…

And when changes are made at the site, bad things can happen: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...

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

#98

Post by Night_Thastus »

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

Consistency is best, with a slow gradual, measured movement towards 'better' where possible. When and where the opportunity strikes.

If you see a massive 50 line if/else/if/else block that can be replaced with a couple calls to std::minmax, in code that you are working on, why not replace it?

But don't go trying to rewrite everything at once. Little improvements here or there whenever you touch the code. Look for the 'easy wins' which are obvious based on more modern approaches. Don't re-write already well-written code into a new form if it doesn't benefit anything.

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

#99

Post by RaftPeople »

whstl wrote: post #80
RaftPeople wrote: post #39

Earlier quoted context omitted.

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

Once again, that's only true at the surface level. If you dig deeper you'll realize that it's possible to categorize techniques, tools, libraries, algorithms, recipes, whatever. And if you dig even deeper, you'll realize that there is foundational knowledge that lets you understand a lot of things that people complain about being too new. The biggest curse of software is people saying "no" to education and knowledge.

> Once again, that's only true at the surface level.

Can you provide concrete examples of the things that you think are foundational in software? I'm thinking beyond "be organized so it's easier for someone to understand", which applies to just about everything we do (e.g. modularity, naming, etc.)

For every different approach like OOP, functional, relation DB, object DB, enterprise service bus + canonical documents, microservices, cloud, on prem, etc. etc., they are just options with pros and cons.

With each approach the set of trade-offs is dependent on the context that the approach is applied into, it's not an absolute set of trade-offs, it's relative.

A critical skill that takes a long time to develop is to see the problem space and do a reasonably good job of identifying how the different approaches fit in with the systems and organizational context.

Here's a real example:

A project required a bunch of new configuration capabilities to be added to a couple systems using the normal configuration approach found in ERP systems (e.g. flags and codes attached to entities in the system controlling functional flow and data resolution, etc.). But for some of them a more flexible "if then" type capability made sense when analyzing the types of situations the business would encounter in these areas. For these areas, the naive/simple approach would have been possible but would have been fragile and difficult to explain to the business how to get the different configurations in different places to come together to produce the desired result.

There is no simple rule you can train someone on to spot when this is the right approach and when it is not. It's heavily dependent on the business context and takes experience.

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

#100

Post by array_key_first »

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…

IMO programs are 90% data or information, and modern software vastly underutilizes that concept.

If you know what data you need, who needs it, and where it needs to go, you have most of your system designed. If you just raw dog it then stuff is all over the place and you need hacks on hacks on hacks to perform business functions, and then you have spaghetti code. And no, I don't think domain modeling solves it. It often doesn't acknowledge the real system need but rather views the data in an obtuse way.

Post reply on HN