6 ms·

People STILL confuse the construction of software with the construction of buildings. We can estimate fairly accurately how long it will take to build a buildin

by jbb555 10y ago

People STILL confuse the construction of software with the construction of buildings. We can estimate fairly accurately how long it will take to build a building once we have reasonable plans for it. I can pretty accurately say that it will take about 4 minutes to build the software once I have the plans to build it. The compiler pretty much automates the whole job. Writing software is NOT construction. Much of it isn't even design. Most of it is gathering detailed requirements and writing them down in unambiguous form (code). My asking how long it's going to take to write a software it's like saying to a building contractor how long will it take to design every single detail of a city block including gathering all the requirements. Also the requirements for software are much more detailed than building. 100000 lines of code represents 100000 decisions. I bet not many buildings have 100000 decisions. And 10000 is tiny for a software project.

yannickt 10y ago
There is a great essay by Jack Reeves making a similar point. What Is Software Design? http://www.developerdotstar.com/mag/articles/reeves_design.html http://www.developerdotstar.com/mag/articles/reeves_design.h... FTA: There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers.
- someguydave 10y ago
  But then you could argue that the machine code emitted from the compiler is a design and the actual hardware that implements it is "building the software".
  - someguydave 10y ago
    But then you could argue that the implementing transistor arrangement is a design and the actual movement of electrons that implements it is "building the software"
  - TeMPOraL 10y ago
    What compiler does is equivalent to what a contractor does - building. The machine code emitted from the compiler is the building.
  - igravious 10y ago
    Nobody said that it was an exact analogy. :) All it needs to be is more exact than the previous (good, but not all that good) analogy.
bitwize 10y ago
Well, we still need you to provide a detailed task breakdown and hourly estimate for each task so if you can do that before starting work on your story backlog, that would be terrific.
rossdavidh 10y ago
I would bet that those involved in making buildings would differ. However, sometimes you get to make more or less the exact same building again, which you shouldn't ever be doing in software. This is how suburbs happen; it's way cheaper to rebuild the same house again and again. In software, especially in an era of open source, you should not be doing that. So every house you're making, is the first house you've made of that type.
- cestith 10y ago
  In software it's basically free if you want exactly the same building. Bits are cheap. Even physical media to store the bits is cheap. Sure, the bricks, mortar, framing lumber, concrete, drywall, conduit and such for a building cost a fair amount of money. Then there's the labor to actually put it together. But one of the big costs is the architecture and (literal) groundwork. The fixed costs of a building are fairly steep, but miniscule compared to redesigning it over and over. In software we generally get away with much cheaper fixed costs of deployment but redesign is still redesign. We're typically happy to spend some time redesigning and paying that cost because we're not actually demolishing and rebuilding parts of the project with high deployment costs like renovating an existing building. Throwing away the old copy and deploying a new one is essentially free. So we shift the budget to more redesign. There should be a limit on how often, though, if we ever want to move on to different problems.
ChemicalWarfare 10y ago
Maybe not the best analogy but there's also things like letting 10x the projected number of occupants enter the building to make sure it can still handle the load and then if it can't this can lead to some rather drastic changes requiring rework. Also things like having a contingency plan if say city sewer gets backed up - how will your tenants take care of "business" then :)
snowwrestler 10y ago
The reason designing a building is faster is that there are fewer decisions. The reason there are fewer decisions is because buildings are way better understood than software. A lot of designing the structure of a building is just the implementation of a few core concepts that have been perfected for thousands of years, like doors and windows and beams and arches. There is sufficient human knowledge about buildings that people expect every single building to stand up, work properly, and be safe the very first time it is built. There aren't many self-taught building engineers who just picked it up in their spare time during high school. And a lot of the design is simply choosing fixed options. Architecture and construction firms don't design and engineer the ceiling light fixtures or the faucets. They select a supplier + model, and install them with standard hardware in standard ways. In many cases there is even government code that tells them exactly how it must be done. Compare to software. Every single decision is up for grabs on every new project. Programmers have no standard certifications, and in fact are often actively hostile to standardization and formal training. The state of the art in making sure things work is just brute-force, constant testing. Of course projects can run into problems. Software, as an engineering discipline, still has a long way to go toward being a mature, well-understood human endeavor. Which makes sense, since we've been doing it about 1/100th as long as we've been making buildings.
- yannickt 10y ago
  The reason there are fewer decisions is because buildings are way better understood than software. I think buildings are better understood in large part because they are not nearly as malleable. Because software is highly malleable by nature, the complexity and scope of decisions can grow much faster than in any other engineering discipline.
  - weaksauce 10y ago
    I am not sure malleability is really the core issue... the core issue is that there are many different approaches to making a feature with different trade offs and costs that are not readily apparent at the outset. Not to mention that poor design upfront causes a plethora of issues down the line if you need to scale it.
scandox 10y ago
My brother builds large buildings and after a lot of discussion about our professions the key difference we agreed on was the level of constraint. Software is (appears?) unconstrained. The enormous cost of experiment or change is very much apparent to stakeholders in his projects. In mine there is always a sense that because it is intangible it doesn't have the same cost. However this appears to be a misconception.
farm_code 10y ago
In construction the hardware part is pretty much standardized. Very little new hardware is coming up. But in software development, hardware is still evolving very fast (processor, memory, bus, fibre etc..). So software has to evolve along with hardware. Once hardware is standardized like CPU instruction set, then software will also be standardized with out any further significant development.
- douche 10y ago
  Meanwhile, lately it seems like all too often, you'll be pounding nails with a hammer and then in between swings, it suddenly turns into paint brush or a screwdriver or an Allen wrench. Or you're working along one day, and all of a sudden, every machine screw in every piece of power equipment on the job site just up and disappears into thin air, and all of that equipment shakes itself apart into a maelstrom of shrapnel, because that little hidden component nobody thought about winked out of existence. Construction workers would not put up with this bullshit.
arielb1 10y ago
Yeah. Software projects that are as complex as a house are typically called "the script that guy wrote a decade ago", and tend to work fairly well, even considering that use-cases for software have changed rapidly in the last few decades.
gerbilly 10y ago
>Most of it is gathering detailed requirements ... Gathering is the common term used to refer to it, but it makes it sound too easy. I'd say it's harder than gathering requirements, i's eliciting requirements.
- jl6 10y ago
  It's requirements negotiation round here.
deleted 10y ago
[deleted]
wahsd 10y ago
That's a good description. I would just expand it even a bit and compare software development to building a whole city or town form nothing without knowing anything about the conditions and circumstances going in. Sure, you can maybe reuse certain libraries, but before you can do all that you even just have to get an idea of the purpose of the project and then make 1 million other choices that will impact all other later decisions in a profound way. Washington DC is a good example in many ways in how it was designed in its rough layout with the interconnecting streets that are symbolic connections between the branches of government and choices like keeping a line of sight to the Washington Memorial from the White house so the President may always be reminded of Washington's ultimate gift to America. Preceding those kinds of decisions came 1 million prior choices and decisions and was then followed with 10 million more before the city even just had a slightly built out grid and layout with relatively functioning systems.
jordwest 10y ago
It's reasonable to imagine that installing 1000 windows in a building could take weeks or months. If you're writing software and follow DRY, it might take a few hours to work out how to perform some repeatable task, but then only a brief moment to actually do it 1000 times. The act of making software is all about decisions, there are almost by definition very few repeatable tasks. If you do find yourself repeating things over again, you're not taking full advantage of DRY or automation. This is why I think a lot of software is so unpredictable in terms of time. How do you predict that which you don't already know how to do?
firebones 10y ago
Underestimated in this comparison is the fact that software development, even on very large projects, tends to be staffed by generalists, while building construction relies on many highly-specialized masters of a trade. Software has some of that specialization (for instance, even big projects don't try to write new operating systems, invent interoperability protocols, or graphics libraries). But when it comes to the boundaries of what's considered part of the project, we rely on generalists. In building construction, a general contractor may have an HVAC subcontractor, one for electricity, one for glass, one for landscaping, one for every subsystem. In software, it's not economically feasible to contract in someone specializing in, say, web routes, and another in Rails model development, and another in for-loops, etc. The other, related point: very often software development time isn't just a function of the requirements, it's a function of the intersection of the technical requirements/platform and the talent pool available for that platform/language/tech.
DougWebb 10y ago
Several years ago I wrote a blog post expressing a related point, contrasting software design to construction. Here's a part: Let me give an example: if you're designing a bridge, you can draw blueprints on paper which shows girders. The girders are described by giving their dimensions (accurate to 1/16th of an inch, say) and the particular alloy the girder is made from. This is sufficient to accurately model how that girder will behave under all kinds of different stress loads which is important for ensuring the bridge will be safe, and also to model how the girders will fit together like a puzzle which is important for allowing the steelworkers to build the bridge correctly, on-time, and on-budget. The key to all of this is the fact that you don't need to create a real girder in order to test the design and make sure it's correct. A few easily described properties of the girder are sufficient; it doesn't matter where every atom goes, it doesn't matter if the surface isn't perfectly uniform, it doesn't matter if there is some rust, etc. Lots of the details just don't matter at design time, and most of them don't matter at construction time either. Software just doesn't work this way. Software development languages are extremely detail-sensitive: get one letter wrong, one punctuation character in the wrong place or left out, and the software won't work right. There is no way to accurately model something this sensitive to detail without building it first, and if you have to build it first you lose the biggest benefit of doing design up-front: the ability to test and iterate on your design cheaply before committing to a full build of it.
OtterCoder 10y ago
Another point in support of this is that buildings tend to get away with more minor bugs than software does. Walls usually have a subtle bow to them, toilets don't have to fail gracefully if the sewage network gets backed up, doors get installed the wrong direction, there are gaps behind the cabinets, light switches get wired around odd corners, etc. So long as the building can stand up in an earthquake and looks good enough to sell, that's usually the end of it. Software, on the other hand, has an air of imperative perfection. If it is even slightly wrong or ugly, it must be entirely wrong. I feel that way myself, and I must sometimes throttle my impulse to fix it indefinitely so that I can meet a business need in time.

by jbb555 10y ago

yannickt 10y ago

There is a great essay by Jack Reeves making a similar point. What Is Software Design? http://www.developerdotstar.com/mag/articles/reeves_design.html http://www.developerdotstar.com/mag/articles/reeves_design.h... FTA: There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers.

someguydave 10y ago
But then you could argue that the machine code emitted from the compiler is a design and the actual hardware that implements it is "building the software".
- someguydave 10y ago
  But then you could argue that the implementing transistor arrangement is a design and the actual movement of electrons that implements it is "building the software"
- TeMPOraL 10y ago
  What compiler does is equivalent to what a contractor does - building. The machine code emitted from the compiler is the building.
- igravious 10y ago
  Nobody said that it was an exact analogy. :) All it needs to be is more exact than the previous (good, but not all that good) analogy.

bitwize 10y ago

Well, we still need you to provide a detailed task breakdown and hourly estimate for each task so if you can do that before starting work on your story backlog, that would be terrific.

rossdavidh 10y ago

I would bet that those involved in making buildings would differ. However, sometimes you get to make more or less the exact same building again, which you shouldn't ever be doing in software. This is how suburbs happen; it's way cheaper to rebuild the same house again and again. In software, especially in an era of open source, you should not be doing that. So every house you're making, is the first house you've made of that type.

cestith 10y ago
In software it's basically free if you want exactly the same building. Bits are cheap. Even physical media to store the bits is cheap. Sure, the bricks, mortar, framing lumber, concrete, drywall, conduit and such for a building cost a fair amount of money. Then there's the labor to actually put it together. But one of the big costs is the architecture and (literal) groundwork. The fixed costs of a building are fairly steep, but miniscule compared to redesigning it over and over. In software we generally get away with much cheaper fixed costs of deployment but redesign is still redesign. We're typically happy to spend some time redesigning and paying that cost because we're not actually demolishing and rebuilding parts of the project with high deployment costs like renovating an existing building. Throwing away the old copy and deploying a new one is essentially free. So we shift the budget to more redesign. There should be a limit on how often, though, if we ever want to move on to different problems.

ChemicalWarfare 10y ago

Maybe not the best analogy but there's also things like letting 10x the projected number of occupants enter the building to make sure it can still handle the load and then if it can't this can lead to some rather drastic changes requiring rework. Also things like having a contingency plan if say city sewer gets backed up - how will your tenants take care of "business" then :)

snowwrestler 10y ago

The reason designing a building is faster is that there are fewer decisions. The reason there are fewer decisions is because buildings are way better understood than software. A lot of designing the structure of a building is just the implementation of a few core concepts that have been perfected for thousands of years, like doors and windows and beams and arches. There is sufficient human knowledge about buildings that people expect every single building to stand up, work properly, and be safe the very first time it is built. There aren't many self-taught building engineers who just picked it up in their spare time during high school. And a lot of the design is simply choosing fixed options. Architecture and construction firms don't design and engineer the ceiling light fixtures or the faucets. They select a supplier + model, and install them with standard hardware in standard ways. In many cases there is even government code that tells them exactly how it must be done. Compare to software. Every single decision is up for grabs on every new project. Programmers have no standard certifications, and in fact are often actively hostile to standardization and formal training. The state of the art in making sure things work is just brute-force, constant testing. Of course projects can run into problems. Software, as an engineering discipline, still has a long way to go toward being a mature, well-understood human endeavor. Which makes sense, since we've been doing it about 1/100th as long as we've been making buildings.

yannickt 10y ago
The reason there are fewer decisions is because buildings are way better understood than software. I think buildings are better understood in large part because they are not nearly as malleable. Because software is highly malleable by nature, the complexity and scope of decisions can grow much faster than in any other engineering discipline.
- weaksauce 10y ago
  I am not sure malleability is really the core issue... the core issue is that there are many different approaches to making a feature with different trade offs and costs that are not readily apparent at the outset. Not to mention that poor design upfront causes a plethora of issues down the line if you need to scale it.

scandox 10y ago

My brother builds large buildings and after a lot of discussion about our professions the key difference we agreed on was the level of constraint. Software is (appears?) unconstrained. The enormous cost of experiment or change is very much apparent to stakeholders in his projects. In mine there is always a sense that because it is intangible it doesn't have the same cost. However this appears to be a misconception.

farm_code 10y ago

In construction the hardware part is pretty much standardized. Very little new hardware is coming up. But in software development, hardware is still evolving very fast (processor, memory, bus, fibre etc..). So software has to evolve along with hardware. Once hardware is standardized like CPU instruction set, then software will also be standardized with out any further significant development.

douche 10y ago
Meanwhile, lately it seems like all too often, you'll be pounding nails with a hammer and then in between swings, it suddenly turns into paint brush or a screwdriver or an Allen wrench. Or you're working along one day, and all of a sudden, every machine screw in every piece of power equipment on the job site just up and disappears into thin air, and all of that equipment shakes itself apart into a maelstrom of shrapnel, because that little hidden component nobody thought about winked out of existence. Construction workers would not put up with this bullshit.

arielb1 10y ago

Yeah. Software projects that are as complex as a house are typically called "the script that guy wrote a decade ago", and tend to work fairly well, even considering that use-cases for software have changed rapidly in the last few decades.

gerbilly 10y ago

>Most of it is gathering detailed requirements ... Gathering is the common term used to refer to it, but it makes it sound too easy. I'd say it's harder than gathering requirements, i's eliciting requirements.

jl6 10y ago
It's requirements negotiation round here.

deleted 10y ago

[deleted]

wahsd 10y ago

That's a good description. I would just expand it even a bit and compare software development to building a whole city or town form nothing without knowing anything about the conditions and circumstances going in. Sure, you can maybe reuse certain libraries, but before you can do all that you even just have to get an idea of the purpose of the project and then make 1 million other choices that will impact all other later decisions in a profound way. Washington DC is a good example in many ways in how it was designed in its rough layout with the interconnecting streets that are symbolic connections between the branches of government and choices like keeping a line of sight to the Washington Memorial from the White house so the President may always be reminded of Washington's ultimate gift to America. Preceding those kinds of decisions came 1 million prior choices and decisions and was then followed with 10 million more before the city even just had a slightly built out grid and layout with relatively functioning systems.

jordwest 10y ago

It's reasonable to imagine that installing 1000 windows in a building could take weeks or months. If you're writing software and follow DRY, it might take a few hours to work out how to perform some repeatable task, but then only a brief moment to actually do it 1000 times. The act of making software is all about decisions, there are almost by definition very few repeatable tasks. If you do find yourself repeating things over again, you're not taking full advantage of DRY or automation. This is why I think a lot of software is so unpredictable in terms of time. How do you predict that which you don't already know how to do?

firebones 10y ago

Underestimated in this comparison is the fact that software development, even on very large projects, tends to be staffed by generalists, while building construction relies on many highly-specialized masters of a trade. Software has some of that specialization (for instance, even big projects don't try to write new operating systems, invent interoperability protocols, or graphics libraries). But when it comes to the boundaries of what's considered part of the project, we rely on generalists. In building construction, a general contractor may have an HVAC subcontractor, one for electricity, one for glass, one for landscaping, one for every subsystem. In software, it's not economically feasible to contract in someone specializing in, say, web routes, and another in Rails model development, and another in for-loops, etc. The other, related point: very often software development time isn't just a function of the requirements, it's a function of the intersection of the technical requirements/platform and the talent pool available for that platform/language/tech.

DougWebb 10y ago

Several years ago I wrote a blog post expressing a related point, contrasting software design to construction. Here's a part: Let me give an example: if you're designing a bridge, you can draw blueprints on paper which shows girders. The girders are described by giving their dimensions (accurate to 1/16th of an inch, say) and the particular alloy the girder is made from. This is sufficient to accurately model how that girder will behave under all kinds of different stress loads which is important for ensuring the bridge will be safe, and also to model how the girders will fit together like a puzzle which is important for allowing the steelworkers to build the bridge correctly, on-time, and on-budget. The key to all of this is the fact that you don't need to create a real girder in order to test the design and make sure it's correct. A few easily described properties of the girder are sufficient; it doesn't matter where every atom goes, it doesn't matter if the surface isn't perfectly uniform, it doesn't matter if there is some rust, etc. Lots of the details just don't matter at design time, and most of them don't matter at construction time either. Software just doesn't work this way. Software development languages are extremely detail-sensitive: get one letter wrong, one punctuation character in the wrong place or left out, and the software won't work right. There is no way to accurately model something this sensitive to detail without building it first, and if you have to build it first you lose the biggest benefit of doing design up-front: the ability to test and iterate on your design cheaply before committing to a full build of it.

OtterCoder 10y ago

Another point in support of this is that buildings tend to get away with more minor bugs than software does. Walls usually have a subtle bow to them, toilets don't have to fail gracefully if the sewage network gets backed up, doors get installed the wrong direction, there are gaps behind the cabinets, light switches get wired around odd corners, etc. So long as the building can stand up in an earthquake and looks good enough to sell, that's usually the end of it. Software, on the other hand, has an air of imperative perfection. If it is even slightly wrong or ugly, it must be entirely wrong. I feel that way myself, and I must sometimes throttle my impulse to fix it indefinitely so that I can meet a business need in time.