
Why writing software is not like engineering - nishantmodak
http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html
======
jpatte
IMHO, writing software is actually an excellent example of an engineering
task. The reason we see all these failures in software development is, in
fact, that most software developers are NOT engineers. This is where all this
pain comes from.

The role of engineering is to apply a theoretical model/representation of a
physical fact, in order to achieve a desired result. The role of science is to
provide these models with maximum accuracy.

The better a model is (equations, empirical laws...), and the better the
engineer masters this model, the more accurate will be the expected results.

Programming languages, frameworks and patterns _are_ scientific models,
designed to represent the working of a computer. Bugs and unexpected behaviors
in a program are due to a bad application of these models. If you know
_exactly_ what you are doing (i.e. you have a deep understanding/knowledge of
these models), there is no reason for you to observe some unexpected failures.
The more experience you have, the better you understand these models, and the
more productive you are.

Of course this is just theory: in practice, things are getting quickly
complicated and it is humanly impossible to predict everything that will
happen - that's why testing exists. But my opinion is one would see much less
failures in software development if developers were actually experienced
engineers. Many developers today have no idea _what_ they are doing,
essentially because they are juniors and inexperienced. Unlike engineers, they
are not trained to mentally play with the theoretical tools they use, so they
cannot predict the results. And yes, at this point software development
becomes more an art than an engineering task. It's like juggling without being
able to predict the trajectory of the balls.

~~~
fnid2
I think the difference is that software is engineering that isn't _treated_
like engineering. For example, if a new bridge is going to be built, years and
years are spent building models, testing winds, and understanding the
geography of the location. Models are tested in wind tunnels. Dampers are
added for earthquakes that may or may not occur. Every truckload of concrete
is tested. Metals are designed for exact specifications.

When software is built, the first prototype becomes the production version.
People don't think about the future. Algorithms aren't _chosen_ they are
hacked together by someone who may or may not understand the system from
beginning to end.

The problem with software, most times, is precisely that it is not treated as
engineering. We build software to be thrown away. We don't build it to last.
This article from Dan Bricklin changed my perspective on software.

<http://www.bricklin.com/200yearsoftware.htm>

He argues that we _should_ treat software more like engineering projects and
design and build it to last.

Furthermore, we _require_ civil engineers building bridges to have degrees in
civil engineering. For software, anyone can create it. People who never went
to college even. But you'd never allow someone with only a history degree to
design a skyscraper. We've become accustomed to software written by people who
are not engineers. We don't spend the same kind of money on it and the users
of it don't really care, because unlike a bridge, their lives don't depend on
it not crashing.

~~~
yason
If we treated programming like engineering we would finish one project every
twenty years or so, and proceed to work on the next for the next twenty years.

There's simply no such counterpart in physical engineering to the iterative
programming process. Engineers _know_ how to build a bridge, that's why a
particular design succeeds and is then followed by construction properly
carried out. Programmers face _unknown and unsolved_ problems all the time; in
fact, a solved problem is not worth the programmer's time. A solved problem
has already been implemented several times and can be reused, either literally
or conceptually.

Engineers have been trying to solve the problem of a practical electric car
with acceleration, velocity, range, and reload time comparable to petrol
engines for decades. New things take time.

The reason we can write complex software in a few years instead of decades is
that in software world, luckily, the cost of building, compiling, and trashing
a prototype is negligible. Conversely, the complexity of projects has been
upped a corresponding notch but only to the extent that we can still actually
finish _some_ projects.

~~~
fnid2
If what you say is true, we'd have electronic voting. Why don't we have that?

Physical engineers face unknowns all the time. Building in unknown
environments for example. New materials. Climate change. I can't even count
the number of different designs for bridges, buildings, and cranes.

~~~
sshumaker
Yes, but at least you know you're building a bridge. Instead of, say,
developing a game and discovering your users want a photo sharing site instead
(flickr). That's an extreme example, but it's very rare to build software that
doesn't deviate significantly from what is initially specified. You could
never engineer in those conditions.

And once you build your bridge, you're finished. It just has to stand there
and take the load. It doesn't have to be unpredictably changed over the course
of it's lifetime to also function as an airstrip and shopping mall.

Even the simplest of real-world software products you typically need to grow
and adapt - sometimes dramatically - over time.

------
dutchflyboy
I disagree with this guy, every point he makes is flawed:

> Engineering components exist in the real world

Yes, and computers don't exist in some alternate dimension. People might
forget it sometimes, but if you're a real engineer, you should know how a
computer works, and know it's not magic, it's physics that make you're
computer work. Software is merely an abstraction. Secondly, math is also
engineering, but you can't touch it, can you?

> Engineering components interact in more predictable ways

No, wrong again. Software is perfectly predictable (BTW, if you want, you
could build a mathematical model of every program. 100% predictable). If you
make mistakes in other engineering branches you can get some strange results
too.

> Engineering has fewer fundamental midcourse design changes

I don't see the link between engineering and design changes here. Are you
trying to say that no single engineering project changes during it's life?
Just look at prototypes of cars, those changes are quite massive. Secondly,
ask yourself this question: How much does it cost to change a rocket design
midway compared to a software program?

> Is software development a science?

Well, that's the point, in my opinion it's engineering.

> Writing software is more an art than an engineering discipline

Some think so, but really, it should be seen as engineering. Why? Artists make
choices related to what they like, how they feel. Engineers make objective
choices (or at least they should, nobody is perfect).

Rant finished!

~~~
praptak
I agree with D. Knuth here: software is an "art", but rather like in "artisan"
not in "artist". In this context "art" means something that has some good
established practices but is not yet science.

Full article here: <http://www.paulgraham.com/knuth.html>

This is a discussion about meaning of words, so appeal to authority finishes
the argument :)

~~~
dutchflyboy
Hmm, good point, there is quite a difference. But still, I think most software
problems wouldn't exist if there were more engineers (=theoretical knowledge)
than artisans (=practical knowledge). But that's another discussion.

------
erikstarck
Algorithms are science and math. Programming is a craft. Programming in teams
is communication and human relations. Making software that's easy and fun to
use is psychology and arts. Selling that software is business and marketing.

It's the mix of all this that makes software development so challenging and
fun.

~~~
jonsen
_Theory_ is science and math. _Engineering_ is a craft. _Engineering_ in teams
is communication and human relations. Making _artifacts_ that's easy and fun
to use is psychology and arts. Selling that _artifacts_ is business and
marketing.

It's the mix of all this that makes _engineering_ development so challenging
and (potentially) fun.

------
HeyLaughingBoy
Well, engineering is not like engineering. You can't paint all "engineering"
and all "engineers" with the same brush: we're not all alike.

I've designed (physical) devices where the customer needed the end product
ready in a few days, and others where it took months. Sound anything like
software?

Software engineering is simply the process of using known concepts to build a
software product. That's no different from "traditional" engineering. Just as
you apply a different approach to a 3-page website versus an enterprise
inventory app that must failover smoothly between 5 servers, a mechanical
engineer will apply a different approach to designing a pickup truck versus a
"Little Tykes" car.

The reason programs don't look like they're engineered isn't because we don't
know how to (I'd like to think my software engineering degree counts for
_something_ ), it's because we usually don't bother.

------
Legion
Does it really matter what you call it?

At the university I attended, the Computer Science program shifted from the
Engineering department to the Science & Mathematics department during the
course of my studies. Incoming freshmen were still handed copies of SICP and
Introduction to Algorithms at the door.

~~~
InclinedPlane
The vast majority of college degree programs don't teach the core skills
necessary for success in the field, regardless of naming, but that's a
different problem.

Nevertheless, naming has a powerful influence on understanding. If people
think that software development is a science, they'll treat it that way,
similarly, how they treat it will change if they think it's an engineering
discipline or an artistic effort.

I've come around to the idea that software development is partly engineering
and partly creative, much like architecture. Treating it like a science is the
surest recipe for failure, as you'll be lucky if you ship anything worthwhile
on schedule. Treating it like engineering will result in a much higher rate of
success, with higher quality, and greater scheduling certainty, but will
frequently result in mediocrity and developer dissatisfaction. Treating it
like pure art sans engineering will probably result in lower quality, and
unpredictable scheduling. But giving proper respect to the importance of both
sound engineering and creativity seems like the sweet spot to me.

------
swombat
Another factor: Many software projects are research projects, i.e. new
technology development, because they try to do something new, whether on a
technical level or on a user interface development level.

It is fairly common for new technology development to cost vast sums of money
while yielding nothing practical. Importantly, when developing new
technologies, people understand that something may or may not come out of it,
and they accept that (somewhat).

The other factors are definitely an issue too, though:

\- Lack of physicality of the output

\- Increased likelihood of unintended interactions between components

\- Clients changing their mind halfway through (!)

------
Eddk
Computer Science in most schools is mainly mathematics and a couple of
programming courses thrown in. To become a working programmer however is a
craft that you learn and become better at through experience. The education
that you get from Computer Science is similar to that you get from say
political science. From political science you usually go to law school to
learn something more concrete. Computer Science doesn't have a law school
equivalent where you go to learn software development, usually you have to
learn on your own. Depending on the type of software development work you do,
you can find your Computer Science education quite useful. Basically any math
heavy subject is a fine prerequisite education for software development
craftsmanship.

~~~
jasonkester
That's not specific to Computer Science.

My Mechanical Engineering degree spit me out with just enough knowledge that I
could go learn how to be a Mechanical Engineer. None of the things I did on a
daily basis over the next year were things I learned in school, but I was able
to figure them out because of the things I learned.

That's the unspoken purpose of school (at least in the Engineering areas).
Your degree doesn't teach you to do any specific job. It's a 4-5 year
conditioning course for your brain. It weeds out people who won't be
successful in a certain area, and rewires everybody else so that they can
"think like and Engineer".

So if you're complaining that School didn't teach you to write CRUD apps in
Java, you're complaining about the wrong thing.

------
Ygor
A couple of questions that come to mind:

1.Is “Computer Science” the same term as “Software Engineering”? 2.Is
developing specific applications for clients that ordered them Computer
Science? 3.What about the cases when someone writes software for experiments
and research in a specific field of science (for example biology)? 4.Is
developing large enterprise systems part of the same field as is writing
software that controls robots or for example software for optimization based
on biological phenomena?

What do you think?

~~~
jpatte
1\. No: The goal of Computer Science is to provide and improve methods,
languages and frameworks to manipulate a computer. The goal of Software
Engineering is to apply these tools in order to achieve a requested result
with a computer.

2\. No, that's the purpose of Engineering. (Science creates models,
Engineering applies them)

3\. This is engineering for scientific purposes :)

4\. This is still engineering, applying different models.

------
frou_dh
I prefer the title Developer to Engineer because it conveys the iterative work
that is a large element of writing most software.

~~~
bendtheblock
I always just assumed 'engineer' was an Americanization of the word
'programmer'/'developer'. Maybe that's just my British perspective. It's also
down to my belief in some of the principles in the OP. I'd never heard
'software engineer' used outside of an academic discipline, until I got in to
startups and listened to lots of US tech podcasts and read lots of US tech
blogs.

~~~
michaelcampbell
> I always just assumed 'engineer' was an Americanization of the word
> 'programmer'/'developer'.

It often is exactly that. I'm probably being too pedantic, but as a developer
I don't allow myself to be called an engineer, though some companies have
wanted me to. I'm not one, I don't have an engineering degree nor
certification and I feel it cheapens the Engineering profession to allow that.

I guess I could be called a "scientist" since I do have a CS degree, but that
just feels weird.

~~~
frou_dh
It implies a degree of rigour that I certainly don't have. I'm conscious of
being just a punkass with an inflated job title.

------
wanderr
I disagree with points of this article, and I'm not sure about the premise. I
think Software Engineering is not as well defined as it could be but I think
it is getting better. The book Rapid Development by Steve McConnel goes a long
way in that regard.

The article states that to spend vast sums of money and end up with nothing,
you must be paying for software development. But if you follow the principles
laid out in Steve's book (and probably other software engineering books as
well), you can't end up with nothing; at every milestone you have something,
just like a building.

I also disagree that software either works or doesn't. Most software problems
are bugs, and most of the ones that make it through testing are intermittent,
seemingly randomly occuring problems. Software with bugs still works, but may
not be high enough quality that you would want to use it, similar to how you
wouldn't want to live in a house made of shoddy materials, even though it
still mostly provides shelter and "works."

~~~
cousin_it
_> at every milestone you have something, just like a building._

What? When you're building a building, you don't have something usable at each
milestone.

~~~
marcinw
Of course there are milestones (that leaves you something usable) in
construction!

* Construction start

* Foundation completed

* Structure/Frame completed

* Roofing completed

* Interior Walls

etc etc etc.. I'm not in the construction business, but anyone with even the
smallest experience (like putting up a deck) can tell you what critical
milestones need to be completed. You can't start the roofing without the
supporting foundation and structure completed -- nor can you put up deck
railings without the actual deck floor in place.

~~~
artsrc
The cool thing about software is that the order should reflect uncertainties
and risks rather than physical structure. The incomplete parts can be stubs.

------
oliveoil
Terence Parr (the author) is "the maniac behind ANTLR":
<http://www.antlr.org/>

------
projectileboy
A tangential issue is the broken metaphor of "coding as construction", which
is discussed in a classic essay by Jack Reeves:
[http://www.developerdotstar.com/mag/articles/reeves_design_m...](http://www.developerdotstar.com/mag/articles/reeves_design_main.html)

------
jared314
Software is an art because the tools, components, and abstractions are so
incomplete, and so numerous, that it becomes impossible to calculate what will
happen without trial and error.

------
krschultz
The difference between engineering physical things and software is that in
"regular engineering" the bulk of the decisions are made in the design phase.
You might have issues that crop up during implementation but largely they are
small in scope and can be resolved. In "software engineering" your design
phase is short and the implementation phase is really long. Design decisions
are happening during the coding part.

It doesn't have to be this way. If there were the equivalent of CAE tools for
software design where you could easily manipulate modules and the interfaces
between them maybe it would happen. (And no, the IDEs today are not there
yet).

We need more standard high level reusable components that all the people on
the team know. When I need something bolted together or need a simple motor,
I've got a bunch of suppliers to handle that. Java and Python and others have
these great comprehensive software libraries now, but they only go up to a
certain level. I feel like so many software projects are just duplicating the
same stuff over and over (exactly what RoR aims to solve in one domain which
is why it is so popular). People have been saying this for 30 years now, but
people were saying it in mechanical engineering for about 100 before it came
to pass so I'm not surprised it will take a long time.

There is also the difference of modeling. When I'm designing something in the
physical world I have a bunch of knowledge to apply to the problem. It's not
as easy as people are making it out to be (bridges are not _exactly_ trivial
problems, especially when compared to 99% of the software written out there.
Don't even get me started on what I work on) but there are guides. When I'm
deciding what material to use for a part I have a bunch of information about
the problem, a bunch of information about the available materials, and there
will be some decision making process trading off several factors (cost,
corrosion resistance, weight, strength, fatigue etc) and an informed choice is
made. When I want to choose between Ruby on Rails and Django, I have a bunch
of blog opinions. I can't model out the performance difference between using
C++ or Java for a robotics framework. I can't predict what this algorithmn
will do to my real time performance. You have to actually DO IT, and then
measure it. Sometimes we have this in mech eng. too and we make physical
models and test them on a small scale, that CAN happen in software engineering
but rarely does it.

So 2 bit take away: the design phase in software engineering could be a lot
more like "engineering".

~~~
sshumaker
Certainly no one here is trying to make it sound like undertaking a massive
engineering effort (like building a bridge) is easy. It's damn hard, and
harder than most software projects - and it takes a lot more time and people.

But people do build 'models' on a small scale when doing development. They're
called 'prototypes'. Except in this case, they're usually to prototype the
functionality, to collect feedback from the users, and not to test the
'engineering' suitability of a given library or framework for the final
product. Why? Because satisfying the engineering constraints is not the
hardest problem - nor the most important one - and not by a long shot. You can
replace pieces of your infrastructure, or write your own, if they don't scale
to your needs - but if your product isn't compelling, that's a non-starter.

The 'design phase' of most construction projects is mostly about making
engineering decisions. The 'design phase' of software products is more about
features, usability, and scope. While engineering plays a role, it's not the
biggest one - and you can have plenty of success with bad engineering
decisions. The great thing about software development is that if you're
successful, you can go back and revisit your earlier decisions - and fix them
if necessary.

You can build a bridge that will last a thousand years, but with software it's
more important to figure out where to build the bridge TO. Or whether people
would prefer a ferry.

------
hoggle
I like the term "Informatics" pretty much describes what is the main topic in
CS - so just being an Information Engineer/Artist is fine with me.

~~~
yardie
In other countries anyone that does anything computer related is an
informaticien. I don't like it because it's used as a catchall for an entire
industry (tech support all the way up to engineer). And, atleast in the US,
informatics implies information science. A degree you get when you want to be
a research librarian.

------
mynameishere
A Z80 can do almost everything that a modern CPU can do. Software is not quite
so generic or fungible.

------
DaniFong
A lot of what we now call software engineering should really be sociological
experimental design.

------
known
Art + Engineering = Software

------
hackermom
I've always had the opinion that "engineer" is what the americans call a
programmer. I also maintain that the largest reason behind the increasing and
worrysome trend of downright lousy and inefficient software is due to it being
"engineered", or should I say "overengineered", rather than just programmed. I
blame a bad part of "software engineering" for this downwards spiral, but not
"software engineering" itself, even if there's always a very clear distinction
in what software was done by a programmer, and what software was made by an
"engineer", with the latter pretty much always being the clunky and
inefficient one.

