9 ms·

No, unlike e.g. civil engineering you're never doing the same thing twice and you're always doing something you've never done before because if you have, you co

by Aaargh20318 10y ago

No, unlike e.g. civil engineering you're never doing the same thing twice and you're always doing something you've never done before because if you have, you could just use that code. You can't copy-paste a bridge but you can re-use software.

jacquesm 10y ago
You possibly don't now much about civil engineering, let me start out by writing that every project in civil engineering stands on it's own, it is the knowledge and the practices that get re-cycled from one project to the next and on a higher level from one generation of civil engineers to the next. So it is extremely unlikely that civil engineering will be done twice for an exactly identical project. But no civil engineer is going to make his own table for bolt tensile or sheer strength just to scratch an itch. Then we come to software, in software the same problems appear over and over again and we have in the 100's of possible solutions for some problems that are all almost (but not quite, of course due to sloppy design and lack of standardization) interchangeable. Think web frameworks. They are themselves an attempt to abstract away some elements that are common, but in the meantime there are almost as many webframeworks as there are things that they were trying to abstract away to begin with (and all of them fail on one or more of the details). Or programming languages, another area in which we have re-invented the wheel so many times that the number of programming languages (1000+) will at some point probably exceed the number of human languages (about 6500 in active use, but about 2000 of those have < 1000 speakers). http://www.infoplease.com/askeds/many-spoken-languages.html http://www.infoplease.com/askeds/many-spoken-languages.html http://www.99-bottles-of-beer.net/ http://www.99-bottles-of-beer.net/
- Aaargh20318 10y ago
  > You possibly don't now much about civil engineering I don't, so maybe it's not the best example. But take houses for example, it's not common to see a dozen or more identical houses being built. After you've done 11, number 12 is not going to be much different.
  - jacquesm 10y ago
    But the foundations might be slightly different to account for terrain differences. And that will not cause the civil engineers involved to re-define what a bulldozer or backhoe can or should do and how it should work, nor will it change the process they will use to make that foundation. In fact, the house sitting on top of the foundation will likely be the same project if they really are identical, just like copies of a piece of software, in other words, from an engineering perspective the job as far as the house is concerned was done with #1 if you want more than one house. It's all about the tools, processes, materials, soil knowledge and so on that are being employed in order to solve the problem, not about what is actually built. In the software equivalent there would be a new build process with associated terminology and tool obsoletion for almost every engineering project. Imagine workers coming to the job one morning to find that the tools they used the day before have now en-masse been declared obsolete and all their technology is slightly different, incompatible and un-tested. Then, a few weeks later at another job site it would be the same story all over. In the meantime, the engineers would be re-inventing engineering from first principles for every 5th job or so. In other professions that would be called madness.
    - numlocked 10y ago
      I think that's the wrong perspective. Software is a tool. What you do with it is an outcome. A bulldozer is a tool. The house is the outcome. So, we already invented a bulldozer (some piece of software) and it's trivial to duplicate it and reuse it all over the world. But when we need a new type of machine it's harder because, well, it's new. In the software engineering world the goals is generally not to facsimile something like e.g. a house. It's to create a legitimately new tool. And since there are no real capital investments required (unlike building new tools in the physical world), and folks often value their free time at a weirdly low marginal rate, you end up with tool proliferation in a way not seen in the physical world, which makes it easy to think that we're building houses when in fact we're inventing the bulldozer.
      - jacquesm 10y ago
        > It's to create a legitimately new tool. More likely: to create a minor variation on an existing tool. There have been relatively few instances of legitimate new tool creation but many 100's (and probably 1000's) of instances of re-creating slight variations on the same tools. For instance: build tools, programming languages, libraries (95% duplicate functionality with some other library, and of course an inconsistent interface) and so on. > And since there are no real capital investments required (unlike building new tools in the physical world) Software requires enormous amounts of capital, in part due to all this re-invention. We even have a name for it: NIH, and we have a term for what happens to a software project that is a few years old (technical debt). Our tools and our processes are ill equipped to deal with the challenge and what is supposed to be building houses more often than not ends up with people re-inventing the bulldozer. Now there are times when that is the right thing to do, but most of the times it isn't.
- gregmac 10y ago
  How is the number of web frameworks any different from the number of possible building facades? Even if you decide you want a glass facade, there are dozens of companies that can build that for you, and they've all re-invented essentially the same thing. The same can be said for nearly everything else. Insulation systems, HVAC, lighting, interlocking brick, drainage...
  - jacquesm 10y ago
    But, you would expect your house to stand upright, all the fixtures should work (and work in an expected way), the roof won't leak, your house should be solid and so on. And if it is not you'd expect the producer to put a warranty on their product. Choices made are made for aesthetic or engineering reasons or cost or some other constraint, rarely because the tech is 'fancy', 'new' or has been invented by the crew building your house. Bricks will be laid on plumb walls, the roof will be strong enough to support the expected load and so on and if any of it fails you will be surprised. Note that most of this is stuff that has already been engineered elsewhere that is is combined in some novel way, and for the most part all of the materials can be used together, are standardized as much as possible and your average build crew will be able to move on to the next job without having to re-learn their whole knowledge base because what they did last week is now so '2015' that they are essentially useless unless they get with the times. So yes, that's entirely different.
    - gregmac 10y ago
      Not all software developers consider something from 2015 'old' and immediately jump to the 'fancy new' stuff that came out this week. See the discussion on "Happiness is a Boring Stack"[0] from yesterday. There are crappy new building materials that don't work (which you often don't figure out until years later when you have to replace your roof or windows or siding or doors), and there are bad crews that do crappy jobs. This is really no different from software, though I'd argue it's easier for the crappy developers to continue working. This partly has to do with your website having ugly-but-working code has little impact to your typically business owner, while having bricks that are crooked and unevenly spaced -- even though they're perfectly functional -- is highly visible to everyone. The bricklayer that does a functional-but-ugly job gets a bad reputation immediately. The website developer that does the same thing isn't found out until much later when you have to modify the code. [0] https://news.ycombinator.com/item?id=12788804 https://news.ycombinator.com/item?id=12788804
ransom1538 10y ago
Having worked with PE civil engineers out of college I can confirm they don't do anything new. Civil engineering at this point is pouring concrete. Concrete is an understood material. They mainly deal with permitting, fixing a cad drawings and arguing with architects (who are also not doing anything new). Once and a great while they do something new like expand the bay bridge. Then you get to see civil engineers try to solve an actual problem. A decade(?) of work on a bridge that could have been completed quicker in 1929.
- jacquesm 10y ago
  Civil engineering just pouring concrete? The plan: https://www.youtube.com/watch?v=xmWmRQ1_uAE https://www.youtube.com/watch?v=xmWmRQ1_uAE Reality: https://www.youtube.com/watch?v=7L32wC2qNAY https://www.youtube.com/watch?v=7L32wC2qNAY
  - ransom1538 10y ago
    You posted a video of people moving something heavy with wheels. I guess in the civil engineering world: amazing!
    - jacquesm 10y ago
      I think you slightly missed the point there. The video is of a bridge designed to span a highway that was to be expanded from 2x4 to 2x5 lanes + an emergency lane on both sides with minimal interruption to existing road and rail traffic. The decision was made to construct the bridge off to the side of the road on a separate spot, then to create a special purpose roadway across the road to the location where the bridge would be placed. And finally, to move the bridge from the construction site to the final destination in one piece. The whole thing was conceived and executed according to plan, including a < 24 hour closure of the road and one week of interruption on the rail line (it was not possible for many reasons to have the track installed prior to moving the bridge). That is engineering. In the 'move fast and break stuff' world that would be 'move fast and kill people'. If this were software we'd be looking at a multi-year software project with a few hundred programmers delivered on-time, within the budget and working flawlessly on the day of delivery. I have yet to see such a project. But as you say, 'Amazing!', the fact that you make it seem like this is 'no big deal' is exactly what is so good about it, you fully expected it to work didn't you? The trick apparently is to make the complex and impressive stuff look so boring, I really wished that we could make software look that boring.
clifanatic 10y ago
> unlike e.g. civil engineering It isn't like people don't wonder why it takes so long or costs so much to, say, build a road, either. It seems like everybody massively underestimates how long it should take to do something that they don't know how to do and won't be doing. I characterize this mindset as "I need _x_ to be true, therefore _x_ must be true." It's endemic in all of the people who don't actually produce anything.
ArkyBeagle 10y ago
It's unusual to actually be able to reuse a lot of software. But this is another argument for "the only difference between product A and product B is the configuration." Then it's "What??? We're paying <x> dollars a seat for a configuration change????." You can't win...

jacquesm 10y ago

You possibly don't now much about civil engineering, let me start out by writing that every project in civil engineering stands on it's own, it is the knowledge and the practices that get re-cycled from one project to the next and on a higher level from one generation of civil engineers to the next. So it is extremely unlikely that civil engineering will be done twice for an exactly identical project. But no civil engineer is going to make his own table for bolt tensile or sheer strength just to scratch an itch. Then we come to software, in software the same problems appear over and over again and we have in the 100's of possible solutions for some problems that are all almost (but not quite, of course due to sloppy design and lack of standardization) interchangeable. Think web frameworks. They are themselves an attempt to abstract away some elements that are common, but in the meantime there are almost as many webframeworks as there are things that they were trying to abstract away to begin with (and all of them fail on one or more of the details). Or programming languages, another area in which we have re-invented the wheel so many times that the number of programming languages (1000+) will at some point probably exceed the number of human languages (about 6500 in active use, but about 2000 of those have < 1000 speakers). http://www.infoplease.com/askeds/many-spoken-languages.html http://www.infoplease.com/askeds/many-spoken-languages.html http://www.99-bottles-of-beer.net/ http://www.99-bottles-of-beer.net/

Aaargh20318 10y ago
> You possibly don't now much about civil engineering I don't, so maybe it's not the best example. But take houses for example, it's not common to see a dozen or more identical houses being built. After you've done 11, number 12 is not going to be much different.
- jacquesm 10y ago
  But the foundations might be slightly different to account for terrain differences. And that will not cause the civil engineers involved to re-define what a bulldozer or backhoe can or should do and how it should work, nor will it change the process they will use to make that foundation. In fact, the house sitting on top of the foundation will likely be the same project if they really are identical, just like copies of a piece of software, in other words, from an engineering perspective the job as far as the house is concerned was done with #1 if you want more than one house. It's all about the tools, processes, materials, soil knowledge and so on that are being employed in order to solve the problem, not about what is actually built. In the software equivalent there would be a new build process with associated terminology and tool obsoletion for almost every engineering project. Imagine workers coming to the job one morning to find that the tools they used the day before have now en-masse been declared obsolete and all their technology is slightly different, incompatible and un-tested. Then, a few weeks later at another job site it would be the same story all over. In the meantime, the engineers would be re-inventing engineering from first principles for every 5th job or so. In other professions that would be called madness.
  - numlocked 10y ago
    I think that's the wrong perspective. Software is a tool. What you do with it is an outcome. A bulldozer is a tool. The house is the outcome. So, we already invented a bulldozer (some piece of software) and it's trivial to duplicate it and reuse it all over the world. But when we need a new type of machine it's harder because, well, it's new. In the software engineering world the goals is generally not to facsimile something like e.g. a house. It's to create a legitimately new tool. And since there are no real capital investments required (unlike building new tools in the physical world), and folks often value their free time at a weirdly low marginal rate, you end up with tool proliferation in a way not seen in the physical world, which makes it easy to think that we're building houses when in fact we're inventing the bulldozer.
    - jacquesm 10y ago
      > It's to create a legitimately new tool. More likely: to create a minor variation on an existing tool. There have been relatively few instances of legitimate new tool creation but many 100's (and probably 1000's) of instances of re-creating slight variations on the same tools. For instance: build tools, programming languages, libraries (95% duplicate functionality with some other library, and of course an inconsistent interface) and so on. > And since there are no real capital investments required (unlike building new tools in the physical world) Software requires enormous amounts of capital, in part due to all this re-invention. We even have a name for it: NIH, and we have a term for what happens to a software project that is a few years old (technical debt). Our tools and our processes are ill equipped to deal with the challenge and what is supposed to be building houses more often than not ends up with people re-inventing the bulldozer. Now there are times when that is the right thing to do, but most of the times it isn't.
gregmac 10y ago
How is the number of web frameworks any different from the number of possible building facades? Even if you decide you want a glass facade, there are dozens of companies that can build that for you, and they've all re-invented essentially the same thing. The same can be said for nearly everything else. Insulation systems, HVAC, lighting, interlocking brick, drainage...
- jacquesm 10y ago
  But, you would expect your house to stand upright, all the fixtures should work (and work in an expected way), the roof won't leak, your house should be solid and so on. And if it is not you'd expect the producer to put a warranty on their product. Choices made are made for aesthetic or engineering reasons or cost or some other constraint, rarely because the tech is 'fancy', 'new' or has been invented by the crew building your house. Bricks will be laid on plumb walls, the roof will be strong enough to support the expected load and so on and if any of it fails you will be surprised. Note that most of this is stuff that has already been engineered elsewhere that is is combined in some novel way, and for the most part all of the materials can be used together, are standardized as much as possible and your average build crew will be able to move on to the next job without having to re-learn their whole knowledge base because what they did last week is now so '2015' that they are essentially useless unless they get with the times. So yes, that's entirely different.
  - gregmac 10y ago
    Not all software developers consider something from 2015 'old' and immediately jump to the 'fancy new' stuff that came out this week. See the discussion on "Happiness is a Boring Stack"[0] from yesterday. There are crappy new building materials that don't work (which you often don't figure out until years later when you have to replace your roof or windows or siding or doors), and there are bad crews that do crappy jobs. This is really no different from software, though I'd argue it's easier for the crappy developers to continue working. This partly has to do with your website having ugly-but-working code has little impact to your typically business owner, while having bricks that are crooked and unevenly spaced -- even though they're perfectly functional -- is highly visible to everyone. The bricklayer that does a functional-but-ugly job gets a bad reputation immediately. The website developer that does the same thing isn't found out until much later when you have to modify the code. [0] https://news.ycombinator.com/item?id=12788804 https://news.ycombinator.com/item?id=12788804

ransom1538 10y ago

Having worked with PE civil engineers out of college I can confirm they don't do anything new. Civil engineering at this point is pouring concrete. Concrete is an understood material. They mainly deal with permitting, fixing a cad drawings and arguing with architects (who are also not doing anything new). Once and a great while they do something new like expand the bay bridge. Then you get to see civil engineers try to solve an actual problem. A decade(?) of work on a bridge that could have been completed quicker in 1929.

jacquesm 10y ago
Civil engineering just pouring concrete? The plan: https://www.youtube.com/watch?v=xmWmRQ1_uAE https://www.youtube.com/watch?v=xmWmRQ1_uAE Reality: https://www.youtube.com/watch?v=7L32wC2qNAY https://www.youtube.com/watch?v=7L32wC2qNAY
- ransom1538 10y ago
  You posted a video of people moving something heavy with wheels. I guess in the civil engineering world: amazing!
  - jacquesm 10y ago
    I think you slightly missed the point there. The video is of a bridge designed to span a highway that was to be expanded from 2x4 to 2x5 lanes + an emergency lane on both sides with minimal interruption to existing road and rail traffic. The decision was made to construct the bridge off to the side of the road on a separate spot, then to create a special purpose roadway across the road to the location where the bridge would be placed. And finally, to move the bridge from the construction site to the final destination in one piece. The whole thing was conceived and executed according to plan, including a < 24 hour closure of the road and one week of interruption on the rail line (it was not possible for many reasons to have the track installed prior to moving the bridge). That is engineering. In the 'move fast and break stuff' world that would be 'move fast and kill people'. If this were software we'd be looking at a multi-year software project with a few hundred programmers delivered on-time, within the budget and working flawlessly on the day of delivery. I have yet to see such a project. But as you say, 'Amazing!', the fact that you make it seem like this is 'no big deal' is exactly what is so good about it, you fully expected it to work didn't you? The trick apparently is to make the complex and impressive stuff look so boring, I really wished that we could make software look that boring.

clifanatic 10y ago

> unlike e.g. civil engineering It isn't like people don't wonder why it takes so long or costs so much to, say, build a road, either. It seems like everybody massively underestimates how long it should take to do something that they don't know how to do and won't be doing. I characterize this mindset as "I need _x_ to be true, therefore _x_ must be true." It's endemic in all of the people who don't actually produce anything.

ArkyBeagle 10y ago

It's unusual to actually be able to reuse a lot of software. But this is another argument for "the only difference between product A and product B is the configuration." Then it's "What??? We're paying <x> dollars a seat for a configuration change????." You can't win...