Comment by Barrin92 | Hacker News Reader

Comment by Barrin92 | Hacker News Reader

I'd say the core of what engineering is, is building something according to formal specifications and well-defined error-rates and constraints. It need not be mathematical in nature but it has to be strict and measurable. And as a consequence, almost any engineering discipline has well-defined methodologies and processes, and engineers are formally trained.

I think this is in line with the intuition of the article. Someone who writes software for a spacecraft is an engineer because they work within extremely well defined limits and towards strictly enforced specifications. People who write software for the military or who write compilers probably do too.

I don't think this applies to how most software developers work when it comes to the web or just your average project. There is in my experience no rigor of that sort. People just write code, and sure there's performance considerations but usually not in a systematic way, and it's often more tinkering than engineering.

This makes sense to me as someone educated as an electronics engineer. I've since moved over to software development and on occasion feel it can be called engineering, but more often it cannot.

> building something according to formal specifications within constraints...

Yes this is close to what I consider engineering, but maybe it is better to say 'design something according formal specifications within a set of constraints'. Engineering is a process of design. Does this mean implementation is excluded from the definition of engineering?

Plumbers and carpenters build according to specifications and architects design the specifications yet neither are called engineers.

Software development more often than not has little in terms of formal specifications and design, and as the article points out it is very much a field of change. It also focuses mostly on implementation instead of design. That is closer to what a plumber, carpenter and other tradesmen do.

I think you are largely correct, but I think I would instead characterize it as well-defined requirements and guarantees. What I mean by these terms is: requirements are a formal statement of a problem, guarantees are a formal statement about a solution, and a specification is a formal implementation that guarantees the requirements are met.

For instance, using the case of a bridge, the requirement might be something like: "lasts 10 years, max 10 ton load", the implementation might be a steel bridge, and the guarantee of the specification might be something like: "lasts 20 years, max 20 ton load".

Put another way, the key distinction is that engineering has an objective measure of what is considered adequate (i.e. solving the problem) and an expectation that only adequate solutions should be implemented.

The only formal specification of a software is the software itself. If there would exist a way to specify exactly what a program should do formally you wouldn't need the programmer: you already have the formal specification, can't you just compile that to executable code?

A formal specification doesn't make a lot of sense, if no sense at all. It's a waste of time and you will end up doing the work two times, one to write the specification and then to translate that specification in a real programming language.

The most difficult part of the job of the programmer is not into writing the code, it's into translating the informal specification from the customer to a formal specification in the form of computer code.

Reply on news.ycombinator.com