Hacker News Reader

Comment by kykat | Hacker News Reader

I always thought of myself as someone closer to a craftsman than an engineer, it's true that there's more "I think", "I believe" than verified working processes, their limits, etc.

But I also think that the software development process is maybe too flexible to be regulated, and tested like the other disciplines, a building is always a building, a material is always the same material.

But in software, who is going to test and verify the "materials" if they change constantly and evolve? It seems to me that any attempt at standardizing software development could slow down development so much that most won't find it to be worth it.

View on HN

A material is not always the same material, that's a non-trivial part of what engineering is about managing. Building to code is downstream of engineering, and that's more or less when you can get away with “SPF is SPF”, because the building code is already accounting for the differences in the safety margins and allowed/required techniques, vs the non-trivial difference between spruce, fir and pine.

If you want to do anything outside of what's permitted by the book, that's generally when you call an engineer.

It does seem to me that a lot of calls for formalizing things in software is trying to skip over the engineering step and jump straight to a codebook that crystalizes the common engineered solutions into a list of dos and don'ts.

I think there is space for both.

You have your "not an engineer" people who have built airplanes, cars, motorcycles and whatnot. They are good with their tools and they are able to make amazing things. Some of them might even be doing these things for a living.

Then you get your "real" engineers who need to measure and test and spec out and define limits and must be able to provably demonstrate that the bridge will not fall over.

In software you have your journeymen who build software for a living, they are good at what they do and they are building amazing things, and then you have your "engineers" who are building avionics for rockets and planes, the control software for nuclear reactors and so on. They need to prove their software works as intended and cannot venture beyond it's parameters etc.

Two very different professions, two very different types of people, yet both are (on the surface) doing something that appears very similar.

Any definition of engineering which excludes the Wright brothers and James Watt, who _invented the machine that gives the field it's name_ is a fairly poor definition. If you're creating something in a poorly understood situation by applying rules of thumb, you're doing engineering. Depending on what you are doing, flying by the seat of your pants might be really poor engineering practice, or you might be doing cutting edge work that people will be studying decades from now. Those rules of thumb might be a result of personal trial and error, or you might be getting them from a detailed technical manual. It just depends on what the state of the art is, the maturity of the field, etc.

> Any definition of engineering which excludes the Wright brothers and James Watt, who _invented the machine that gives the field it's name_ is a fairly poor definition. If you're creating something in a poorly understood situation by applying rules of thumb, you're doing engineering.

You seem to be implying that the Wright brothers built planes based on rules of thumb. They built scale models and a wind tunnel precisely so they could measure and design their plane more effectively.

A "rule of thumb" isn't just guessing. My point is that they weren't accredited members of an engineering organization following established guidelines from regulations. They were figuring it out how to build an airplane without having any real scientific theory for how airplanes could work or any established engineering practice for how to build one.

Software would benefit more from some training in philosophy than in scientific thinking.

Reply on news.ycombinator.com