True somehow, I see a lot of people who don't understand the business well cannot, absolutely, design a good software.
You can't design software you don't work on
61–70 of 119 posts
Re: You can't design software you don't work on
#62> 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.
Re: You can't design software you don't work on
#63> 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…
My father mentored some engineering college students about 15 years ago. He came away from the experience a bit disappointed: they knew how to model a part, but not how to machine one. When he came up in the world of slide-rule-and-drafting-pencil mechanical engineering, every engineer knew, in principle at least, how to machine a part; such knowledge was necessary for good designs because a design was instructions to shop-floor personnel on how to make the part, including info like materials to be used, tolerances, tools, etc.
Re: You can't design software you don't work on
#64Earlier 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.
Possibly. Probably even.
High quality and consistent > Low quality and consistent > Variable quality and inconsistent. If you're going to be the cause of the regression into variable quality and inconsistent you'd better deliver on bringing it back up to high quality and consistent. That's a lot of work that most people aren't cut out for because it's usually not a technical change but a cultural change that's needed. How did a codebase get into the state of being below standards? How are you going to prevent that from happening again? You are unlikely to Pull Request your way out of that situation.
Re: You can't design software you don't work on
#65> 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.
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.
Re: You can't design software you don't work on
#66The job of the big-picture software architect is not to give "generic software design advice". It's precisely to see the big picture: understand the information needs and flows of the business and determine WHAT needs to be built in order to serve those precise needs. Let the programmers worry about the details. That's their job and their strength: they are detailists who are fluent in the language of the machine, but their biggest drawback is, they tend to have difficulty seeing the big picture and understanding how those details fit into a greater whole.
One does not need to be a programmer in order to be a great systems analyst/architect. Matter of fact it's the opposite: great analysts are good with people, and have a strong intuitive grasp of what people need in order to effectively run the business. Leaving that to programmers is a recipe for disaster, as without documentation of existing business systems and requirements and a solid design, programmers will happily build the wrong thing.
Re: You can't design software you don't work on
#67> 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).
[deleted]
Re: You can't design software you don't work on
#68Earlier 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…
[deleted]
Re: You can't design software you don't work on
#69> 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…
> software engineers' body of knowledge can change 52 times in a year
I understand I’m replying against the spirit of your point, but the IEEE has actually published one and it seems to get updated very slowly.
https://www.computer.org/education/bodies-of-knowledge/softw...
Re: You can't design software you don't work on
#70Earlier quoted context omitted.
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.
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, going from human requirements to machine readable code.
Beginning in about the 1980s or so, with the rise of PCs and later the internet, the "genius programmer" was lionized and there was a lot of money to be made through programming alone. So systems analysts were slowly done away with and programmers filled that role. These days the systems analyst as a separate profession is, as you say, nearly extinct. The programmers who replaced the analysts applied techniques and philosophies from programming to business information analysis, and that's how we got situations like with Bingo, WNGMAN, and Galactus. Little if any business analysis was done, the program information flows do not mirror the business information flows, and chaos reigns.
In reality, 65% of the work should be in systems analysis and design—well before a single line of code is written. The actual programming takes up maybe 15% of the overall work. And with AI, you can get it down to maybe a tenth that: using Milt Bryce's PRIDE methodology for systems analysis and development will yield specs that are precise enough to serve as context that an LLM can use to generate the correct code with few errors or hallucinations.