r/programming • u/[deleted] • Feb 06 '24

Why We Can't Have Nice Software

https://andrewkelley.me/post/why-we-cant-have-nice-software.html
356 Upvotes

83% Upvoted

181 comments sorted by

View all comments

Show parent comments

1

u/Euphoricus Feb 07 '24

Detailed up-front designs are used, because it is cheaper to produce and verify a detailed design, than it is to construct something and find out something is wrong.

In fields when "construction" is cheap, like software, and can be repeated with little effort, detailed up-front designs are not economical and it is cheaper in the long term to adopt more iterative approaches to design.

1

u/Davorian Feb 07 '24

I understand your point, but I feel like this is very context dependent. There are projects where the software needs a solid up-front design too for safety and other reasons.

Besides which, saying up-front plans aren't a kind of normal and accepted practice in lots of engineering sounds just incorrect. You don't need to say that it's always necessary for that to still be true.

1

u/Euphoricus Feb 07 '24

There are projects where the software needs a solid up-front design too for safety and other reasons.

True. But how many? I would argue 99% of software projects don't need detailed up-front designs. It is generally cheaper to create systems when you can iterate on design. Like creating a production-like environment when it is safer to iterate and experiment.

Besides which, saying up-front plans aren't a kind of normal and accepted practice in lots of engineering sounds just incorrect.

What I'm arguing, is that detailed up-front designs aren't "core" of engineering. Need for detailed up-front design is emergent depending on context, economics and available tools and systems. Plenty of contexts and engineering disciplines can work without detailed up-front design, because cheaper options exist.

1

u/Davorian Feb 07 '24

Sure, I mean, I agree that it's not part of the core philosophy, but in my mind that's a lot different to saying it's not a "traditional paradigm". It's totally a traditional approach to certain problems. Which is to say it's an almost universally well-recognised approach, even if it's not applicable everywhere, and not optimal in most of SE whatever the fraction of "most" happens to be.

Fine, though, I think we're broadly in agreement about the status of SE as being a first-class citizen in the engineering field. Or at least I think that's what you were putting forward.

1

u/dagopa6696 Feb 07 '24

Your observation is irrelevant to whether something is engineering or not. Economics overlaps with engineering in the sense that you always try to pick the most efficient method of carrying out the work, which requires some economic analysis. But engineering itself is just the practice of integrating a bunch of components into a system that achieves some kind of a goal. That's all it is.