brilliant comment in the original post, just in case anybody missed it
"When I had my bathroom remodelled, at first I thought it was organized amazingly well and why couldn’t software be like that? There was a designer from Expo, a primary contractor and subcontractors for tiling, painting, etc. a project workbook containing all the documents, including the design, and a logbook for every contractor to record their visit. But it turned out to be just like a software project.
As soon as they started ripping up the walls, the painstakingly drawn design for the tub/shower was hastily and arbitrarily adjusted because the casing for an outside fire extinguisher was in the way. Many of the components turned out to be incompatible with each other and many were not the ones originally ordered (the bathtub was not even the one labelled on its box!)
Communication was terrible – the city inspector would tell the primary contractor to change something, and then a subcontractor would show up and ask me what he was supposed to do. When there was a disagreement about whether the tiling was done properly, one of the contractors disfigured the tiling to force another contractor to redo it. They all had other projects, so for long stretches I had a pile of dirt (for the cement) in my patio and a non-functioning bathroom for months. And toward the end there were some quick patches, e.g. the walls were slightly curved so edges of the tiles looked bad and they just painted the patches, which worked but cost me extra. And a couple of years later when the tub sprung a leak, the plumber couldn’t figure out how to get in there, said they must have done a shoddy job on connecting the pipes, then when he finally got a good look at it, realized why they did it that way. It was exactly like a software project!"
This is exactly it. It's very easy to look at a field we only have a surface understanding of, and conclude it's all fairly straight forward after and expert in the field makes it look easy. I've found that in construction, as in software, there really is a very wide range of expertise too. Some of the tradesmen really know their art, and some are just slapping something together because by the time the customer realses it's probably too late.
Perhaps the biggest difference with software might be that physical reality places greater constraints on the solution space. With software it's easy to innovate the constraints of the pieces to a greater extent, which can easily have unforseen consequences. The difference is not so much that working around constraints is harder, but with every project they can be hugely different. A problem that I suppose design patterns attempt to ameliorate. If only design patterns could be foisted on designers the way physical reality is.
I wish I could up vote the part about physical reality a few times more :) What's even worse is with something like usability, it's even more insidious since may never really find out something is "broken", or even think of it as being broken.
I've always thought of the various kinds of testing as adding some physics to constrain a purely abstract idea within some bounds.
Thousands times this. I've seen situations like that in all sorts of businesses and software projects aren't unique in their inability to deal with complexities and bad communication.
On the other hand, learning to manage software projects gets you an almost unfair advantage at managing "simpler" and more mundane projects where everyone and his mother underestimates the complexities and all the ways things can go wrong.
> learning to manage software projects gets you an almost unfair advantage at managing "simpler" and more mundane projects
I'd add that learning to write software also gives you an unfair advantage in managing the "complexities" of all other processes you'll encounter in day-to-day life, to the degree that it's (at least for me) incredibly frustrating going through life seeing inefficiencies and "incompetence" (not meant as an insult) everywhere around you.
There's a big difference between a construction project and a software project, though. With no formal plumbing experience, a layman can walk into a newly installed bathroom and can tell, for example, whether it has any large holes in the walls; whether the materials used in the construction seem solid; whether, when the toilet is flushed, the waste actually appears to go away into the sewage system; whether the contractor got carried away and installed an industrial air extraction unit when all that was needed was a small vent fan.
When you go in to inspect a software system someone has constructed for you, though, you just don't know. It could have a gaping security hole; it may be dreadfully underpowered for your needs - or ridiculously overpowered. And you just can't tell.
And while, if you need repairs on your bathroom, you can get in any plumber and, even though he may criticise the original installer's technique, he can pretty reliably open things up and expect to find things he understands - pipes, for example, rather than, say a system of motorized buckets. But if you get in someone to look at software you've had built then who knows what the original developer will have constructed.
And as a customer of a bathroom installer, you can (hopefully) understand why you can't just have the showerhead suspended in midair with no pipes to feed it; that you can't have an electrical outlet installed actually in the bathtub; that the bathroom is only 8 by 12 so there isn't room to include a hottub. But no such immediate understanding is available to someone commissioning software.
The physicality of real things renders them much more readily comprehended by the user, which means they have a chance to grasp what goes into creating them. But software's complete lack of physical existence means that it is virtually impossible for anyone except its creators to fully comprehend.
I spent half a year doing home renovation as a way to get out of software development and into something totally unrelated only to find out the two are exactly the same thing. The tools are different, but the problems and the way you go about solving them are freakishly identical.
You wonder why buildings take so long to construct? It's because nothing goes as you expect.
As they say: A plan is just a list of things that don't happen.
To be fair, I can see one difference, though, at least here in Euroland: you have all sorts of standards and regulations that buildings and contractors have to adhere to and especially on bigger changes or constructions you would get an independent expert to check whether your contractors and subcontractors did obey all the rules and when they frakked up somewhere along the way, they have to fix it, typically on their own bill. So it is not enough that you have a house standing there, material, construction and architecture are evaluated as well.
Contrast that to software, it is typically more than enough that you can click through the links and it basically looks like it "works" and if you delivered all that on time then it is already better than probably 95% of all software projects out there and in all but the most critical cases (money or human lives involved) absolutely nobody will check what exactly you programmed and how terrible the underlying software structures and architectures are. If anything, symptoms are being checked and there are requirements you have to meet when money or lives are involved. But that is it then.
We have regulations here in the US also (I had my house rebuilt 10 years ago and recently turned an outdoor deck into an indoor office). But our regulations are primarily safety-related. The wiring must be safe, the pipes plumbed so that drains drain and vents vent, and so on. They don't really inspect the quality of the craftsmanship. If your wall is not load-bearing, they care very little at all about how it is built. The tiles aligning? Your problem.
So, here anyway, it is also safety which triggers the regulations.
You're absolutely right - safety is key importance, style/'correctness' are secondary.
My dad is a contractor. He can literally build anything. I grew up with this, going on jobs with him, being in that whole space. I do software (but can build things too! :) and the one thing I've inherited from him is the 'do it right' conviction. Just like some of the tv shows where the hero goes in and says "omg, how could they do this?" or "this is all gonna have to be ripped out and re-done the right way because the wall is load bearing", that's my dad.
And for software more and more as the years go by, that's me. Yah, there is no software test we have to take - we just have conventions and patterns, none of which (I've seen) are governed at all, although I'm sure some are somewhere. Sometimes I wish this was the case. I've worked with bad coders and seen code that is unbelievable and part of me thinks this could all be avoided with regulation. But then, obviously, the other part (that wants to stay alive and put food on the table) knows that when this happens, the world changes and software will not be the 'easy' path it is now.
Like my dad, I have that dna in me to do the best job and the right work. But if there were regulation like in the building industry, a whole universe of different types would be out of a job. I don't see it happening in my life time even if AI starts building stuff.
But in software, the people smart enough to say "this is all gonna have to be ripped out and re-done the right way", are rarely in a position to not get their asses booted out the door.
It would help if you understood his reference, which I believe is the show Holmes on Homes. For example, Holmes the main character/contractor, had to rip off an entire roof (shingles, layering) of a flat-roof structure because it needed to have slight angles for the water to flow off. Otherwise any patching would not produce a leak free roof that would last for 20+ years like it should. I've worked on software projects where we went back in and completely re-worked the UI or re-wrote some data access layer stuff without a full rewrite. That would be a more analogous example.
In the US, the regulations often do little to protect construction clients, particularly individual homeowners. When contractors fail to observe the code, what recourse does the client have? Most often, the only thing available would be a lawsuit. Lawsuits are always expensive. This is especially true when they hinge on a technical question such as: "Did the defendant observe [insert building code citation] while installing the pipes that are now buried under a slab of concrete?" The costs make suing rather unattractive, particularly because here in the US, the loser does not pay the winner's litigation expenses.
Several states have consumer protection boards set up for just this sort of thing. I know because I filed a complaint in CT against a contractor who did faulty work.
My complaint along with a few others were compiled, leading to a hearing where his license was revoked. Additionally, the state had a fund set aside for people who lose money on shoddy work (up to 15K). We were one of the lucky ones, as he only cost us $3K (which we got back). Others lost 10-20K.
Bringing it around to the topic at hand, a code inspector for 'code' is an interesting idea. That said, I'm okay with devs/agencies being held accountable for their coding work -- as long as clients are likewise held accountable for paying on time, proper briefs, etc.
I agree that savvy rogue contractors can skirt the law and build crappy, unsafe stuff (like came to light in Miami FL after hurricane....Hugo, I think...). But what regulations do well is make sure the honest guys know how to be safe. Whether they go to their conferences and learn best practices is optional, and they have to decide if they want to bear the expense.
If they ignorantly (not maliciously) wire the bathroom in an unsafe manner, however, they will fail inspection and be made to fix it properly. This is useful to the individual homeowners. In a way it's similar to the adage that "locks keep the honest people from breaking in." With both regulations and locks, they are less likely to stop the criminals.
"When I had my bathroom remodelled, at first I thought it was organized amazingly well and why couldn’t software be like that? There was a designer from Expo, a primary contractor and subcontractors for tiling, painting, etc. a project workbook containing all the documents, including the design, and a logbook for every contractor to record their visit. But it turned out to be just like a software project.
As soon as they started ripping up the walls, the painstakingly drawn design for the tub/shower was hastily and arbitrarily adjusted because the casing for an outside fire extinguisher was in the way. Many of the components turned out to be incompatible with each other and many were not the ones originally ordered (the bathtub was not even the one labelled on its box!)
Communication was terrible – the city inspector would tell the primary contractor to change something, and then a subcontractor would show up and ask me what he was supposed to do. When there was a disagreement about whether the tiling was done properly, one of the contractors disfigured the tiling to force another contractor to redo it. They all had other projects, so for long stretches I had a pile of dirt (for the cement) in my patio and a non-functioning bathroom for months. And toward the end there were some quick patches, e.g. the walls were slightly curved so edges of the tiles looked bad and they just painted the patches, which worked but cost me extra. And a couple of years later when the tub sprung a leak, the plumber couldn’t figure out how to get in there, said they must have done a shoddy job on connecting the pipes, then when he finally got a good look at it, realized why they did it that way. It was exactly like a software project!"