[jbb555]

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.

[snowwrestler]

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.

[cesarbs]

> Programmers have no standard certifications, and in fact are often actively hostile to standardization and formal training.

I hold the unpopular opinion that we need those things. The current state of things is that we're not much more than kids hacking away on computers with minimal supervision.

I'd love to see most (if not all) software written with the rigor required to write safety-critical systems.

[tormeh]

>The state of the art in making sure things work is just brute-force, constant testing.

I'm pretty sure the state of the art is using good type systems and libraries that use that type system. It takes some of the brute force out of testing. Unfortunately, many places don't even use the full power of the types their chosen language have. Others choose PHP or C++, piling on technical debt because they sell software the way HP sells printers - the initial payment is low, but you'll have to pay for support and bugfixes forever.

The only thing that can make software cheaper is the customers demanding better tools, languages and processes.

[yannickt]

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.

[atomicfiredoll]

This reminds me of a metaphor: "If you want to know the maximum load of a bridge, you don't drive progressively larger trucks over it until it collapses then rebuild the bridge."

I think you're right that thousands of years of experience play a part. But, overall, that metaphor has had me thinking a bit about how much less predictive building software can be compared to engineering and wondering why that's the case.

Assuming building software and traditional engineering are about as complex and assuming that engineering it is easier to predict (construction deadlines slip too,) I'm curious to see if we can overcome fundamental issues like the halting problem to become as predictive.

[erikpukinskis]

I think the reason designing a building is faster is peoples' standards are lower.

Almost no one wants a building designed uniquely for their lifestyle. They don't even realize you could ask for such a thing. They just pick and choose from what they've already seen.

If that were true of software, it would be just as simple. But people keep asking for things no one has ever done before, exactly, and that leads to unpredictability. We keep seeing unique new software, so we are more likely to ask for the same.

The same is true for buildings when the architect is trying to do something new. Buildings could be just as interesting as software, but most people don't think to ask.

I think in the long term, buildings will be exactly as custom and complicated as software, and designing them will be just as difficult to estimate.

[scandox]

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.

[yannickt]

There is a great essay by Jack Reeves making a similar point.

What Is Software Design? 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]

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".

[rossdavidh]

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]

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.

[DougWebb]

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.

[jordwest]

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?

[ChemicalWarfare]

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 :)

[bitwize]

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.

[firebones]

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.

[OtterCoder]

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.

[farm_code]

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]

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]

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]

>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]

It's requirements negotiation round here.