decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Engineers play, Programmers should play too | 67 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Engineers play, Programmers should play too
Authored by: Anonymous on Tuesday, February 12 2013 @ 09:41 AM EST

Real engineers do the same thing all the time. That's how we learn and build new stuff. A lot of it falls apart, however we learn in the process.

What scares me is engineers designing bridges that haven't randomly played with bolts. What did they miss? Sometimes it is something significant.

[ Reply to This | Parent | # ]

Differences yet Similarities in Attitude
Authored by: Chromatix on Tuesday, February 12 2013 @ 06:25 PM EST
It is sometimes said that if buildings were built the same way as software, the first woodpecker to come along would destroy the whole of human civilisation. That hints at the major differences between software and civil engineering. Yet there can also be similarities.

In civil engineering, it is often possible to reuse a design, or a family of designs, to solve a series of related problems. So there were military bridges designed as kits of parts to be assembled on site in a relatively short time, to reinstate a road or a railway destroyed by enemy action so that supply trains or tanks could roll across it. Some of those bridges were also used to repair accidentally damaged bridges, and despite their age and nominally "temporary" nature, are still in use because they have proved adequate and surprisingly robust. Such economy of design is also found in the software- engineering practices of shared libraries and code reuse.

The general attitude of civil engineers is to build a bridge stronger than it needs to be, if possible - and if there is any uncertainty, they will err on the safe side. The practical upshot is that early railway bridges and viaducts, built in the early-to-mid Victorian era when locomotives sometimes weighed as little as 20 tons and wagons might have carried 12 tons each, still serve in their original capacity in the present day, when locomotives more typically weigh 120 tons and wagons can weigh as much as 100 tons (in Britain - other countries may run even heavier trains). One of these bridges is the famous Maidenhead bridge built by Isembard Kingdom Brunel (a man with a hilariously over- engineered name), which others of his time were sure would collapse even under the weight of contemporary trains. As engineering has improved it's understanding of the safe limits of various structures, these bridges have been found to be capable of withstanding far more than their original designers assumed. Meanwhile if we look at work by well-known and well- respected software engineers, we will often find similar "sanity checks" and "safety valves" that aim to make their software more robust than it absolutely needs to be.

In fact, the modern software environment doesn't face merely woodpeckers but the equivalent of termites, sulphuric acid, flooding, high winds, speeding juggernauts and kamikaze jetliners, all aimed at every conceivable weak point in deliberate or accidental efforts to demolish their structure. It is a robust piece of work indeed that can survive all of that without failing. Bridges have fallen to just one of these challenges many times, although modern bridges often aim to be more robust against them than older designs.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )