What the hell is wrong with our industry when we pretend to contort ourselves into strange shapes to do things we've already done when we really want to do things we haven't done.
How long does it take to solve a problem? As a computer programmer, this is something you get asked a lot. These estimations (and even agile projects do this) fall into a schedule which results in a product with features. Let me give you a problem:
You have 12 marbles, one of them is either heavier or lighter than the rest. In three weighs on a balance scale, you must determine which is the odd marble. How do you do this?
Now, you don’t have to solve the problem, you just have to tell me how long it’s going to take you to solve the problem.
There are a number of possibilities here:
You’ve solved this problem, or a problem like it. Sometimes this is simply identifying that this problem is really another form of a different problem you’ve solved before. Over time, more and more of the problems you see will probably be in this bucket. This is either through experience or through being taught what these problems and their solutions are. If there were a finite number of problems which people could conceivably encounter, then our job would be a lot easier. As it is, this is not the case.
This is the trivial case, as the estimate is simply codifying the solution into... well... code! However, if you’ve solved the problem before, why isn’t there code already? Perhaps you did this at a previous company. Perhaps you did it in a way that wasn’t extensible. Perhaps the programming language you used was different to the problem domain. Or perhaps your language cannot generalise the concept of the solution as well as you can. In any case, the process is largely mechanical, boring work (as trivialities are) where pretty much all circumstances are forseen.
You can identify this problem as one you have doubtlessly proven to be impossible. A single bead of sweat will form on your forehead and you will go through the four stages: Shock, Denial, Anger, Acceptance. Software Engineering differs from programming in that there is a bargaining step; one where you try and change the problem so it’s one you know how to solve. However, you know that at the end of the day, there will come a scaling issue, a correctness issue, or some other thing that is unavoidable and leaves the problem unsolved — a conspicuous kink in the fabric of computing.
At the end of the project you will accept that you did as well as you could. You may be able to adjust customer expectations, or maybe limit “n” to small numbers; whatever it is, you have come to terms with the fact that you looked darkness in the face and didn’t go insane.
This is the interesting case, and the one which you long for as a logician. In this case, you will time-box the problem, and if you can’t solve it within that time, then you will treat it as unsolvable. Then you will deal with it like the unsolvable problem above. The only difference is that in the end, instead of acceptance, you feel guilt.
The question “how long is this going to take” literally ruins the fun parts of software engineering, because the rest is just monkey work. There is literally nothing new going on there.
I had a cap with the words “Impossible is nothing” on it. I had an arguement with a friend who said he loved the slogan, while I was wary of it. I eventually realised we were talking about two different impossibles. I was talking about the literal kind, where people ask you to solve a literally impossible problem, and you go through the four stages. I’ve come to realise that this is far better than not solving a problem which may not be impossible. Ultimately, you want your stakeholders to ask you to deliver the impossible, and spend the time it takes to figure out how to do it, because if it actually is impossible, then it will be a noble failure, and if it’s not actually impossible, then that’s the area where software engineering gets to be exciting!