Are there any strategies to avoid satisficing?

Question

Satisficing (a portmanteau of "satisfy" and "suffice") is a decision-making strategy which attempts to meet criteria for adequacy, rather than to identify an optimal solution. A satisficing strategy may often be (near) optimal if the costs of the decision-making process itself, such as the cost of obtaining complete information, are considered in the outcome calculus. (Source)

Most decisions in software engineering are easy enough to take without pondering for hours on the subject. The first solution that comes to mind is usually good enough, so we can quickly use that and proceed to the next decision.

However, there are also those rarer cases in software engineering when you have to solve a more difficult and / or critical problem. Those problems can cost you a lot of money or time when solved in a suboptimal way.

In those cases I am usually trying to come up with several completely different solutions approaches of solving the problem, then pick one and refine it until I am fully satisfied with my solution.

Usually this works, but sometimes I can only come up with one adequate, but not really good, solution. I am aware that my solution is not very good and the problem is critical enough to warrant some more effort. However, knowledge of the solution I already found blocks my creativity, so I just can't find a second one (at least not right away). I am stuck with my mediocre idea and, unless I can ask someone else, I have to implement it to move forward.

Are there also techniques to overcome this? The two things I can think of is holding a brainstorming session with someone else or going for a walk.

What do you do in those cases?

Answer 1

In my experience I address that by putting the problem aside for a while, say a week. Let it rest. Then come back with a fresher mind and you'll start to see things you didn't before.

Of course, YMMV.

Answer 2

Describe the problem to someone else and ask how they would solve it. Sometimes it'll be the same solution you came up with, in which case, point out the flaws you've already perceived in it and continue the dialog.

Sometimes it'll be a solution you didn't think of, or one that helps you solve problems with the solution you did have in mind.

However it works out, I've found discussing the problem with others to usually be a very beneficial strategy.

Answer 3

Satisficing is the technique that gave birth to AI. Some very important software, including driving direction generators and network routing are both done based on a tradeoff of efficiency for completeness.

The best way to deal with this issue is to implement the solution, and fix the incomplete parts of it when and if it becomes apparent that other parts of the project require it to be fixed.

Obviously there's a lot of room to go in the wrong direction on this one and end up with something sloppily put together, but keep in mind that the context of the entire system is where the quality of what you write is going to be measured.

Answer 4

I find it useful to stop looking at the solution, and start looking at the problem. Maybe I am trying to solve the wrong problem. Look, and see if there is actually a different problem there. If you feel that your solution is only 'adequate', it could well be because it's not addressing the right problem.

Perhaps your client asks you to make a better kettle. Do they really want a better kettle, or nicer coffee? Maybe you don't need to build them a kettle at all, and instead just take them to the café round the corner.

Answer 5

I would normally have two problems with putting a problem aside for a week: a) my boss probably wouldn't go for it because the business will usually need a solution sooner as opposed to later, and b) I have the attention span of a gold fish, so if I drop a problem for that long, I will have to take time to walk through the problem because I've filled my brain with dozens of other problems in the meantime.

That's not entirely bad, because sometimes I do find a better, more elegant solution when I'm forced to refresh myself on the code and the business constraints that define the problem, but sometimes I just spend half a day running myself into the same dead-ends.

All that being said, the idea of putting a problem aside is a good one, but it's the time frame that's important. I've often realized a solution while eating breakfast the morning following an end of the day spaghetti-code brain lock up fiasco.

Trying to articulate the problem to colleagues often helps, just because the effort will expose gaps in your understanding of the problem. Usually the other person won't find a better solution unless they're actually working with you on the problem from the beginning, just because they won't understand all the constraints that you've probably spent days mapping out in your head.

To answer the original question, my preferred method after taking a break and running it by some colleagues, is to implement the adequate solution and just get something working.

One reason is that if the client decides that wasn't what they wanted, because they never really know what they want in the first place, you won't have spent too much time on something that'll be thrown out anyway. Another reason is that the adequate solution might just be that: adequate. You can move on. The best reason is that an implementation gets you into the hard questions quickly, and from there you might start to see a better solution.

It's like building models as an architect. You can do lots of drawings, and even spend a lot of time on nice renderings, but it's really more effective to quickly get a glue gun and starting throwing cardboard models together. Once you can see it in 3D you can start to see where things don't line up properly, and you haven't wasted your time on nice renderings that will gloss over the shortcomings.

Answer 6

Why do you want to avoid satisficing? It is necessary for survival.

Answer 7

I know this is a bit heretical but I find writing documentation for the solution helps. Just putting it down on paper forces you to think and organize the problem differently than coding on it. Attempting to describe the solution in terms of the business problem tends to help point out were the gaps lie and these in turn suggest alternate solutions. In the best cases you end up with new approaches. At worst, you end up with documentation. Give yourself a set amount of time. Start with an outline and work until you run out of time, you complete the documentation or you are inspired with alternate solutions.