If architects had to work like software developers
-
The difference between developers and the other engineering fields is this: the PHB's in charge stay in charge, because the cause of software failure is not obvious to the layman (the bosses). For example, if a company builds a bridge they first do a bunch of math on known specifications. They know exactly how long the bridge will be, how many lanes, and therefore the maximum number of osmium-filled tractor trailers that can fit on the bridge at once bumper-to-bumper. They also know the exact environment for the bridge, meaning that if the bridge is built in Tampa, Florida, they need not anticipate 10 foot thick ice flows. From these long standing well tested mathematical formulas, they can create a blueprint. An exact blueprint. This blueprint will be submitted to various local and state authorities for review by their engineers. Once approved, construction begins. We have been building bridges for thousands of years, and the most of the methods now in use have been around for over a century. There is no hype stirred up by advertising. No paper companies are going around hyping up paper mache as a building material because "materials are cheaper than engineers". No 15-year-old bloggers are weighing in on concrete slip-form "best practices". Foremen know how much work a man can do in a day, and measuring that work is blatantly obvious even to casual passersby. The quality of the work is also easily measurable, and shoddy workmanship will become apparent at some point. Once the bridge is done, it's done. There is maintenance of course, but there is no such thing as "beta testers" for a bridge. Clueless upper management don't go out for a drive on the bridge when its half-done and then complain about poor cell phone reception on the lower decks and demand that the whole thing be retrofitted using fiberglass instead of steel. If the bridge collapses for some unfortunate reason one day (if it were built by the average software company it would collapse twice a week), inspectors and engineers would come in and investigate. The causes would be found quickly, and demonstrated with models and proven with math and measurements. If it was an engineering issue, the engineers get the blame. If it was lack of maintenance, the politicians get the blame. If it was cheap workmanship or faulty materials, the builders get the blame... and so on. A politician who cut the maintenance budget cannot come out and claim that a giant sea serpent was secretly humping the bridge at night. No PHB's can dodge the blame for forcing
David I Hunt wrote:
A politician who cut the maintenance budget cannot come out and claim that a giant sea serpent was secretly humping the at night.
My favorite part. :laugh:
_____________________________ There is no I in team. But there is meat in there.
-
Thanks for making the point of the article. :-D
You're welcome. That's what bitter forum trolls like me are here for :)
I have nothing against VB or .NET; all Turing-complete languages are respectable. It just seems that some languages attract one echelon of programmers, and other languages attract an entirely different echelon of programmers. :P
-
Chris Losinger wrote:
programmers really need to quit thinking of themselves as something unique and special in the world of engineering. we aren't.
Well,we are kind of special - we're about the only branch of engineering that doesn't really have a solid formal/mathematical backing to an awful lot of the practices we employ allowing us to do a decent analysis before we build the thing - and even when there is such a backing, we don't use it anyway. So, special. But not necessarily in a good way :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
A friend of mine is a cosntruction engineer designing and checking bridges. Looking at their formals/math, it is pretty sure to me that most bridges hod together because of the safety margins, not the calculations. The problems are pretty darn complex both from physics and math, so all the claculations give just guesstimates and tools to avoid obvious weaknesses. So, not very special :)
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
A friend of mine is a cosntruction engineer designing and checking bridges. Looking at their formals/math, it is pretty sure to me that most bridges hod together because of the safety margins, not the calculations. The problems are pretty darn complex both from physics and math, so all the claculations give just guesstimates and tools to avoid obvious weaknesses. So, not very special :)
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighistBut still closer to a formal basis than most software designs :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
If architects had to work like software developers: Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.[^] This is a painfully accurate take on the work environment of software developers
-
The difference between developers and the other engineering fields is this: the PHB's in charge stay in charge, because the cause of software failure is not obvious to the layman (the bosses). For example, if a company builds a bridge they first do a bunch of math on known specifications. They know exactly how long the bridge will be, how many lanes, and therefore the maximum number of osmium-filled tractor trailers that can fit on the bridge at once bumper-to-bumper. They also know the exact environment for the bridge, meaning that if the bridge is built in Tampa, Florida, they need not anticipate 10 foot thick ice flows. From these long standing well tested mathematical formulas, they can create a blueprint. An exact blueprint. This blueprint will be submitted to various local and state authorities for review by their engineers. Once approved, construction begins. We have been building bridges for thousands of years, and the most of the methods now in use have been around for over a century. There is no hype stirred up by advertising. No paper companies are going around hyping up paper mache as a building material because "materials are cheaper than engineers". No 15-year-old bloggers are weighing in on concrete slip-form "best practices". Foremen know how much work a man can do in a day, and measuring that work is blatantly obvious even to casual passersby. The quality of the work is also easily measurable, and shoddy workmanship will become apparent at some point. Once the bridge is done, it's done. There is maintenance of course, but there is no such thing as "beta testers" for a bridge. Clueless upper management don't go out for a drive on the bridge when its half-done and then complain about poor cell phone reception on the lower decks and demand that the whole thing be retrofitted using fiberglass instead of steel. If the bridge collapses for some unfortunate reason one day (if it were built by the average software company it would collapse twice a week), inspectors and engineers would come in and investigate. The causes would be found quickly, and demonstrated with models and proven with math and measurements. If it was an engineering issue, the engineers get the blame. If it was lack of maintenance, the politicians get the blame. If it was cheap workmanship or faulty materials, the builders get the blame... and so on. A politician who cut the maintenance budget cannot come out and claim that a giant sea serpent was secretly humping the bridge at night. No PHB's can dodge the blame for forcing
David I Hunt wrote:
Once approved, construction begins.
and the client can make changes to the design. which changes the architecture. which adds to cost overruns. which pisses-off engineers. which causes them to write articles about "if house building was like bridge building, nobody would have a place to live!" the client is never done changing - even when the architects are done building.
Clueless upper management don't go out for a drive on the bridge when its half-done and then complain about poor cell phone reception on the lower decks and demand that the whole thing be retrofitted using fiberglass instead of steel.
they sure do go though at all steps and demand changes! there are government inspectors, company safety inspectors, insurance companies, auditors, and the clients themselves all looking at the work in progress - and they're not out there for the joy of it. find a homebuilder and ask him if people do design changes when things are halfway done. ask him how many times a client has showed up on site and demanded that a wall be removed or moved back a foot, or that a room be expanded, etc.. how many people change the flooring after it's been partially laid. how many change the color of the bricks or shingles or the size and position of windows. it happens all the time. blueprints are not magical documents that rigidly constrain the construction. everything is subject to change, at any point in the process. the only real obstacles to change are time and money.
David I Hunt wrote:
The quality of the work is also easily measurable, and shoddy workmanship will become apparent at some point.
and people don't know it when the software they use doesn't work ?
David I Hunt wrote:
Once the bridge is done, it's done.
that's not strictly true. bridges are widened and expanded all the time.
David I Hunt wrote:
Furthermore, the bridge failure is a public thing. It will be all over the news. Everyone will know who built it and why it fell down
well, they'll know the layman version of what happened. they might not know the exact reason, which might have something to the crystalline structure of the metal used in key joints which was flawed due to minute vibrations present during casting, or whatever
-
But still closer to a formal basis than most software designs :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Well - he's a GERMAN bridge engineer (said with a faux german accent). So I expect his calculations to be above-average.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
Well - he's a GERMAN bridge engineer (said with a faux german accent). So I expect his calculations to be above-average.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighistThat goes without saying :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
If architects designed buildings the way software developers wrote programs, then the first woodpecker that came along would destroy civilization.
try
{
//Code goes here
}
catch (WoodPeckerException)
{
//Save civilization here
} -
The difference between developers and the other engineering fields is this: the PHB's in charge stay in charge, because the cause of software failure is not obvious to the layman (the bosses). For example, if a company builds a bridge they first do a bunch of math on known specifications. They know exactly how long the bridge will be, how many lanes, and therefore the maximum number of osmium-filled tractor trailers that can fit on the bridge at once bumper-to-bumper. They also know the exact environment for the bridge, meaning that if the bridge is built in Tampa, Florida, they need not anticipate 10 foot thick ice flows. From these long standing well tested mathematical formulas, they can create a blueprint. An exact blueprint. This blueprint will be submitted to various local and state authorities for review by their engineers. Once approved, construction begins. We have been building bridges for thousands of years, and the most of the methods now in use have been around for over a century. There is no hype stirred up by advertising. No paper companies are going around hyping up paper mache as a building material because "materials are cheaper than engineers". No 15-year-old bloggers are weighing in on concrete slip-form "best practices". Foremen know how much work a man can do in a day, and measuring that work is blatantly obvious even to casual passersby. The quality of the work is also easily measurable, and shoddy workmanship will become apparent at some point. Once the bridge is done, it's done. There is maintenance of course, but there is no such thing as "beta testers" for a bridge. Clueless upper management don't go out for a drive on the bridge when its half-done and then complain about poor cell phone reception on the lower decks and demand that the whole thing be retrofitted using fiberglass instead of steel. If the bridge collapses for some unfortunate reason one day (if it were built by the average software company it would collapse twice a week), inspectors and engineers would come in and investigate. The causes would be found quickly, and demonstrated with models and proven with math and measurements. If it was an engineering issue, the engineers get the blame. If it was lack of maintenance, the politicians get the blame. If it was cheap workmanship or faulty materials, the builders get the blame... and so on. A politician who cut the maintenance budget cannot come out and claim that a giant sea serpent was secretly humping the bridge at night. No PHB's can dodge the blame for forcing
If it was an engineering issue, the engineers get the blame. If it was lack of maintenance, the politicians get the blame. If it was cheap workmanship or faulty materials, the builders get the blame... and so on. I wonder - who'd get the blame for leaving a giant chute to the inner core of the death star, big enough for an enemy fighter to fly through and drop a bomb? :^)