7 ms·

> If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believ

by trimbo 13y ago

> If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you. If you told me that you knew to some insane degree of accuracy how long it would take to get to ‘finished’ – I would believe you again. That’s how Engineers roll Oh neat, maybe he can explain why the new Bay Bridge was practically a decade over schedule and billions over budget. Or the Burj Khalifa was about 2 years overdue? Or the California High Speed rail is projected to be twice the budget they thought, and they've barely broken ground on it? So the idea that "Real Engineers" building bridges and railroads and skyscrapers get it right in plans and schedule is total bullshit. We've seen larger software projects, with more people working on them than these examples, hit their deadlines (Windows comes to mind -- except Vista). And by the way, those "Engineering" disciplines have only been around for, what, hundreds, if not thousands of years. What they do for a living is mostly explored territory. Software, at least at a scale to be considered engineering at all, has been around for about 3-4 decades... maybe. And we're still hitting up against major unknowns all the time at every level of the practice, big and small. edit: grammar

maxmcd 13y ago
If large scale civil engineering projects were not muddled by politics, contracts, and bidding wars, I imagine that wouldn't be the case. So in an abstract since, and in a world where engineers are the only ones involved in construction, I understand his point.
- jeltz 13y ago
  > If large scale civil engineering projects were not muddled by politics, contracts, and bidding wars, I imagine that wouldn't be the case. And software development is never involved in any of that? While I suspect software is more often plagued by problems I do not see that it is another kind of problems than other forms of engineering.
- hackula1 13y ago
  Waterfall software design would also probably work if it was not for changing requirements, limited budgets, optimistic estimate push, etc.
- jacalata 13y ago
  Like the healthcare website?
greenyoda 13y ago
I agree with you that the author of this article doesn't know much about how engineering projects really get done, but I have to disagree with your claim that software engineering has only been around for "3-4 decades... maybe". In the 1960s, IBM was building its OS/360 operating system, the massive project that inspired Brooks' famous book The Mythical Man Month. The Multics operating system (which inspired Unix with ideas like a hierarchical file system and an OS written a high level language) was started in 1964. Lisp, Algol and Fortran were all implemented in the 1950s. So software engineering has been around for at least 6 decades.
- hackula1 13y ago
  You are correct, but I would point out that this does not detract from the argument considering the time scale. Software engineering could be 150 years old, and still not have the close to the history of traditional engineering.
  - greenyoda 13y ago
    Still, you'd think that after three generations of programming, we'd wouldn't have to constantly re-learn such basic lessons as: - Accumulation of technical debt is bad. - The latest trendy programming language won't make your hard problem all that much easier to solve. - A complex system can't be properly integrated and tested in two weeks (as recent news reports have shown). - The CEO setting an arbitrary deadline doesn't magically alter the laws of physics.
    - hackula1 13y ago
      > Accumulation of technical debt is bad. Is it always? In dollar amounts, I really do not know that it always is. "Don't let the perfect be the enemy of the good" and all. As a developer, I am always going to be the one push for better tests, more efficient systems, etc. but pg's post a month or two ago about scaling without automation (very rough paraphrasing) points to the fact that this does not always hold. > The latest trendy programming language won't make your hard problem all that much easier to solve. Maybe not the latest, but I would think that it was way easier to develop a desktop app in C++ than Fortran, develop a website in PHP than C++, develop a web app in Ruby than PHP, etc. Tech definitely improves over time. Jumping on every third bandwagon seems to be worthwhile. > A complex system can't be properly integrated and tested in two weeks (as recent news reports have shown). > The CEO setting an arbitrary deadline doesn't magically alter the laws of physics. These are not engineering problems, but political/administration problems that have been around forever and in every endeavor. I am certain that stone masons building cathedrals dealt with the same sorts of incompetent management, despite a dedication to craftsmanship and engineering.
timr 13y ago
"And we're still hitting up against major unknowns all the time at every level of the practice, big and small." I was with you until you got to this line. Let's be brutally honest: the limiting factor for most of today's software projects (i.e. CRUD websites and iPhone apps) is not technology. It's developer competency, experience and self-discipline. I'd go so far to say that most working software developers don't even understand the fundamentals of the technologies they're using -- it's why you see people replacing their relational databases for key-value stores, then trying to re-invent database join algorithms from scratch in the application layer. Or why every new generation of "engineers" re-discovers asynchronous programming in a new language (then promptly writes a framework in Blub...because Blub is so much better than last year's Blub.) Truthfully, it's pretty damned hard to find gigs working on the frontier of technology. Most projects are predictable, tedious slogs to fit together well-understood technologies without shooting yourself in the foot. And yes, requirements shift and clients get fussy, but that's true of any engineering discipline. You learn to pad the schedule to compensate for the shifts. It's part of being a professional. As far as I can see, commercial software isn't limited by "major unknowns", so much as an industry-wide unwillingness to learn from experience. But hey...that tends to happen in industries when you're considered "old" at 30....
- hackula1 13y ago
  Granted, most engineers are not exactly employing quantum physics to parking lot design. Most people, in general, work on gluing together pre-built parts that they do not understand all of the fundamentals of.
- Widdershin 13y ago
  Ah man, this hit slightly hard as someone who just moved from Postgres to MongoDB to avoid database migrations only to realize that I've now lost the power of a many to many relationship.
  - deleted 13y ago
    [deleted]
  - voltagex_ 13y ago
jacques_chester 13y ago
"Real" engineering has the commonality with software engineering that many projects are quite similar to previous projects and are thus fairly predictable. (This is true also of safety factors; I read a good book on it not too long ago[0]). A bog ordinary 12 story building will probably come in close to schedule and budget because it's a well-understood problem domain and there is a large pool of existing examples to draw data from. But the Burj Khalifa required solving some genuinely novel problems, of the sort which only turn up at that scale. When a project involves substantial R&D, schedules become much less certain. If my business is churning out Wordpress brochureware, I can give a pretty good estimate of how long a given job will take and how much it costs. If on the other hand my customers require me to develop novel, publishable algorithms, then any estimate I give will need to have very wide bands. [0] http://chester.id.au/2013/07/07/review-to-engineer-is-human-the-role-of-failure-in-successful-design/ http://chester.id.au/2013/07/07/review-to-engineer-is-human-...
ceol 13y ago
The author didn't say that every engineering project was perfect — only that he would believe an engineer if they gave him a very specific estimate.
cmaitchison 13y ago
I agree with you. My post was only really trying to promote Agile over Waterfall. Never intended for it to be taken so literally. I hope people enjoy reading it regardless.
- trimbo 13y ago
  It certainly makes for good HN discussion fodder :) FWIW, I've had the "Real Engineering" discussion before -- way more in depth than you illustrated here. My grandparent response above is probably a bit of pent-upness towards those discussions more than anything about your article in particular.
coldtea 13y ago
>So the idea that "Real Engineers" building bridges and railroads and skyscrapers get it right in plans and schedule is total bullshit. A few examples do not an argument make. You don't think in the "law of long numbers" sense. If you did, you'd find out that MOST engineering projects do end on time and budget, and even if they miss, they miss far more gracefully and with extremely better predictability of outcome that MOST software projects. That you can find some counter-arguments doesn't mean much -- what TFA proposes holds in general, and holds much better than the alternative propositions (that engineering is as fucked or more fucked than software). Of course there will be several counter-examples, it doesn't have to be perfect to be near-perfect compared to software schedulling. >And by the way, those "Engineering" disciplines have only been around for, what, hundreds, if not thousands of years. What they do for a living is mostly explored territory. That just reinforces the original posts thesis.
declan 13y ago
"Or the California High Speed rail is projected to be twice the budget they thought, and they've barely broken ground on it?" A correction: They've broken no ground on it. An AP article today reports that the "California High-Speed Rail Authority is in escrow on just one parcel of the 370 it needs" for the first 30 miles. http://abclocal.go.com/kabc/story?section=news/state&id=9320450 http://abclocal.go.com/kabc/story?section=news/state&id=9320... And the entire effort is in trouble: "Sacramento County Superior Court Judge Michael Kenney ruled that California's high-speed rail authority had violated the letter of the 2008 ballot initiative authorizing $10 billion in bonds for the 500-mile train's construction." http://online.wsj.com/news/articles/SB10001424127887324108204579023003948817332 http://online.wsj.com/news/articles/SB1000142412788732410820... I actually agree with the parent comment re: engineering but wanted to make sure that folks didn't think ground had been broken already on California's high speed rail plan. I wasn't sure and had to check myself.
- trimbo 13y ago
  Ah, thanks. I thought they had started building something out near Bakersfield, Modesto, or wherever the heck that thing is going on.
mtdewcmu 13y ago
I'm pretty sure that the kind of engineering that designs circuits to do things in hardware that you'd normally do in software can't be that much different than writing software. A title that I find more ridiculous than software engineer is software architect. Architects are partly like engineers, but they also design things to look pretty while serving their function. Making software look pretty on the inside is utterly pointless, because users only see what the software does, not what the design looks like. Designing software is a lot more like engineering than architecture.
mcv 13y ago
The skyscrapers and bridges that are finished on time and on budget are the ones that have been built before. For physical structures, it makes sense to do the same work again, because then you have two bridges or two skyscrapers instead of only one. People can live in two different locations, and they can cross yet another river, which is useful. For software, if you need another copy, that's a trivial task. It's more on schedule and budget than any skyscraper or bridge could ever hope to be. Once built, we can use it everywhere. The only thing that requires any real effort, is building that very first skyscraper.
jmerton 13y ago
I come from a civil engineering background. The problems you cite are not engineering problems - they're management problems. In the environments I've worked in, heads would have rolled for the over-runs/over-dues you mention. We call these NFE situations. BTW - thank you for mentioning (indirectly) that civil engineering is the world's oldest profession. ;-)

by trimbo 13y ago

maxmcd 13y ago

If large scale civil engineering projects were not muddled by politics, contracts, and bidding wars, I imagine that wouldn't be the case. So in an abstract since, and in a world where engineers are the only ones involved in construction, I understand his point.

jeltz 13y ago
> If large scale civil engineering projects were not muddled by politics, contracts, and bidding wars, I imagine that wouldn't be the case. And software development is never involved in any of that? While I suspect software is more often plagued by problems I do not see that it is another kind of problems than other forms of engineering.
hackula1 13y ago
Waterfall software design would also probably work if it was not for changing requirements, limited budgets, optimistic estimate push, etc.
jacalata 13y ago
Like the healthcare website?

greenyoda 13y ago

I agree with you that the author of this article doesn't know much about how engineering projects really get done, but I have to disagree with your claim that software engineering has only been around for "3-4 decades... maybe". In the 1960s, IBM was building its OS/360 operating system, the massive project that inspired Brooks' famous book The Mythical Man Month. The Multics operating system (which inspired Unix with ideas like a hierarchical file system and an OS written a high level language) was started in 1964. Lisp, Algol and Fortran were all implemented in the 1950s. So software engineering has been around for at least 6 decades.

hackula1 13y ago
You are correct, but I would point out that this does not detract from the argument considering the time scale. Software engineering could be 150 years old, and still not have the close to the history of traditional engineering.
- greenyoda 13y ago
  Still, you'd think that after three generations of programming, we'd wouldn't have to constantly re-learn such basic lessons as: - Accumulation of technical debt is bad. - The latest trendy programming language won't make your hard problem all that much easier to solve. - A complex system can't be properly integrated and tested in two weeks (as recent news reports have shown). - The CEO setting an arbitrary deadline doesn't magically alter the laws of physics.
  - hackula1 13y ago
    > Accumulation of technical debt is bad. Is it always? In dollar amounts, I really do not know that it always is. "Don't let the perfect be the enemy of the good" and all. As a developer, I am always going to be the one push for better tests, more efficient systems, etc. but pg's post a month or two ago about scaling without automation (very rough paraphrasing) points to the fact that this does not always hold. > The latest trendy programming language won't make your hard problem all that much easier to solve. Maybe not the latest, but I would think that it was way easier to develop a desktop app in C++ than Fortran, develop a website in PHP than C++, develop a web app in Ruby than PHP, etc. Tech definitely improves over time. Jumping on every third bandwagon seems to be worthwhile. > A complex system can't be properly integrated and tested in two weeks (as recent news reports have shown). > The CEO setting an arbitrary deadline doesn't magically alter the laws of physics. These are not engineering problems, but political/administration problems that have been around forever and in every endeavor. I am certain that stone masons building cathedrals dealt with the same sorts of incompetent management, despite a dedication to craftsmanship and engineering.

timr 13y ago

"And we're still hitting up against major unknowns all the time at every level of the practice, big and small." I was with you until you got to this line. Let's be brutally honest: the limiting factor for most of today's software projects (i.e. CRUD websites and iPhone apps) is not technology. It's developer competency, experience and self-discipline. I'd go so far to say that most working software developers don't even understand the fundamentals of the technologies they're using -- it's why you see people replacing their relational databases for key-value stores, then trying to re-invent database join algorithms from scratch in the application layer. Or why every new generation of "engineers" re-discovers asynchronous programming in a new language (then promptly writes a framework in Blub...because Blub is so much better than last year's Blub.) Truthfully, it's pretty damned hard to find gigs working on the frontier of technology. Most projects are predictable, tedious slogs to fit together well-understood technologies without shooting yourself in the foot. And yes, requirements shift and clients get fussy, but that's true of any engineering discipline. You learn to pad the schedule to compensate for the shifts. It's part of being a professional. As far as I can see, commercial software isn't limited by "major unknowns", so much as an industry-wide unwillingness to learn from experience. But hey...that tends to happen in industries when you're considered "old" at 30....

hackula1 13y ago
Granted, most engineers are not exactly employing quantum physics to parking lot design. Most people, in general, work on gluing together pre-built parts that they do not understand all of the fundamentals of.
Widdershin 13y ago
Ah man, this hit slightly hard as someone who just moved from Postgres to MongoDB to avoid database migrations only to realize that I've now lost the power of a many to many relationship.
- deleted 13y ago
  [deleted]
- voltagex_ 13y ago

jacques_chester 13y ago

"Real" engineering has the commonality with software engineering that many projects are quite similar to previous projects and are thus fairly predictable. (This is true also of safety factors; I read a good book on it not too long ago[0]). A bog ordinary 12 story building will probably come in close to schedule and budget because it's a well-understood problem domain and there is a large pool of existing examples to draw data from. But the Burj Khalifa required solving some genuinely novel problems, of the sort which only turn up at that scale. When a project involves substantial R&D, schedules become much less certain. If my business is churning out Wordpress brochureware, I can give a pretty good estimate of how long a given job will take and how much it costs. If on the other hand my customers require me to develop novel, publishable algorithms, then any estimate I give will need to have very wide bands. [0] http://chester.id.au/2013/07/07/review-to-engineer-is-human-the-role-of-failure-in-successful-design/ http://chester.id.au/2013/07/07/review-to-engineer-is-human-...

ceol 13y ago

The author didn't say that every engineering project was perfect — only that he would believe an engineer if they gave him a very specific estimate.

cmaitchison 13y ago

I agree with you. My post was only really trying to promote Agile over Waterfall. Never intended for it to be taken so literally. I hope people enjoy reading it regardless.

trimbo 13y ago
It certainly makes for good HN discussion fodder :) FWIW, I've had the "Real Engineering" discussion before -- way more in depth than you illustrated here. My grandparent response above is probably a bit of pent-upness towards those discussions more than anything about your article in particular.

coldtea 13y ago

>So the idea that "Real Engineers" building bridges and railroads and skyscrapers get it right in plans and schedule is total bullshit. A few examples do not an argument make. You don't think in the "law of long numbers" sense. If you did, you'd find out that MOST engineering projects do end on time and budget, and even if they miss, they miss far more gracefully and with extremely better predictability of outcome that MOST software projects. That you can find some counter-arguments doesn't mean much -- what TFA proposes holds in general, and holds much better than the alternative propositions (that engineering is as fucked or more fucked than software). Of course there will be several counter-examples, it doesn't have to be perfect to be near-perfect compared to software schedulling. >And by the way, those "Engineering" disciplines have only been around for, what, hundreds, if not thousands of years. What they do for a living is mostly explored territory. That just reinforces the original posts thesis.

declan 13y ago

"Or the California High Speed rail is projected to be twice the budget they thought, and they've barely broken ground on it?" A correction: They've broken no ground on it. An AP article today reports that the "California High-Speed Rail Authority is in escrow on just one parcel of the 370 it needs" for the first 30 miles. http://abclocal.go.com/kabc/story?section=news/state&id=9320450 http://abclocal.go.com/kabc/story?section=news/state&id=9320... And the entire effort is in trouble: "Sacramento County Superior Court Judge Michael Kenney ruled that California's high-speed rail authority had violated the letter of the 2008 ballot initiative authorizing $10 billion in bonds for the 500-mile train's construction." http://online.wsj.com/news/articles/SB10001424127887324108204579023003948817332 http://online.wsj.com/news/articles/SB1000142412788732410820... I actually agree with the parent comment re: engineering but wanted to make sure that folks didn't think ground had been broken already on California's high speed rail plan. I wasn't sure and had to check myself.

trimbo 13y ago
Ah, thanks. I thought they had started building something out near Bakersfield, Modesto, or wherever the heck that thing is going on.

mtdewcmu 13y ago

I'm pretty sure that the kind of engineering that designs circuits to do things in hardware that you'd normally do in software can't be that much different than writing software. A title that I find more ridiculous than software engineer is software architect. Architects are partly like engineers, but they also design things to look pretty while serving their function. Making software look pretty on the inside is utterly pointless, because users only see what the software does, not what the design looks like. Designing software is a lot more like engineering than architecture.

mcv 13y ago

The skyscrapers and bridges that are finished on time and on budget are the ones that have been built before. For physical structures, it makes sense to do the same work again, because then you have two bridges or two skyscrapers instead of only one. People can live in two different locations, and they can cross yet another river, which is useful. For software, if you need another copy, that's a trivial task. It's more on schedule and budget than any skyscraper or bridge could ever hope to be. Once built, we can use it everywhere. The only thing that requires any real effort, is building that very first skyscraper.

jmerton 13y ago

I come from a civil engineering background. The problems you cite are not engineering problems - they're management problems. In the environments I've worked in, heads would have rolled for the over-runs/over-dues you mention. We call these NFE situations. BTW - thank you for mentioning (indirectly) that civil engineering is the world's oldest profession. ;-)