
What is Software Engineering? - stablemap
https://research.swtch.com/vgo-eng
======
Jedi72
If your life really depended on the ok outcome of the nxt program you wrote,
you would make SURE it worked. You test, re-test, try alternatives and compare
outcomes, run experiments about what happens under certain conditions. Then
you take the level you've tested it at and release it saying that your system
is capable of 1/10 what you tested it at. The application of the scientific
method to the act of building stuff so that you really _know_ the outcome, at
least within known bounds of uncertainty - thats engineering.

I'm sure this kind of work does go on throughout the world, but not in 95% of
the software that gets written. Just like how engineers aren't involved in 95%
of construction jobs, except when writing some guidelines 20 years ago. Most
programmers are plumbers and brickmakers building houses, not engineers
designing skyscrapers.

"When Roman engineers built a bridge, they had to stand under it while the
first legion marched across. If programmers today worked under similar ground
rules, they might well find themselves getting much more interested in Ada !"
— Robert Dewar, President Ada Core Technologies.

~~~
biggc
> Most programmers are plumbers and brickmakers building houses, not engineers
> designing skyscrapers.

Conversely, most mechanical engineers don't end up designing a new production
motor, they design a door handle.

------
jasode
_> Software engineering is what happens to programming when you add time and
other programmers._

To preface, I think there's room for a wide variety of meanings people assign
to words and nobody has a monopoly on what "engineering" means. That said, I
offer an alternative:

 _Software engineering = programming that accounts for real-world
_constraints_ such as performance goals, technology limitations, monetary
budgets._

Whether engineering a bridge or engineering a circuit board, they share a
common theme of optimizing multiple constraints (materials, cost, maintenance,
durability, etc).

An advantage of this view of engineering is that it can also be applied to
_solo programming_. The single programmer weighs the _tradeoffs_ to a possible
solution.

The other concept of _" add time and other programmers"_ that the blog author
is talking about is also important but in my opinion, I'd prefer the industry
find another catchy label for it. I've seen others call it "software factory
design" instead of "software engineering". The "factory" of optimizing how
multiple programmers work together is what books like Mythical Man Month,
Peopleware, etc talk about.

To apply my concept of engineering (constraints) back to the Go language...
let's say I interview a candidate and ask what his favorite language is and he
says "Go". I then follow up and ask _" Ok, Go is good. What is Go not good
for?"_ If he responds that he can't think of anything negative, _it means he
can 't do engineering with Go_. Engineering means you know the stress
weaknesses of concrete, or corrosion properties of steel, or the warts of
programming languages. If the candidate then tries to answer with the
universal _" well, good and bad programming can be done in any language"_,
that's just a restatement of the Turing Tarpit[1] and you can't do effective
_engineering_ with that view. Assembly, C/C++, Haskell, Lisp, Javascript all
have weak points that work against particular engineering goals.

[1]
[https://en.wikipedia.org/wiki/Turing_tarpit](https://en.wikipedia.org/wiki/Turing_tarpit)

~~~
varikin
> If he responds that he can't think of anything negative, it means he can't
> do engineering with Go.

I have used this tactic for interviews for quite a while. Though working
primarily with Java and the JVM, every good programmer already has a long list
of complaints. Regardless of preferred languages, frameworks, etc, everyone
should know when their tools are not sufficient. I never care what the answer
is other than they are able to articulate an answer.

~~~
waisbrot
My ability to talk at length about what's wrong with a language corresponds
directly with how well I know and love the language.

~~~
twothamendment
Yes - or how well I know and hate the language.

~~~
adrianratnapala
Only C++.

I simply don't know enough to make an intelligent argument about why, say, PHP
is a bad idea. But I have used it, and I don't want to do it again.

------
k__
I had it at university and was thinking "Well, programming is just a start,
software engineering is where the bacon is!" Whelp... I learned a bunch of UML
and SE methods (Rational etc.) and thought I'd go back to programming.

Same went with all senior programmers I worked with, they all said "I was a
programmer for the longest time! Now I want to become a software engineer!"
Just to come out of a certification course and asking "That's it?!"

I think the core ideas and principles are right, but after you learned what
can be done with code, like infrastructure etc. you don't want to meddle
around with stuff that is so far away from code as these methods. It just
slows things down too much.

The only thing I really liked were class and call diagrams to find out what's
going on in legacy codebases.

~~~
wolfgke
> Same went with all senior programmers I worked with, they all said "I was a
> programmer for the longest time! Now I want to become a software engineer!"
> Just to come out of a certification course and asking "That's it?!"

Semi-relevant: [http://programming-motherfucker.com/](http://programming-
motherfucker.com/)

------
jhpriestley
I don't think that this post really explains much about how to judge the
fitness of a feature for software engineering. From the article, `gofmt`
supports automated tooling around source code, which is good for software
engineering; but scattering import paths throughout the source tree instead of
centralizing them in something like `package.json` obviously makes automated
tooling around import paths _harder_ , so why aren't local import paths bad
for software engineering?

The whole viewpoint seems to just add a sort of high-handed argument from
authority to your typical subjective arguments over programming features.

~~~
skybrian
I agree that it's not explained clearly.

One possible reason: import statements in source code can be analyzed
regardless of which build system you're using. In the case of Go, there are at
least two important build systems ("go build" and bazel), so analysis tools
would need to support both.

On the other hand, if a package.json file were just as universally used as Go
source code, it would effectively be part of the language.

------
Joeri
The difference between programming and software engineering is the difference
between cooking for yourself and cooking in a restaurant kitchen. Similar
outcome, radically different methods.

~~~
AnimalMuppet
To put it slightly differently: software engineering is about efficiently
producing working programs at scale.

It's like chemistry and chemical engineering. Chemistry is about atoms and
molecules, and about chemical reactions. Chemical engineering is about
building and running chemical plants that efficiently produce the desired
chemicals without blowing up.

Though I guess that's the difference between computer science and software
engineering, not between programming and software engineering. Maybe in the
chemical analogy, programming is pipe-fitting in the chemical plant.

------
panda88888
I think software engineering, similar to other engineering disciplines, is
applied computer science. It means taking the theory (algorithm, data
structure, etc) and create a product (software) that does useful things in the
real world.

This means the software have to perform functions needed by its users, under
real world constraints (time, space, power, cost) while being sufficiently
robust to handle noisy inputs and variances. This also means the user will
play a large role in driving the evolution and direction of the software and
that the scope of software engineering encompassing beyond the theory but to
the entire lifecycle of he software product including development, deployment,
support, and iterative improvement.

------
nudpiedo
Software engineering is a whole discipline with several stages, it is mostly
technology agnostic for most of the process. There are even people who say
that all technology choices are just implementation details, and I do believe
the same if I need to think abstract and formulate/define the larger patterns
in area domain to work at.

That was quite empty article... what’s that? A sales pitch for the next
article?

The only comment related to design was an _implementation detail_ : the Go
modules are git urls. Even at speaking an implementation the article fails:
the article does not comment the pros, cons, consequences, problems or typical
pitfalls, and evolution in time of this decision; it even does not compare
with any other existing choices out there.

I believe these kind of articles should not be part of HN since it just aims
to exploit the audience.

Edit: format

------
AnimalMuppet
It seems to me that computer science is really not programming, but _thinking
about_ programming. The problem is, it should _also_ be thinking about
software engineering.

~~~
twothamendment
I think CS on its own can be so theoretical and perfect that it is only a part
of software engineering. A software engineer who can program can also put that
programming and CS to use within business constraints.

Hand a strong theoretical CS person a steaming pile of a project and ask for
the smallest tweak and it will take forever - that is if their head doesn't
explode or they decide to re-architect it. Task a good software engineer with
the same thing and they will get the change done with the understanding that
they also hate the steaming pile of a project, but it isn't worth any more
time.

------
nathanaldensr
Software engineering is the art of learning to lie to the technically-ignorant
around you to satisfy "business requirements."

