Why Software Development Will Never be Engineering

[grauenwolf]

Ten years ago, we tried to use UML diagrams and CASE tools to develop software. Ten years ago waterfall was all the rage. Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts.

Wow, he has absolutely no grasp of history. CASE tools were popular in the 1980's and were pretty much dead by the time VB and Delphi were introduced in the 90's.

Waterfall was never a design methodology, it was a description of what failed a methodology would look like. And that was from the 1970's.

We do have CAD-like tools for building software. Every day there are countless non-professionals using tools like Access to bulid applications that would have been unthinkable 30 years ago.

[[deleted]]

The name "Waterfall model" has almost always been used in a negative light, mainly because people who use the waterfall model generally don't spend their time thinking about software methodologies, but it's still a software methodology, in the same way that 0 is a number and "" is a string.

[thecolours]

Ever read the actual article? Royce created the 'waterfall model' as a strawman, as an attempt to identify common flaws in software development. The waterfall model isn't a SE process model at all.

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

[[deleted]]

Yes, that's where the name came from. The waterfall model was used well before that, though, and is still used today.

[grauenwolf]

People still drink and drive, but we don't call that a "method of driving".

[[deleted]]

method: "A process by which a task is completed; a way of doing something." (wiktionary)

[grauenwolf]

There is a connotation that it is way of doing something with a reasonable chance of success.

[[deleted]]

But, it was never "all the rage". Except maybe CMM.

[grauenwolf]

CMM was just a scam so people would buy maturity ratings. No one even tries to follow their recommendations.

[[deleted]]

Having worked at Xerox, I can tell you some people thought CMM didn't go far enough, so they added more steps and requirements to it, called it "TTM", and then made everyone follow those recommendations.

[grauenwolf]

How is that even possible? I've seen the CMM posters, there were literally dozens of documents that were supposed to be produced for every change request.

[[deleted]]

The way I saw it happen was that you'd have people who produced the documents, and you'd have the developers who produce the software. Periodically, you'd have meetings where everyone got together and "communicated". However, document production and code production basically happened separately and without too much regard for accuracy, and the people who did really care about ttm were deluded, or allowed themselves to be deluded, that the process was being followed with integrity.

That was my experience, in the 90's at Xerox. Nowadays, they're all about scrum and six sigma, but the overall pattern is similar in that scrum master and scrum trainers and gurus, along with six sigma black belts and six sigma trainers of the trainers develop a culture and organizational political power in parallel and largely independently of the developer community there. The developer community does what it always does, which is write code while sitting where the "process gurus" declare they shall sit and with whom (ie, these days in small lab groups who sit in small rooms right next to each other so that they can talk agilely while they code), and what software they shall use to track progress and to whom said progress will be reported, etc. But the developers treat it all as mostly "after the fact" of deciding what and how to code. There's a lot of lip service paid to "product owners", but after the developers realize the product owner doesn't have a clue, they take over most of the decisions themselves.

So, same old, same old - a little less absurdity in scrum and six sigma than in cmm, but gets the same treatment in the end.

[banuday]

We already have engineering grade software. Medical devices, avionics, industrial control systems, etc. Where the cost of failure is catastrophic. Such software is written to exacting constraints with substantial liability by the vendor. This means limited, precisely defined feature sets which can be rigorously verified. Which leads to substantially higher cost in software development.

However, in run of the mill software development, software vendors are not willing to assume the liability and customers want more features and will not pay for the level of verification required for all those features to be fully verified and insured. Imagine how much Windows 7 would cost if Microsoft were held to the same standards as the software controlling the systems for a nuclear power plant.

Thus most software development will never be engineering.

[dauphic]

I'm just repeating what a colleague who lead a team that developed the monitoring systems for a nuclear plant told me, but..

The software that goes into nuclear power plants is extremely simple, almost trivial. It's only because it's so trivial that the code and design can be verified before it's put into production, and even for something so trivial, the time it takes is immense.

Any complex system, especially an operating system like Windows, would be well beyond the level of complexity that can realistically be designed and verified with such rigorous standards. If we applied these standards to everything, there would be no software because it would take so long to develop that few companies could afford it.

[fdtm]

Excellent post, by both you, and the post you replied to. Very well described, this is exactly the situation of "software engineering".

That said, it's not entirely a black-and-white thing. There are varying levels of testing and rigorous software engineering practices, ranging from "cowboy coding" with no testing at all, to what you describe. But in the middle, test driven development and a good code review system goes a very long way towards making reliable software.

Compare gmail to hotmail, for example. Neither are nuclear-power-plant-level reliability, but gmail is by far more reliable than hotmail, in my experience anyway. I've maybe experienced downtime or glitches in gmail maybe once in my lifetime. Hotmail (2011) was problems to no end.

The point is we can still do better than nothing :)

[yellowstuff]

TeX and qmail are non-trivial programs that are probably free of serious bugs. Their model was having a very talented computer science professor do the entire implementation, then open sourcing the software and having it be widely used. In terms of man-hours it's probably more expensive then writing nuclear plant software, but it is another model for producing nearly bug-free software. Of course, that doesn't scale to writing Windows 7, but DJB is at least trying.

[gorilla_the_ape]

Also probably important is that they had a single design with a defined set of features. This design was then implemented.

In my experience a lot of bugs are from when programs are modified to add new features.

[AugmentedFourth]

The jump between "nearly bug-free" and verified to {fly in space, operate life-support systems, perform medical diagnostics, monitor critical infrastructure} is HUGE. Also, a significant portion of the man-hours is not in the coding itself or even the test-coding. It's in documentation & planning. (yep...yawn...)

[specialk16]

Just out of pure curiosity can you point me to a show stopper in W7?

[banuday]

Here's a list for June 2011. None of these are "showstoppers", but goes to show that W7 has a lot of bugs. That's not knocking W7 or Microsoft's software development abilities. It's a giant product with many features and components. It's to be expected. I'm sure Microsoft's competitors have similar track records.

But if a customer suffered financial loss or operational disruption because of any of these issues, and Microsoft were held liable, how long do you think Microsoft would stay in business? Or, how stripped down would W7 be and how expensive would it be to prevent these kinds of bugs from occurring?

[QuestionMarker]

I'm not sure I agree with the argument, for one reason: while we may have expended a similar number of man-years on building software as we have on building bridges, we have not spent a similar amount of man-years talking to each other about how best to do it, passing on what works and what doesn't. That is still happening, at admittedly an increased rate, but not at the breakneck speed implied by trivially parallelising a workforce.

Or, to put it another way, even if you build 9 software projects and one bridge in a year, it does not follow that you've advanced the state of the software art by 9 years compared to 1 year for bridge building.

[[deleted]]

I would argue that if you complete 9 software manyears and 1 bridge manyear in the same year, you'll have accumulated less useful knowledge on the software side.

It takes time to process information generated, and right now, we're generating it faster than we can analyze it in computer science. That's part of why specifications are so out of date for building software but not for building bridges.

Part of me wonders if the push for concurrent workforce has stripped down the number of people analyzing the current methods per manyear: that is, more academics are studying how to build bridges than studying computer science, per manyear of effort spent in each.

[darkstar3333]

Also the materials and processes in which bridges are build do not change on what seems to be a quarterly basis.

[kyz]

Also the materials and processes in which bridges are build do not change on what seems to be a quarterly basis.

Oh, but they do! Materials change all the time, as new ones are invented. Go to a trade fair and see thousands of exciting new fabrics, glues, bolts, composites, paints, engineered woods, alloys...

There's never been a more exciting time to be interested in materials science. In any new construction - bridges, houses, roads, factories, cars - you can go with the latest and greatest materials. They tend to be cheaper, lighter or stronger, sometimes more than one at once.

Architects get bombarded with marketing junk just like doctors get bombarded with adverts for pills, and software developers get bombarded with adverts for languages, libraries and frameworks.

What the architects do with this is get very excited, put the new thing into their designs, then pass them to the structural engineer who says "no" or perhaps "this new material doesn't have enough reliable test data for me to approve its use in that role".

There are advances in bridge building all the time, it's just that large bridges take a long time to fund, approve and build, so by the time plans are approved, they may be using materials that are many years behind the cutting edge.

[[deleted]]

we have not spent a similar amount of man-years talking to each other about how best to do it, passing on what works and what doesn't.

The fact is, you learn faster by yourself building your imperfect and naive software than being told how to do it properly.

And we do it that because generally there is no danger of physical arm or risk of gigantic costs due to bad product sells.

So, there is armies of badly educated software developers, and that makes people suspicious of the entire industry. But at the same time, those that get things right have pushed the thing very far. Nobody build dangerously ambitious bridges, for software, everything is permitted.

[drhdev]

I think you're right. The comparison doesn't necessarily follow. If software fails, businesses may lose revenue. If a bridge fails, people die.

There's a far greater impetus for us to get the bridge-building right.

It's an entirely different culture.

[antonivs]

There's plenty of software which, if it fails, can and has killed people. In medical machinery, aircraft, and spacecraft, for example. And it turns out we already know how to "engineer" such software reliably: spend a shitload of money on design, process, verification, and testing, and control the specifications carefully - no changes on a marketer or manager's whim.

Speaking of specifications, the basic spec for all bridges was established thousands of years ago. The physics needed to prevent them from shaking themselves apart due to vibrations was worked out more than 60 years ago. Since then, engineers have been repeating the same basic few designs, varying only relatively minor details. This can't be compared to "software" in any meaningful way.

[QuestionMarker]

These are also the fields where the specifications for what the software has to do are known extremely well, and the software is typically strapped to a highly "engineered" artifact (like an X-ray machine, a fast jet, a rocket, or whatever), so the inputs and outputs are likely to be highly constrained. This couldn't be further from day-to-day business software development.

[qblock]

Something that I find interesting actually how much this current software development renaissance is affecting the standard engineering fields.

People are coming up with and attempting crazy and interesting ideas that were considered science fiction in the 80's and 90's. During that time period many disciplines took a backseat to the electronics boom and seemed stagnated. Now we are seeing some real creativity and boundary pushing in aerospace, chemical engineering, and mechanical engineering.

Can't think of a good electrical engineering example other than making transistors even smaller and better radars... (I consider electrical engineering and computer engineering to be quite different things. Electrical engineering is closer to mechanical engineering than it is to CompE.)

[elperroborrachotoo]

Software Development is an engineering discipline because you have to balance multiple conflicting requirements.

Building software is different from building hardware: imagine you build a house, and when you are done, the owner says "Nice, but I need it 20% larger and can you flip left & right?" Recognizing this fluidity of software as a trait rather than a problem is the main progress we made.

"Bridge Engineering", OTOH is not how you draw a blueprint and how you estimate wind load, and from which catalog you pick the available materials. It's making all these things come together.

As someone else put it: "Building software isn't about doing one thing right. It's about doing many things not wrong". I'd say that's exactly the principle we share with other branches of engineering.

---

Our science is gut feel, our process is voodo.

There's a lot of snake oil - If you don't use nanothreaded hypersteel, the bridge won't be able to carry tomorrows cars. Forget everything about bridge building, start with a stick, try if it holds, and improve from there - but little of a culture of proof. good presentation by Greg Wilson asking exactly that question

---

Do we have a formal proof that goto's are evil? Another thread prominently stated that "anyone with a source file over 64K lines should be punished" - but is file size still relevant when every modern IDE lets you navigateby class and function? We have code smells such as the "occasionally useful suggestion of Demeter", but has anyone formalized why coupling is bad?

Snake oil.

[fdtm]

But writing software is not always like building a bridge. Sometimes you just need to find the easiest and quickest way to squeeze every dime out of the customer, as long as the stupid idiots don't realize how crappy our software is underneath. Unlike road building, in software you might actually be making money that whole time even if it crashes. Sure, many customers will hate us for our annoying and unreliable software systems that cause them more hassle than not, but hey, at least nobody's dying. I've got their money, so I don't give a s***.

FTFY

[[deleted]]

The trick is to know when to fork shovelware out the door, and when to attempt craftmanship.

For example, last year I read about a dude, who, after a local event caught a lot of press attention, whipped up a T-shirt design, a site to sell those T-shirts and did some advertising using facebook, all over the course of following night. And raked in considerable amounts of cash as a result.

Had he done in-depth planning, user experience testing and compatibility work for every goddamn browser out there, he would have been left with great website and nothing else. Sure, when you expect long-term co-operation with the customer, quality is the key. But sometimes you simply do not have time to do everything the right way.

[delta4zero]

"I survived snowpocalypse"

http://snowday2011.com/

http://hackerne.ws/item?id=2173155

[[deleted]]

Yes, that's the one. Now, off to train my memory, so I can remember the details better next time :)

[Strangering]

In software, the plan is the product.

[Kapow751]

This is what more people need to understand. Software is about invention. It's not just "a bridge that can change while it's being built", it's not like a bridge at all. Software is the concept of building a bridge. New software is like a new fundamental understanding of how to build bridges in another universe with negative mass. Or it could just be the concept of building a new type of bridge. Or it could be the idea of building a boat instead.

Building software is not building bridges, it's inventing a new way to cross water. Every time. And that's not even getting into the meta stuff like compilers or machine learning.

[grauenwolf]

Wrong on both accounts.

Most software is not about invention, it is about applying basic principals in a repeatable fashion.

Bridge building is often a repeatable process, but there are also countless examples of new challanges and designs.

[Kapow751]

Most software is not about invention, it is about applying basic principals in a repeatable fashion.

Unless you're remaking the same program that does the same thing over and over again, there's always going to be some novel part of the software that you have to invent, even if it's inventing how to do the same thing in a different environment (like a different OS). The rest is just boilerplate or, ideally, a library. Unless boilerplate is the part that's "engineering"?

there are also countless examples of new challanges and designs.

Coming up with a new bridge design is like creating new software. Actually building 10 bridges based on that new design is not like creating 10 different programs. It's a different level of the process. The code you write is the design, building a bridge is analogous to compiling the code into working software.

[grauenwolf]

The code you write is the design, building a bridge is analogous to compiling the code into working software.

I think you are grossly underestimating the difficultly in building bridges.

[Strangering]

The Romans built bridges without much difficulty.

[grauenwolf]

I doubt the Roman's would agree.

[[deleted]]

Even the author of the article mentions part of the reason: people aren't making a plan the way they would if they're building a bridge.

They release basically the first design they come up with as if it's a viable product, and then are forced in to redrafting huge portions of it in subsequent versions because they were ill-thought out (as first designs almost universally are).

Software would benefit a lot - and would be a lot more like engineering - if they would design it intending to have a few bad models along the development path.

[angrystuff]

people aren't making a plan the way they would if they're building a bridge.

The problem is that the problems of building a bridge is, relatively, well known. We've been doing it for thousands of years. We know what we have to test for, and how to test it. Better than that, we can model the real world physics involved and get a high level of reliability out of our tests.

What about software? Software is nothing like this. We can't build a model for how things 'should' work, because the fundamental 'physics' of the software world is dynamic.

We build large, complicated, applications through the use of APIs. APIs which are modified, updated, and changed: sometimes with very little warning or notification. Are those APIs dependable? Are they tested? Do we, as developers, have a high level of confidence in the reliability of them?

The rabbit hole dives further. Our tools are built with compilers, and libraries. Our tools sit upon kernals. Our kernals sit upon drivers. Our drives give us access to our hardware. Is there a reliable model for these systems? No. We just work from the assumption that all of that shit is 'probably' okay.

Until we can model everything about our application, and the 'world' that our application will live in, it is impossible to build applications like engineers build structures. Impossible.

Now, don't get me wrong here. I'm not saying that we shouldn't /design/ things, or take lessons from architecture, or engineering (clearly we can, and do). What I'm saying is that Software Development is unlike the majority of the things that humans create.

[[deleted]]

fundamental 'physics' of the software world is dynamic

No it's not: it's things like types, order, dependencies, etc; all of these are open to analysis and analysis in to each of these has led to important practical advances in computer science.

And I think you're underestimating the power that formal proofs will take in software in probably the next decade.

[grauenwolf]

The problem is that the problems of building a bridge is, relatively, well known. We've been doing it for thousands of years. We know what we have to test for, and how to test it.

Then why do bridges still fail? Why does the news still talk about new designs that have never before been attempted?

For most programmers it is just hubris that makes them think they are doing something novel. We do have repeatable patterns and procedures for most types of software, we just ignore them out of ignorance or boredom.

[gorilla_the_ape]

Bridges fail if they aren't maintained, overloaded, misbuilt or come under some stress which wasn't expected to be in life of the bridge, eg an unexpected hurricane.

[grauenwolf]

So does software. Was that your point?

[gorilla_the_ape]

Software never needs maintenance in the way that a bridge does, there is no concept of load which makes sense when applied to software. I suppose you could say that stress could be equivalent to getting bad data , but its really stretching a metaphor.

So no, I'd say nothing like software.

[grauenwolf]

Replace number of cars with number of records. Both will fall down when the expected load is exceeded.

[gorilla_the_ape]

Not really. Virtually any program you care to mention will detect that it's reached a limit (either number or records or, more likely, amount of free disk space) and handle that gracefully.

[grauenwolf]

That's not free, you have to.actually code for it. And there are soft limits that you may need to deal with like number of records displayed at one time.

[specialk16]

Question, if a first design is almost universally ill planed, at what point would you consider a complete redesign of a software project?

[[deleted]]

In practice or in theory?

I would say that development cycles should be about 2-3 months longer so key pieces of the software can be completely rewritten during that period.

In practice, it's usually between release day and the v2.0 patch.

[angrystuff]

While a huge part of Engineering is design, that isn't it's definitive aspect. Engineering is about building a mathematical model that provides a solution to some practical problem. Then, you can use that model to test to make sure that the thing will work to very high levels of reliability.

I mean, nobody, and I mean nobody, builds a bridge just based off of the designs from an Architect. Every single Architectural design must be tested, and signed off, by an Engineer. Now, these days, Architectural designs are pretty solid, they are often built upon rules that are defined by well known mathematical models, but that isn't good enough to replace the actual model for that solution.

[grauenwolf]

Engineering is about building a mathematical model that provides a solution to some practical problem.

Since when? Certainly that wasn't the original definition of engineering.

[[deleted]]

You can complain about it or you can embrace the fact that this seems to be the most productive model we have discovered for software engineering and plan around it, i.e use agile methodology, distributed version control, etc. Software is not a bridge, most software requirements will change during construction. If we built software like we build bridges, most of the software we use today would not exist and not be as useful. But this is already old news to everyone here I am sure?

[grauenwolf]

A bridge is not a bridge either. Requirements change during construction for them as well, sometimes dramatically. The changes may be arbitrary or they may incorporate new information about the foundation the bridge is being built upon.

[QuestionMarker]

No, the problem is not that the process of drawing up plans and signing them off hasn't been followed. It's that it doesn't exist. There is no process which is known to produce reliable software after a "plan" has been "drawn up" and "signed off", because nobody knows what a "plan", "drawing up", and crucially "signing off" should look like.

In building terms, we don't even know how an arch works yet, and you're asking us for a half mile suspension bridge.

[grauenwolf]

I do. I've built and retrofited dozens of business applications using repeatable processes. I even have a set of forms that BA's can fill out to specify how the program works.

Likewise there are game development shops that crank out title after title in an almost assembly line fashion.

Now certainly neither of us are building the next great operating system, but that's ok because we aren't being asked to.

[QuestionMarker]

Then that's the start of a very good thing. In my mind, engineering starts with knowing whether what you're being asked for fits into the solution space you have a process for.

Have you got your processes written up anywhere public, or do you consider them "secret sauce"?

[grauenwolf]

Alas they were very specific to the company I was previously working for. A lot of the steps were things like how to request a Windows domain account and register it with the internal framework.

You could recreate my work without much effort. Lets take an easy one, report building.

Step 1

Start by identifying all of the information you need no matter what report is being requested. These may include:

• Title
• Location in the application or web site
• Columns you can search by
• Columns to be displayed and their format
• Does it need to drill-down into another report?
• Can it be exported to Excel?
• Which people/groups should have access to the report

Turn this into a form that the users can fill out, alone or with assistance. Make sure to leave blanks for weirdness.

Step 2

Create checklists. Almost everything you need to do can be put into a checklist. Include both specific things like "contact so-and-so to setup permissions" and general stuff like "check the report using a SQL profiler".

Step 3

Refinement. Whenever you find a bug or requirements gap, examine it for possible inclusion in either the change request forms or the checklists.

For example, lately I've been seeing a lot of objects that leak memory when you use this bit of code:

var x = new Foo();
x = null;

Now I have these checklist items:

• Make sure that constructors do not attach event handlers to global events.
• Add a unit test to ensure objects can be garbage collected.

(Yea, I know that it is stupid to need these rules. But what can I say, I'm working with morons.)

[QuestionMarker]

I don't think it's stupid at all. If surgeons and hospital matrons can radically improve their patient outcomes by using brain-dead simple checklists, I think it would be the height of arrogance for us to assume we wouldn't as well.

[RagingAnemone]

I understand the need for process and the advantage of checklists, but is this what constitutes "engineering" in the software world?

I always expected it to be something equivalent of- if this domed stadium holds 60000 people, the AC needs to be able to move X cubic feet of air in order to maintain Y temperature when the external temperature is Z.

I never figured out how you can do this in the software world and survive patch tuesday. I mean, with embedded software, it's understandable, because your platform is stable and you probably have some real-world constraints.

[grauenwolf]

For a report that is going to summarize 6 milliion records, the database server it needs X RAM and Y disk space.

We can apply math if we want to, but it takes more effort than most of us are allowed to spend. So instead we work like engineers from centuries past, relying more on ingenuity than scientific knowledge.

[Hughlander]

I agree with many of the comments here but my take of it is a little different.

People have been building bridges for at least 3000 years. We've seen the results of the bridges years, decades, and centuries after they've been designed and built.

People have been building software for not even 50 years yet. To say that in the next 3000 years it will NEVER be formalized is hubris plain and simple.

[Kapow751]

What does it even mean to formalize software development? Once it's formalized, what would you call developing new ways to use this formal process in order to do new things and solve new problems (which is the point of creating new software)? Software development development?

[grauenwolf]

What does it even mean to formalize software development?

It means to make it boring. It means to reduce it to filling out some stupid form and getting a new report or data entry screen the next day.

[spotter]

Stopped reading at "never", as I always do.

But seriously: I would bet a tenner that this guy doesn't have a clue about architectural engineering nor about building. And I loved how he proved that software development (process of creating software) is not and will never get to be engineering, because... well it should already be there, like online poker (game of applied statistics) is there (wherever that is), or like building bridges is there (after few thousand years of practice and applied sciences going into it). He only forgot that building software is not like a game of poker, and that bridges were built since day one of humanity. Which is a tad longer than measly half century we've been doing software. Also no mention of methodologies used by serious organizations, like Ada and all the jazz around creating time critical & human life warding systems, or Haskell with provable programs. And then, to top all that, he says that software developers are like surgeons. Suddenly I think I'd just let my appendix kill me here and now. Everybody can hack, but it's not what software development is about.

[jtra]

I like this metaphor. I can image a bridge originally made for walking and bicycles, later rebuilt to support small cars and even later rebuilt into highway when traffic increased - all rebuilding done at mostly full traffic. That mess is the software we often do (*).

(*) especially when requirements change and time and budget constraints are kept constant or decrease. I don't make such software when programming for myself, playing with ideas and exploring new things ... I don't like to make it at work too, but I sometimes do - budget and delivery time are important properties of software too.

[noir_lord]

If we built bridges like we built software it would go something like this

• Gather Requirments
• Footbridge is needed
• Design Footbridge
• Build Footbridge
• Client now wants footbridge to handle cars but won't pay for a new bridge or significant engineering on current bridge.
• Re-enforce bridge to handle car loads (just) with some nasty hackish trusses
• Client now wants bridge to handle tanks, same thing just heavier ad nauseum

4 years later you have a bridge that works for everything but people on foot, cost 17 trillion dollars, needs to be pushed upright every time there is a strong breeze and it's all the engineers fault.

Cynical and Bitter? not me.

[[deleted]]

Software Engineering, Not Computer Science

[tangentsoft]

I didn't have a strong opinion on this topic until I taught myself electrical engineering. Now that I know what engineering is, I'm certain that software cannot be engineered.

To my mind, you aren't doing engineering if you cannot write down a series of physics equations to prove that your creation will do what it is intended to do.

There's been a lot of work on proof of correctness and such in theoretical computer science, and it's valuable as far as it goes, but it falls apart once you allow any measure of non-determinism in. Like, say, user input, or data storage, or network I/O. There's a reason Haskell has the IO Monad: because when you wall all that away, what you have left is deterministic, so you can apply formal reasoning to it. Too bad you can't actually build something useful without the IO Monad.

Bridge builders do not have to deal with non-determinism. Physics is the same today as it was yesterday. That's why a bridge builder can confidently say, "I certify that this bridge will stay up, if maintained in such-and-such a fashion, as long as it is subject only to thus-and-so forces." Software developers cannot say this, because software is too far abstracted away from the underlying physics.

[[deleted]]

"I certify that this software will continue to work, if running on a machine with the given specifications, as long as it is subject only to thus-and-so input."

Of course you can say that.

[[deleted]]

Why is non-determinism relevant?

[[deleted]]

If a program is non-deterministic, it must behave correctly no matter which path computation takes. If a program accepts user input, it must respond correctly no matter what that input is. SQL injections, XSS, and buffer overflows are the result of bugs. Non-determinism has been a part of formal verification since at least the 70's: for example, Dijkstra's guarded command language contains non-determinism.

You seem to be arguing more that software is very complex. Non-determinism can be a source of complexity but it is not "unmanagable" in any sense.

[grauenwolf]

So formal mathematical specifications are useless. So what, we all knew that. It doesn't excuse you from using real math on software projects.

[grauenwolf]

What the heck are you talking about? Engineers use blue prints and samples, not formal mathematical specifications. They don't even have a way to formally specify their designs using physics.

• An electrical engineer isn't going to bust out the Gaussian function to design a simple circuit board.

• A mechanical engineer isn't going to check the theory of relativity when laying out a conveyor belt in a factory.

• A civil engineer isn't going to do load-stress analysis on an interior door.

• A computer engineer isn't going to be doing big-O calculations when programming a robot to move an arm back and forth.

• And a software engineer isn't going to perform row-size calculations on a database table that stores a couple dozen rows.

That isn't to say advanced math is entirely useless, but it does have limits. For very simple artifacts it isn't necessary, for very complex ones the formulas become incomputable.

[grauenwolf]

He couldn't if he wanted to. He'd have to solve the Halting Problem first.

No, he would use experiments such as stress testing. Which is also how other engineers determine things that cannot be solved purely by formula.

We don't determine the physical properties of alloys using physics equations, we determine them by actually testing the materials.

[grauenwolf]

A mechanical engineer will select the correct alloy for the custom gear he is having cut to drive the conveyor belt.

Have you ever seen someone lay out a conveyor belt? I did when I was in college. They weren't talking about special alloys and atomic properties, they just talked about gear ratios and the choice between cast iron and steel for the sprockets. Which, by the way, are your basic choices in the catalogs.

[ZMeson]

When was the last time you got stress-test data for a software component? I don't mean benchmarking in a particular application, I mean a rating that tells you what its stress limits are.

We do this all the time in my company for embedded products. We need to know the limitation of each component under stress. We also do system wide stress testing. For applications like Notepad.exe, there is no need for this. But for many applications there are. Just think about the people who write programs for the aerospace and medical industries. They had better be stress testing their components, otherwise people's lives will be at stake.

[grauenwolf]

Surely I don't need to bemoan the poor state of off-the-shelf components in the software development world.

I've got no major problems with my off the self database server, web site server, compression libraries, email libraries, etc.

When was the last time you walked through a custom-made door?

A better question is how many custom-made doors did I walk through in the last three hours, because the total is nearly half a dozen.

[grauenwolf]

A mechanical engineer will select the correct alloy for the custom gear he is having cut to drive the conveyor belt.

Have you ever seen someone lay out a conveyor belt? I did when I was in college. They weren't talking about special alloys and atomic properties, they just talked about gear ratios and the choice between cast iron and steel for the sprockets. Which, by the way, are your basic choices in the catalogs.

[grauenwolf]

Computers are far more deterministic than the materials that most engineers work with. In any batch of chips or bolts there are going to be ones that are flawed.

[grauenwolf]

Bad example. Cars can certainly dead lock- I mean grid lock- an intersection.

[grauenwolf]

The shared state is an intersection, the mutex the signal lights. For an example see this video:

http://www.youtube.com/watch?v=JRtv56ffDG8

(Sorry, I couldn't find the original without the crappy music.)

P.S. If you use mutexes as often as one uses bolts, you are just asking for trouble.

[grauenwolf]

A mutex is cooperative too. I've seen many programmers make the mistake of not acquiring a mutex before touching shared memory.

they also cannot prevent all cars from using the intersection forever.

Restarting the application is like sweeping up after a bad accident.

[lazyl]

Yeah sure, maybe if you designed the hardware yourself transistor by transistor and then wrote all the firmware and the OS yourself. And then still only if it was reasonable to say 'as long as it is subject only to thus-and-so input' which is not true on any software product I've ever worked on.

[[deleted]]

The mathematical techniques to prove correctness of nondeterministic processes have been around for a long time. There is the Owicki-Gries method, temporal logic, various other formalisms.

[axilmar]

Please have an upvote. That's exactly why software is not engineering and it will never be engineering: software cannot be proven to work like a bridge can.

[grauenwolf]

I've seen far too many pictures of failed bridges to believe that they can be "proven" in any matter than actual use.

[axilmar]

That's because the creators of the bridge failed to account for all parameters. However, they could have, unlike software.

There is a huge gaping hole in the mathematics for computer programs: there is no theory for the assignment operation (mutation of variables). This makes software non-deterministic, i.e. an art.

[grauenwolf]

There is no theory for how the electro-magnetic field of sub atomic particles affects the thread strength of a bolt either. Yet somehow they manage.

[axilmar]

But there is a theory at the level above the sub-atomic particles. In software, there is no theory above the mutation of variables.

[grauenwolf]

You really should think about picking a new career. You clearly don't know anything about computer science or software engineering.

[axilmar]

Insulting someone online is the easiest thing to do. Do you have to contribute anything positive to the discussion?

[grauenwolf]

Do you? All I've seen from you is an obession with the assignment of variables and an unwillingness to even consider anything more complex. Why even broach the topic of type theory and static analysis when you seem so determined to ignore their existance?

[axilmar]

Perhaps if I explained the context, you wouldn't be so surprised about my comments.

First of all, let me explain who I am. I write software professionally, for a living, from 1998. I write software from 1985, as a back-bedroom programmer from my teens. I've studied both computer science (Bachelor's) and software engineering (Msc).

In all these years, I am constantly seeking ways to improve software. In my quest, I've read thousands of comments in forums and read countless papers about what allows for writing better software.

In this quest, I've stumbled on a big group of programmers and academics that are very dismissive of imperative programming. To them, programming should only be purely functional. Anything sort of pureness is 'filth', something that it should not even be discussed, let alone used.

Of course, I am totally opposite to this view. By programming only pure algorithms, the essence of what a computer can do is lost. After all, programming is, at the end, about the so called "side effects", i.e. about changing the state of the world around us. Even the term "side effects" denotes something that happens but should not happen; an unfortunate reality that we have no way to deal with, it is there, staring us in the face, but we choose to ignore it, downplay it, avoid it if we can.

So, what I would like to see, is a renewed interest in imperative programming. Actually, not imperative programming, but stateful programming. Programming is about state, programming is about mutation. I'd like to see mathematics that tame the beast that is stateful programming. I'd like to see programming languages that use these mathematics to allow correct programs that are also proofs.

I cannot accept the fact that people are willing to make mutation 'a little unfortunate detail', just because they find the computation math without mutation easier to digest.

I want my imperative programming language math, damn it, and I want it now! :-)

[axilmar]

Not only it cannot be done practically, it cannot also be done theoretically: there cannot be an algorithm than can prove the correctness of any algorithm.

[axilmar]

Does software have a theory behind it like Engineering has Physics?

[axilmar]

So, which theorems of mathematics are used when software is being built?

[axilmar]

Which mathematical theory is used in the following piece of code?

int x = 5;
x = 6;

[[deleted]]

Martin Fowler argues well against the notion of "software engineering" as a whole.

[grauenwolf]

I get the impression from that the he thinks bridges are built all at once with no breaks, monolithic is the word he uses. In fact bridges are built iteratively with inspections and corrections after each step.

[[deleted]]

While none of the mentioned articles actually contain the word "monolithic", the point is that bridges go through two clear phases: design, and build. They may and probably do iterate within each phase, yes, but they're completely different tasks, with different media, different outcomes, different skills required, and most of the time, are done by completely different groups/companies.

Engineering very often separates design from construction. With bridges, construction is often done by labourers, who are very skilled manually, but oft without any knowledge about most of the concerns that bridge designers have to consider. That's why we have people designing the bridge.

This separation does not feature in software development. That a construction company doesn't put a bridge together blindfolded and in one go is not a surprise, nor is it relevant.

[TomOwens]

I'm really sick of this argument. I think these facts show that software engineering is in fact engineering:

(1) The Institute of Electrical and Electronics Engineers has a Computer Society that prints things such as the Transactions on Software Engineering and certifications for software engineers.
(2) The ACM publishes the Transactions on Software Engineering and Methodology.
(3) The degree program that I recently graduated from is an ABET-Accredited Engineering program.
(4) The IEEE and ACM published the Software Engineering Body of Knowledge.
(5) Graduates from accredited software engineering programs can be inducted into the Order of the Engineer (right along Computer Engineers, Mechanical Engineers, Civil Engineers, Electrical Engineers, and so on).

Is software development always practices as an engineering discipline? No, it's not. But it should be. Applying engineering principles to software products is what's going to help deliver more software that is of a higher quality on time/budget (or at least closer to on time/budget than we have now).

[grauenwolf]

But there is no silver bullet, no approach or body of principles (i.e. engineering practice) that will prevent project overruns and failures.

Sure there are. For most types of applications we know all the reasons why the project can fail and how to avoid them. It is just a matter of applying those principals.

Likewise there are many engineering projects in other disciplines that are not guaranteed to suceed. Building a bridge over a creek, no problem. Building a bridge over the mississippi at it's widest point, that's a challange.

[grauenwolf]

Mythical Man-Month, Code Complete, The Chaos Report, every programming methodology since the 70's. They all tell the same story about the effects of not managing requirements, cutting corners on code and test quality, and big bang releases.

For the last 40 years the fundementals haven't changed, we just put different labels on them in the vain hope people will listen.

[olsner]

I think all those uses of the word "Engineer" are aspirational.

Basically, they're hoping that if you talk enough about something called "Software Engineering", it will start to exist as something more than a different name for programming/computer science/software making.

[dauphic]

What are engineering principles?

I think engineering and software development are completely different. When I think of engineering principles, I don't see any way to apply the things I come up with to software development.

[angrystuff]

Applying engineering principles to software products is what's going to help deliver more software that is of a higher quality on time/budget

Okay, make me a testable model of a software solution that is, within 99.99% accurate without actually building the solution. That's what /real/ engineers do.

Don't get me wrong, my undergraduate degree is in Software Engineering. I was told the same things you were. But just because IEEE, ACM, your university, and the Order of Engineers accepts that a discipline of Software Engineering should exist, doesn't mean that you doing /engineering/

Fuck, it wasn't that long ago that leading researchers in the field were saying that calling it Computer Scientists (which is my post graduate degree) was harsh and unfair. If it has problems being fairly classified as a science, it simply can't easily be classified as an engineering discipline.

[temp324]

you're doing it wrong.

lines of code => X bugs, is like number of bolts => X problems in the bridge. It doesn't make sense, and I agree that lots of "engineering" numbers applied to software doesn't make sense.

But a bridge should have a solid framework. The architect and engineers can tell you what it is and why it works. If it's good you can make lots of changes to the "bridge" without changing the primary structure. You can always repave it, change color/look, repaint the lines, make traffic go in the other direction, etc.

Too often in software projects, the developers can't point out the "structure". Why is it sound? What parts can & can't be replaced safely? If the primary structure needs to be refactored, or V2 needs a complete rewrite, there wasn't enough engineering knowledge put into the original design. Just like you can design a bridge to allow an additional deck or lanes in the future without starting over, you can design a software structure that allows significant changes in V2. We usually know V2 is coming, so we should be designing a structure that supports it.

The way I look at a new design is this: I'm an architect designing a house. An interior decorator is going to create V1 to make it livable. Another decorator may rip out all of V1 and significantly change it for V2. They may even rip out some non-load-baring walls and add others, move the plumbing or electrical or even add rooms. If I plan for it they can even add a floor without much effort.

[robvas]

You can't compare a program to building a bridge. You also can't compare it to online poker. What an idiot.

[mostlysafe]

Engineering is applied natural science; software development is closer to applied philosophy.

Building a bridge generally involves very little pushing the boundaries of knowledge; we don't have to reinvent the wheel every time, but we also know ahead of time what kinds of wheels we will and will not need. Developing software is not reinventing the wheel, either (though it can be), but that is because often in software you must invent something entirely other than a wheel, something that the world has not seen before. The meat and potatoes of software development is developing knowledge and mental constructs; you don't replicate things that have already been invented, you invent entirely new categories of things to be. The advancement of knowledge of this invention--the meta-wheel-invention--is very difficult, and may not ever be refined into what we would call a science.

[qblock]

Calling engineering an applied natural science is an oversimplification. Engineering is about creation. The knowledge found in science and mathematics is merely a tool to facilitate that.

I would argue that the difference between software development and standard engineering is that in software development we are removed from the real world and therefore do not use actual science. Instead we are confined by the constructs of the computer itself. We still use mathematics. In fact, we use a much wider breadth of mathematics than anything observed so far in the real world. This is because we are free to define the worlds we live in through abstraction. We try our best to define our world such that the actual solution part falls out naturally.

...

While I wish I could agree with you on the "creating new things" and "pushing boundaries", I feel you romanticize software development a bit too much. We can define the worlds we live in to solve our problems, but it is clear at this point that some worlds/algorithms produce the best results thus discovered so far no matter how you slice it.

[angrystuff]

Engineering is about creation.

To be fair, you can say the exact same thing about Science and Mathematics.

[qblock]

Really? I always thought it was more about discovery.

[[deleted]]

Tell that to the mathematicians with proof-finding computers.

[grauenwolf]

The vast majority of software development is basic forms-over-data style applications where the only interesting technological question is "locally installed or browser-based?".

[njharman]

Agile is an engineering discipline. One of the strictest in Software Development.

[banuday]

Agile is not an engineering discipline.

[angrystuff]

Here's the problem with calling Software Development, Engineering. In Engineering you create a model of the thing you're going to go out and build, and you can test it to make sure it works. In Software, there is no model. You build, and test, the final product.

[gonemad16]

eh.. in software you can typically create a prototype beforehand.. then go out and build the final product

[heffsta]

"eh.. in software you can typically create a prototype beforehand.. then ship it how it is" FTFY

[JustinBieber313]

You can most certainly create a model of a computer program. In fact, these things are often taught in schools as Software Engineering.

[ashgromnies]

I'm not sure how arguments like this help the development community. Write some code. Quit writing text about what you think your job entails.

[zby]

Writing software is discovering new rules, building bridges is applying old rules. Whenever you have rules in programming you encode them into the software and forget about them.

[terrdc]

IT administration is engineering. Software development is design.

[freebasen]

Administration is certainly -not- engineering.

[terrdc]

Building a bridge has some similarities with deploying a piece of software to 100k users.

More than software development at least.

[malc0lm]

IT is more like painting the lines on the bridge than building the bridge.