
You are not a software engineer (2011) - llambda
http://www.chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer/
======
trimbo
> If you were building a bridge or a skyscraper and you told me, before you
> began, that you knew exactly how it would look when it was finished – I
> would believe you. If you told me that you knew to some insane degree of
> accuracy how long it would take to get to ‘finished’ – I would believe you
> again. That’s how Engineers roll

Oh neat, maybe he can explain why the new Bay Bridge was practically a decade
over schedule and billions over budget.

Or the Burj Khalifa was about 2 years overdue?

Or the California High Speed rail is projected to be twice the budget they
thought, and they've barely broken ground on it?

So the idea that "Real Engineers" building bridges and railroads and
skyscrapers get it right in plans and schedule is total bullshit. We've seen
larger software projects, with more people working on them than these
examples, hit their deadlines (Windows comes to mind -- except Vista).

And by the way, those "Engineering" disciplines have only been around for,
what, hundreds, if not thousands of years. What they do for a living is mostly
explored territory. Software, at least at a scale to be considered engineering
at all, has been around for about 3-4 decades... maybe. And we're still
hitting up against major unknowns all the time at every level of the practice,
big and small.

edit: grammar

~~~
timr
_" And we're still hitting up against major unknowns all the time at every
level of the practice, big and small."_

I was with you until you got to this line. Let's be brutally honest: the
limiting factor for most of today's software projects (i.e. CRUD websites and
iPhone apps) is not technology. It's developer competency, experience and
self-discipline. I'd go so far to say that most working software developers
don't even _understand_ the fundamentals of the technologies they're using --
it's why you see people replacing their relational databases for key-value
stores, then trying to re-invent database join algorithms from scratch in the
application layer. Or why every new generation of "engineers" re-discovers
asynchronous programming in a new language (then promptly writes a framework
in Blub...because Blub is _so much better_ than last year's Blub.)

Truthfully, it's pretty damned hard to find gigs working on the frontier of
technology. Most projects are predictable, tedious slogs to fit together well-
understood technologies without shooting yourself in the foot. And yes,
requirements shift and clients get fussy, but that's true of any engineering
discipline. You learn to pad the schedule to compensate for the shifts. It's
part of being a professional.

As far as I can see, commercial software isn't limited by "major unknowns", so
much as an industry-wide unwillingness to learn from experience. But
hey...that tends to happen in industries when you're considered "old" at
30....

~~~
Widdershin
Ah man, this hit slightly hard as someone who just moved from Postgres to
MongoDB to avoid database migrations only to realize that I've now lost the
power of a many to many relationship.

~~~
yen223
How would one avoid database migrations by switching databases?

~~~
Widdershin
MongoDB is schemaless, so you don't have to do traditional migrations. Unless
you're making a joke about me migrating to a different database to avoid
migrations, in which case, good joke.

~~~
gaius
An undocumented and unvalidated schema, you mean. A database without a schema
is a contradiction in terms.

~~~
Widdershin
My apologies, the official documentation referred to MongoDB as "schemaless"
so I figured it was a real thing.

~~~
yen223
You aren't wrong, MongoDB _is_ schemaless in the sense that you don't need to
define a schema to use Mongo. But to use any datastore, you'll be defining a
schema somewhere - generally, in your app itself.

------
polemic
It's a slightly flowery (haha) way of putting it, but I agree whole-heartedly.
I recently held a talk at a Python conference and I asked the question:
degrees and job titles aside, are we scientists, engineers, artists or a
combination of all of these. The overwhelming response was "all of the above".

My preferred term is "artisan". A software developer is applying techniques
acquired primarily through experience, supplemented by training and outside
knowledge. The artisan has a clear vision of the end result in high-level
strokes, but the actual process and implementation is strongly dictated by
experience and intuition.

Obviously there are different branches of software developer that have more
characteristics of engineering, others of science, but I would hazard to guess
that 80% of software development is essentially a guided artistic process.

~~~
sz4kerto
You should have said to them: 'you're only f* programmers'. Just as a joke. As
a software engineer (?), I am quite fed up with people in their early 20s
calling themselves 'architects', 'artist', etc.

You're not a scientist, and not an artist. Being a scientist and a programmer
is extremely different because of a simple, seemingly minor thing: the lenght
of the feedback loop. As a programmer, your feedback loop is sometimes an
hour, sometimes a few minutes, sometimes a second (IntelliSense/other IDE
help), sometimes weeks. But for scientist, it's sometimes forever. So it's for
very different personalities.

~~~
polemic
Heh, well I _actually_ say "developer", because "artisan" sounds douchey,
"engineer" is (imo) incorrect and "programmer" tends to be a very narrowly
defined role. Design and operational sides of a "developer" are not really
adequately covered by "programmer".

But that's semantics really. We're talking about what _sort_ of techniques do
you employ. It doesn't really help to say that programmers use "programming"
techniques because it says nothing about the common attributes with other
industries / professions.

Which is where "artisan" comes in. A good developer is, IMO, more like an
great chef - excellent technique, a wealth of experience across many
disciplines and the best tools are the (ahem) recipe for success, not "good
process".

~~~
cconroy
I think "Process Implementer" is best. I can see both a mathematics and
engineering of processes. Processes instead of computer, because it is more
general and applicable to fields like biology.

Also computer science might be the worst -- there is zero science in CS.
Science has to do with nature![0]

[0] R. Feyman:
[http://www.youtube.com/watch?v=lL4wg6ZAFIM](http://www.youtube.com/watch?v=lL4wg6ZAFIM)

~~~
yohanatan
There is a lot of overlap between CS and Physics. For one example:
[http://en.wikipedia.org/wiki/Digital_physics](http://en.wikipedia.org/wiki/Digital_physics)

------
jarrett
I disagree for two reasons:

First, software engineers exist in a broader culture. The connotations of the
various words in our respective languages are not in our control. "Engineer"
and "gardener" have very different connotations. In a profession that
sometimes struggles to gain respect, it would not behoove us to use a term
that (wrongly in my opinion) is associated with lower social and professional
status. If we could rewrite the English language and define "gardener" as a
person with rare, hard-to-learn, and highly valuable skills, then perhaps we
would do well to embrace the term "software gardener." But we can't.[1]

Second, software _is_ engineering. This article seems to define engineering as
Big Design Up Front. While that may describe _part_ of what engineering _can_
entail, it's not a complete or general description. If I had to describe
engineering generally, I'd say it has to do with understanding and
manipulating complex systems, analyzing and fulfilling requirements,
distilling vague notions to concrete implementations, and building things that
work. Software fits all of that.

[1] As I hinted above, I don't think it's fair, right, or accurate to
denigrate actual gardeners as compared to software engineers. I'm stating the
way most people perceive social status, not the way I'd _like_ them to.

------
brudgers
In August 1991 during the S&L recession and fresh out of Vocational School, I
landed my first CAD jockey job drawing fabrication plans for a precast
prestressed concrete manufacturer. The first task, after running Diazos and
learning that neckties would become caught in the feed and where the reverse
button was by feel as my face was pressed to the top of the machine and my air
supply was rapidly constricting was drawing plans for a series of double tee
members [TT]. It took a couple of weeks to generate the 100 odd variations and
get them through the QA process, but then I moved on to other things.

But come October, they started to roll off the line...20+ kips of concrete a
pop and then stacked three high. To this day, the sensation is fresh; "So
that's what the fuck it really looks like."

The reason it's fresh is because it returns every time I am in the presence of
some lines I put on paper manifested.

The picture of the bridge is not the bridge. The engineer, like the hacker,
has better intuitions regarding the way in which the picture will correspond
to its instantiation - but it is still no more than a [hopefully] informed
intuition.[1]

[1] The idea that there is an Engineer rather than a thousand authors of a
successful bridge tends to be a bit absurd in modern construction practice.
Such heroics are still far more likely in software development.

------
btilly
I was hoping that a more substantial point was going to be made than this
piece of fluff. Here is the substantial point.

If you're building a skyscraper or a bridge, an engineer has to sign off on
the design. If the design subsequently proves to be defective, said engineer
is personally liable. In many places, calling yourself an engineer when you
are not licensed to sign off on designs and be liable in this way is against
the law.

We can debate whether or not extending this principle to software development
is a good idea. What we can't debate is that software development does not
currently work this way. You, the software developer, are not an engineer. If
you think a design is bad, you do not have both the legal authority and
responsibility to stand up, declare it so, and force the design to be changed
to something saner.

But saying you're not an engineer because software projects don't succeed like
projects done by real engineers - that's both silly and wrong.

~~~
lttlrck
It has already been extended into software development. Plenty of software
projects have to be signed off in aerospace, automotive, telecoms, energy and
defense. In fact I'd be amazed if it did not extend into consumer electronics
in large companies, e.g. Apple et al cannot risk bricking millions of phones
with a bad update. The point might be that there are thousands of badly run
projects, just as there are in construction.

------
PaulHoule
Ugh.

I wish we took the engineering metaphor more seriously. In particular, I'd
like to see some real consequences for malpractice on the part of
practitioners -- this would help us in our struggles with management to get
projects done successfully.

I've seen so many cases, for instance, where people screw up simple things,
such as generating primary keys, and keep making the same mistakes over and
over again. This has got to stop.

~~~
martininmelb
> In particular, I'd like to see some real consequences for malpractice on the
> part of practitioners

I agree as long as we also see some of the benefits - required registration
with a professional body - along with a requirement that certain projects
cannot use uncertified practitioners (in other words, better pay for Software
Engineers).

~~~
yetanotherphd
And worse pay for people who can't get certified for some reason.

------
nilkn
As someone who lives in the mecca of the oil and gas industry and is thus
around a lot of engineers--chemical engineers, civil engineers, mechanical
engineers, and more--I can tell you that trying to argue too passionately
about what constitutes an "engineer" is futile at this point. Engineers do
everything from physically working on an oil rig to somewhat abstract economic
analysis at a desk all day.

The only legitimate argument I can find regarding the use of the word
"engineer" is that there are actual engineering licenses that can be obtained.
But if we said that you had to have such a license to be called an engineer,
that would screw up the naming conventions in a ton of industries.

------
matthewmacleod
The fact that the feedback loop of a software engineering process is much
tighter and cheaper than that of civil engineering does not mean that it is
not engineering - that's a fallacy.

Perhaps it's less applicable to civil engineers, because of the scale and
safety requirements of their profession, but let's look at electrical
engineering. An electrical engineer will build prototypes; they will build
models; they will use computer simulations to predict how systems will behave;
they will build testing and QA infrastructure. It's definitely harder to
iterate—once you've built a million widgets, shifting circuits around is going
to be expensive—but it's not qualitatively different to developing a software
product.

As in any engineering discipline, software engineers must optimise for a
system's required qualities. In some cases, reliability might not be that high
up the list. In others—let's say medical systems, or those used in space
travel—software engineers have rigorous systems in place to ensure quality,
and in many cases substantial up-front planning and certification will be
involved.

Ultimately this seems to say that software engineering is different from
(specifically) civil engineering. I think that's broadly rather true – the
nature of civil is such that generally there are stringent safety
requirements, and indeed massive costs involved in making subsequent changes.
The majority of software does not have the same requirements, and so it's no
surprise that the process is somewhat different. And I agree that not all
development is engineering, of course, but to dismiss the entire field is a
bit of a shallow argument.

------
mrottenkolber
I disagree. When I code for my own amusement I might see myself as an artist
but when I do professional work I definitely want to see myself as an engineer
as well as a craftsman.

To me it feels as if we are just at a very early stage. It takes huge amounts
of time to learn software engineering, putting aside mastering it and humans
haven't been practicing for very long. So I'd guess that we're just clueless
enough to not be able to feel like engineers yet. We learn most of our
practical abilities from experience so thats an argument for craft, but once
we get a better understanding of what we are actually doing, and formalize it,
our job will probably be very engineery. There is just millions of problem
domains and no formal education on the domain of writing software yet (no a CS
degree is not it). And I think there is a class of applications that are
already so well understood that they do get developed in an engineering
fashion already.

------
justin_oaks
I grow tired of the endless comparisons of software development with some
other practice, profession, or physical process.

All analogies eventually break down if you take them too far. (If they didn't
then you wouldn't be comparing something to something else; you'd be comparing
something with itself.) But software development is so different from so many
other practices and processes that most comparisons to gardening, building,
finances, etc. don't provide much real value.

Its especially tiresome when it's claimed that "sofware isn't like that, it's
like THIS". In the article, I find that neither gardening nor engineering is
an especially enlightning analogy to software development.

------
Avalaxy
I just checked my diploma, it says my title is 'Engineer' (studied computer
science).

~~~
SethMurphy
I have to agree strongly with this. It's like a professional trainer calling
themselves a professor just because they teach. You are an engineer if your
diploma says so. It is an earned title, not a job description. I say this as a
CS dropout that never calls myself an engineer.

~~~
USNetizen
Engineering is about process, not about degrees. My CS degree did not at ALL
prepare me to be a software engineer. It taught be to be a programmer.
Engineering is more about the process than the technology. CS teaches theory
and technology.

~~~
SethMurphy
100% agrees, I didn't say I didn't do engineering, I just don't call myself an
engineer. Ironically, I do call myself a programmer though, and I don't need a
degree to do that. The state of CS degrees is a whole other topic, which from
the sound of it we agree upon so far. Maybe I just can't call myself a
scientist ;)

------
jwilliams
Engineering is a philosophy. First principles applied to real-world problems.

I'm not a Civil Engineer. So what? What does a Civil Engineer have in common
with an Electrical Engineer or a Chemical Engineer? Very little day-to-day.

Or an Engineer on an oil rig? They'd laugh that Engineering means getting it
right every time.

I can also tell you a Civil Engineer has very different problems if you're
building a skyscraper in Asia, somewhere waterlogged, as opposed to somewhere
geotechnically active. If you picked up your average skyscraper and dropped it
in New Zealand, you'll have problems. Saying the techniques are the same is a
gross generalisation.

------
andmarios
I would like to see him “growing” a database or a compiler, perhaps a firmware
for a car or the CAD software used by the architect to design a skyscraper.

------
zb
This is basically wrong, because it compares designing software with
constructing skyscrapers. But engineers don't construct skyscrapers, they
design them. And designing software shares many, many similarities with
designing skyscrapers.

I agree with the author though, that part of the problem is using engineering
as a metaphor (at least, I agree up to the point where he just replaces it
with his own, equally bad, metaphor). Software development is not _like_
engineering, it _is_ engineering, and the actual practice of it is as
different from civil engineering, mechanical engineering, electrical
engineering, chemical engineering or any other branch of engineering as those
fields are from each other. None of those, by the way, bear even a passing
resemblance to the description of 'engineering' contained in the post.

So yes, let's quit with the metaphors. Instead, let's talk about what
engineers actually do, which is design:
[http://www.zerobanana.com/essays/reclaiming-software-
enginee...](http://www.zerobanana.com/essays/reclaiming-software-engineering/)

~~~
kabouseng
That is actually also wrong.

Its rather a case of each engineering profession is a regulated industry with
an accreditation body, that certifies you as an engineer. Mechanical,
electrical, electronic, chemical, industrial, civil, all have standards
organisations, usually different ones in each country.

See IEEE for instance...

Also the engineer term is a protected designation in many countries, just as
doctor and laywer is...

So no. engineers aren't guys that design stuff, and until the software
industry is as regulated as the rest of the engineering industries are,
software engineer is the wrong term. The only people who can call themselves
software engineers perhaps is working in the medical device, avionics software
etc. industries.

~~~
TheCoelacanth
At least in the US (which has the largest software industry of anywhere in the
world), the title of engineer is not regulated. Only the title "Professional
Engineer" is regulated. Accreditation for engineers only applies to areas that
have an impact on public safety. This means that civil engineers usually are
accredited, but mechanical and electrical engineers usually aren't. So for
people located in the US, it is perfectly appropriate to refer to someone as a
software engineer.

~~~
kabouseng
Please don't find this reply condescending :D But Americans also call their
train operators "engineers"...

~~~
TheCoelacanth
I don't find that condescending. What I do find condescending is attempting to
apply the laws of certain countries to the world as a whole. There are, in
fact, many jurisdictions where being an engineer does not require any form of
accreditation. The fact that some jurisdictions do require accreditation does
not give engineers in other jurisdictions any less claim to the title.

~~~
kabouseng
Where did I do that? You were the one highlighting America as having the
biggest software industry...

~~~
TheCoelacanth
The part where you claimed that only people who are officially accredited are
engineers. People who live and work somewhere without such accreditation are
completely justified in calling themselves engineers without being accredited.

~~~
kabouseng
My apologies then, I was not trying to force my viewpoint, I only shared it.
Just as I don't believe anyone who's read Gray's anatomy (the book) can or
should call themselves a doctor, just the same I don't believe anyone writing
code should call themselves an engineer...

~~~
TheCoelacanth
So, according to your viewpoint, there were no doctor's in the US until the
late 1800's?

~~~
kabouseng
You'll have to provide a bit more context for me.

But again comparing modern day professions to the 19th century equivalent does
not bode well for your argument. If you'd prefer the medical industry return
to its standards and practices of the 19th century, your welcome to visit such
a doctor.

I prefer my modern day certified medical professional.

~~~
TheCoelacanth
The late 1800's is when doctors were first licensed in the US. Before that
doctors practiced medicine but were not licensed, yet they were still doctors.
Official licensing undoubtedly raises the quality of doctor's practicing
medicine, but it is not an inherent quality of being a doctor. In most places,
someone is not allowed to practice medicine without a license, but in places
without medical licensing, someone who practices medicine without a license is
still a doctor.

Engineering is the same. Licensing most likely raises the quality of
engineers, but that does not mean an unlicensed person who does the job of an
engineer is not an engineer.

~~~
kabouseng
Pray do tell where in the world is an unlicensed medical practitioner called a
docter?

My point being, in this day and age, to call yourself a docter, you must be
licensed. Bringing up history does nothing to change that fact. I would state
that should also apply for engineers, and already does in most countries.

Merely the fact that train drivers are called engineers in the US proves my
point. It dilutes the term to be basically meaningless.

~~~
TheCoelacanth
Train drivers being called engineers has nothing to do with this. It is simply
a coincidence that they happen to have the same name. They are sometimes
called "engineers" but what they do is never called "engineering". No one
thinks that the two jobs are the same thing any more than they think that an
academic doctor is the same thing as a medical doctor. With software
engineers, that is not the case. There is a great deal of academic study in
the field of "software engineering".

There are, in fact, many places where engineer is not a protected title and to
claim otherwise is just wrong. Many large countries like the US, UK and France
do not restrict the use of the title engineer. They only restrict something
like "Professional Engineer" or "Chartered Engineer".

~~~
kabouseng
It has everything to do with it. Just as much as you are saying what train
drivers does has nothing to do with engineering, just the same I am saying
writing javascript also has nothing to do with engineering...

There is a great deal of academic study in the field of "software
engineering". That I agree with, but that academic research is being done by
degree'd people, either with computer science or computer engineering degrees.
Even still they don't practice engineering, they are researchers or scientist.
Much like in the other engineering professions, scientists study and advance
the engineering fields.

They only restrict something like "Professional Engineer" or "Chartered
Engineer". Ok that I agree with, but I restate, writing code does not make you
an engineer, anymore than performing an operation makes me a doctor. Being
board certified, makes you a docter. Same with engineering.

------
yetanotherphd
I admit that I like the cachet that goes with the title "Engineer".

I have no interest in worshiping the "real" engineers with their protocols and
whatever. An engineer is qualified to build a bridge because they know how to
build a bridge. Their professional ethics and protocols are secondary. And we
certainly have ethics of our own, even if it isn't codified and we don't wear
special rings.

------
jaegerpicker
Bleh... Can we just stop with the metaphors already? Maybe I'm not an engineer
or a gardner or a scientist but maybe I am. I can be all of those things or
none of them. I know how to make software of varying types and that's enough,
how I apply those skills is a completely different thing. Maybe I'm a
biologist using python to help see the migration patterns of fish better.
Maybe I'm a web developer building highly scalable web systems in java. Maybe
I'm writing drivers at a kernel level. It doesn't matter, programming is a
skill set not a job definition. Engineers aren't just Engineers. They are
Mechanical Engineers, Electrical Engineers, etc.. Scientists are just
Scientists, they are Biologists, Chemists, and Computer Scientists. When we
want programming/software development to have that same level of social
standing we will use programming as a skill set not a job title.

------
clienthunter
Changing requirements and development landscape do not an analogy to a
gardener make.

I do not 'grow' nor 'tend' code, trusting some unknown universal force to keep
me on the right path.

I engineer buildings, bridges, roads, tunnels - all sorts. Sometimes they're
very small and sometimes they're very large but they're all subject to the
forces pushing and pulling on them - my job is to build them and keep them
upright as well as I can subject to the laws and constraints of the
environment.

I am not a gardener. I am an engineer building, modifying, and destroying
complex structures daily in a controlled dance so as to keep their
superstructure useful and safe.

Only to the naive eye could such complexity be reduced to such apparent
simplicity.

------
Systemic33
To me, engineering is about solving problems, it's about taking systematic
analytical approach to whatever problem arise. It is a state of mind, and that
is why engineering now covers everything from software to biochemistry.

------
wfraser
The part of this metaphor that I really like is how a garden is always
changing. Unlike a bridge or a building, software doesn't stand in isolation;
it's always relying on other software for something. These other pieces of the
system are in constant churn, and your software must change with it. This is
even disregarding other factors like changing customer demands. You have to
continuously prune and maintain your garden, or the weeds (continuously
changing software/hardware/services/etc. environments) will choke out your
plants. Software is never "done".

------
stephen_g
I think the largest error in this analogy is that coding is closer to what the
engineer does when designing something - not when building something. I guess
construction in software is more like compilation.

Can a civil engineer say exactly how long it will take to design a bridge? No.
Might putting more engineers on that project speed it up? Perhaps!

Coding is not so much constructing a program, but more creating detailed
descriptions of every aspect of the system's operation for someone else (an
interpreter, compiler etc.) to follow, and that is very similar to engineering
design.

------
fleitz
"Real" projects also know what they want in a year and don't expect the
engineer to double the lanes on the bridge because the bridge went viral on
social media and now needs to handle twice the traffic.

I'm not going to get into a who has bigger stones pissing contest, but lets
just say the expectations and requirements for skyscapers are different than
software.

You'd do just as well to call engineers "traffic gardners" who don't know how
to make a bridge scale.

~~~
desas
Software is more malleable than concrete though.

------
wilsonfiifi
Engineering is about following best practices based on empirical
data/knowledge as much as possible and "winging it" when faced with the
unforeseen. Although "winging it" is a bit of a loose statement because
generally unforeseen challenges are usually solved based on past experience
and quite a bit of lateral thinking.

Therefor in my opinion software development "done properly" has more in common
with engineering than gardening. :-)

------
joseph_cooney
My take on this. Not to say some people don't 'do' software engineering....but
it is still nascent. [http://jcooney.net/post/2012/02/27/What-Other-
Engineering-Di...](http://jcooney.net/post/2012/02/27/What-Other-Engineering-
Disciplines-can-Learn-from-Software-Development.aspx)

------
firegrind
Quite a few people really are software engineers, by qualification and by
profession.

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

That said, Chris has a good point that calling what you do engineering doesn't
make you an engineer.

------
throwaway0094
Dismissing all other organizations as worse at "gardening" than Google was a
bit offensive.

And the lowest bidder for contracted work often sucks, or finds ways to bill
more than the original bid. :)

~~~
cmaitchison
I said they didn't have the same soil. That would include the multitude of
internal tools they use to facilitate their software development, most of
which are not publicly available, their culture, and the aptitude of their
people.

------
lettergram
I personally prefer the term programmer. What I do is program machines to do
as I wish.

Gardener fits, but we design the plants in essence....

To me Programmer, developer, even software architect seems closer than
gardener.

------
tildeslashblog
Op clearly doesn't understand software engineering and automation. Op may be a
"software gardener" but some of us build proverbial skyscrapers.

------
coldcode
A friend's mother once gave him a handwoven little sign that said "Engineer:
faultless, accurate". As programmers we thought it was funny.

------
adamnemecek
So what exactly is the take-away of this piece?

~~~
sz4kerto
That you should not believe that classic engineering techniques work in
software. Also, do not believe that you, as a software developer, know how
engineering works in real world. You don't.

~~~
yeukhon
1\. We don't need to know how engineering works in real world. You need to be
in a domain and work in that domain to acquire that knowledge. Knowing how to
calculate stress in civil/structural engineering doesn't mean you are an
engineer. You need a job. You need an internship if you were a student.

2\. It is quite dumb to assume we build software in the same way that bridge
is built. That's essentially what Water Fall method would do. You build the
blueprint precisely, build a prototype and then build the actual bridge. I
don't see why the author would assume we think we were classical engineer. I
never assumed we would be using the same technique all the time.

~~~
sz4kerto
1\. Well, you don't need to, but it's certainly interesting. 2\. People assume
all the time that software development is engineering. That's what leads to
clashes between management and developers; clients not understanding why you
can't estimate precisely; neverending projects; etc.

It's a very important thing to understand and explain that software
development is _not_ an engineering discipline -- at least not yet. We strive
to make it another branch of engineering, that's why we have design patters,
methodologies, etc. Engineering is usually boring, but predictable, and that's
a very important property software lacks at the moment.

------
antonio0
Software Engineering is an oxymoron.

------
dogweather
This is why I became an attorney.

------
thenerdfiles
I'm a software hacker that gets paid an engineer's salary.

I use old tools (vim, terminals), like engineers use old tools (protractor,
pencil), to make comparatively much larger artifacts (search products,
management tools), like engineers (buildings, bridges).

You're not judiciously applying the metaphor. You've only rephrased what it
means to be "self-taught"; it goes without saying that we don't allow
unlicensed people to engineer things. It also goes without saying that no one
lives or dies by a faulty HTTP request header.

------
benched
I think this [silly] argument is nothing more than a special case of the
argument over whether words have inherent meaning, or derive meaning from
usage. I don't think 'software engineer' was ever meant to denote a new
subtype of engineer. I think 'software engineer' is a compound word that means
whatever it is we do. At work, whenever someone says 'get an engineer to look
at that', absolutely nobody thinks that means to call one of the 'real' kinds
of engineers on the phone. They know it means to get a software
developer/programmer/code monkey/dev or whatever you want to call people who
make software out of computer code.

~~~
USNetizen
It is far more than semantics, the term engineering denotes a rigid adherence
to processes and protocols, whereas 90% of people that call themselves
"software engineers" are just developers at best - they write code to do what
they are told it should do with very little concern for the overall processes
involved in an engineering discipline.

~~~
Brakenshire
It's closer to the British use of the word engineer, which can mean anything
from the civil engineer who designed the Channel Tunnel, to the mechanic who
repairs the trains. I think I prefer the prescriptive definition, though, it's
useful to have a word for someone expected to work with that level of planning
and rigour.

------
goldvine
I enjoyed the fresh perspective :-) Thanks for sharing

~~~
cmaitchison
You're welcome. Thanks!

~~~
j1z0
I for one really like the article. Yes it's true engineering projects aren't
anywhere near as perfect or on-time as people often given them credit for, but
that's exactly the point. People often expect engineering project to fit a agh
exile exactly. The article is about changing that perception and dealing with
the reality that as an industry we don't estimate very well at all. So we need
to change the metaphors to get people to understand more clearly what is I we
are doing. And the Gardner metaphors is apt. Great Article!

