Maybe programming is tortured analogies all the way down? (Not really, but there are some over-engineered code bases that feel like it.)
No, it's turtles.
Tortured turtles.
Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
11–18 of 18 posts
Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#12This may be a tortured analogy, but it boils down into a basic problem: 1. You know there's a bug 2. You can't reproduce it Several next steps come to mind: 1. Hire an outside expert who's dealt with this sort of thing before. They may be able to theorize what's going on and come up with a solution. 2. Install measures that don't prevent the problem but prevent the damage. For example, an emergency failsafe that shut…
My experience has almost always led to #3 being the most workable solution, but not a perfect one.* #2 should be incorporated into any project, but it presumes that you know all possible ramifications of incorrect operation. An electrical breaker works because complete non-operation is generally better than death. For many software companies, complete non-operation is a precursor to death. #1 is almost never a good s…
Brief non-operation (reboot / service restart) is often better than a prolonged outage. Particularly where SLAs are set to create an expectation and acceptance of this, and where redundancy exists.
I'm thinking too that there's a feedback process at work here, and some sort of damping mechanism would help with that.
Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#13Earlier quoted context omitted.
My experience has almost always led to #3 being the most workable solution, but not a perfect one.* #2 should be incorporated into any project, but it presumes that you know all possible ramifications of incorrect operation. An electrical breaker works because complete non-operation is generally better than death. For many software companies, complete non-operation is a precursor to death. #1 is almost never a good s…
Brief non-operation (reboot / service restart) is often better than a prolonged outage. Particularly where SLAs are set to create an expectation and acceptance of this, and where redundancy exists. I'm thinking too that there's a feedback process at work here, and some sort of damping mechanism would help with that.
Agreed, and many architectures are designed to have components "transparently fail" without impact to overall operation. When you have forced failures, feedback/damping is absolutely required. However, (my experience dictates) that most such failures are unplanned and unknowable at the outset, and you can only dampen conditions which are predictable.
Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#14The problem here is that there is very little, if anything, as complicated as software. Preventing leaks like in the example is not that difficult -- you put in pipes that can handle a lot more than the required load, because it is unacceptably expensive to have them burst and the better pipes are not that much more expensive (putting them in is).
Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#15Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#16The problem here is that there is very little, if anything, as complicated as software. Preventing leaks like in the example is not that difficult -- you put in pipes that can handle a lot more than the required load, because it is unacceptably expensive to have them burst and the better pipes are not that much more expensive (putting them in is).
Nope. I actually live in a luxury high-rise, and while the pipes don't leak, the pressure and temperature is about as bad as the OP describes.
No bidets, though.
Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#17Re: Fictional Plumbing Problems As A Tortured Analogy For Software Engineering
#18I was hoping for an analogy to explain how difficult it is to estimate long-term programming work due to unexpected "black swan" details popping up as you get into the work that add considerable effort to the project. It's a situation I find I need to explain often, and in layman terms, so a perfect analogy would be great...
I think that's been beaten to death with http://www.quora.com/Engineering-Management/Why-are-software...