Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Sometimes, after having done a very thorough analysis/research, you can think of a number of solutions to a problem, but they all have considerable downsides. What do you do in such a situation?

For example, I can think of a number of options:

  • Randomly choose one of the solutions.
  • Postpone the issue, do something else in the meanwhile, and revisit the problem a few months later.
  • Find someone who is willing to take the decision (and therefore also the responsibility) for you?
  • Obstinately keep on looking for alternative solutions.
  • Find people to discuss it with, and hope for a moment of clarity.
  • Leave the current situation unchanged; that is: don't solve the problem at all.
share|improve this question

closed as not a real question by gnat, Kilian Foth, jmo21, Jim G., Robert Harvey May 15 '13 at 19:10

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
you then pose the problem on SO –  JoseK Sep 24 '10 at 8:32
1  
This is hard to answer in theory; it can be quite different depending on the exact case. Post a question on SO anyway. –  Job Dec 14 '10 at 18:16
3  
This question doesn't even mention programming. –  David Thornley Dec 14 '10 at 22:51

11 Answers 11

Adapting from Occam's razor: Choose the simplest solution.

Occam's razor... is a principle of parsimony, economy, or succinctness used in logic and problem-solving. It states that among competing hypotheses, the hypothesis with the fewest assumptions should be selected.

...The razor states that one should proceed to simpler theories until simplicity can be traded for greater explanatory power. The simplest available theory need not be most accurate. ...the exact meaning of simplest may be nuanced...

share|improve this answer
    
I like this answer - it's a very good disambiguation for choosing a solution when none of the alternatives have any clear advantage except for simplicity. The simplest alternative will also be the easiest to understand later on when perhaps the problem becomes more well-defined and the choice of solution more obvious. –  Joris Timmermans May 15 '13 at 12:38

Picking a solution when the choice isn't obvious can't be cut down into a set of rules.

For instance, you say when all solutions are equally bad?, this sort of implies that you have just one scale on how to judge the "goodness" of a solution.

In practice, you don't, you have many.

Things to consider:

  • Risk of failure
  • Risk of security or other problems with that solution
  • Cost of implementing
  • Benefit to the user
  • ...

Now, it might be that you have some sort of system that takes things like this into account so that you can compare solutions, but rarely is all solutions similar in all but one dimension. If they were, you would just pick the best one in that dimension and be done with it.

Also note that the act of doing nothing is also a solution. It might not be a good one, but seeing as it already competes with other solutions that aren't good either, it is definitely worth looking into, with the same criteria as above.

And... to look for more solutions is also a solution. You postpone the decision, pending new information.

But there really isn't a basic "calculate X and pick the greatest" type of function here. It all comes down to this:

  • It depends
share|improve this answer
    
very well put +1 –  Alan Sep 24 '10 at 16:38

One approach is to implement the solution that's can be completed with the lowest risk of failure. See where the land lies at that point and build on that.

KT problem solving analysis can sometimes help get things into perspective also.

share|improve this answer

Here I assume problem as a bug in software or complex logic to achieve a feature. Both the things are highly related with Client's need. If Client needs the stable system immediately then we need to work on that instantly. So, I would pick the Solution that has minimal downsides as well as it meets the client's requirement. If there is a workaround to balance the downside I would go for that else I'll intimate the Client and allow him to decide what he wants

share|improve this answer
    
@Kwebble Great! That would also be good option :) –  Tech Jerk Sep 24 '10 at 8:49

If the solutions are equally bad or equally good in all possible estimates then I think you get to choose which one you would prefer. Prefer to code and prefer to maintain.

Many of the answers have good points about checking that they are actually equal, but if they are from the current known data then pick the one that is the most comfortable.

If you have already done that and the team is in a tie vote, bring in a tie breaker.

share|improve this answer

I do a formal decision analysis. I have never had all solutions come up with the same value. Here is what I do:

First decide on the factors that go into making the decision things like cost, security, etc. Then have the decision makers decide how to weight each factor (by putting them in order of importance (1-5 with 5 being the most important). This is the ciritical step to getting buy in on the decision at the end.

Next rate each possible choice against each of those factors on a scale of 1-5 (5 being the best). Then multiply each rating by the appropriate ranking factor. Then add up the numbers. Almost always one choice will be better. If two are extremely close or tied, choose the simplest to implement or have management pick between those two.

INcidentally if you find yourself 'fudging' the numbers to make alternative B win, then you know which one you prefer and you are also probably missing an important rating factor or you wouldn't need to 'fudge' the numbers.

share|improve this answer

At the end of the day if it needs to be solved you have to pick a solution (there's always one choice that seems marginally less awful) and get on with it. (I have, too often, been the person who has to make the decision and I have, too often, procrastinated using all of your suggested methods).

Once you start working on the solution you will gain more insight and that should either tell you you're doing as good a job as can be done or give you sufficient understanding to find/implement a better approach.

The question can only arise if you actually have to solve the problem to reach your goal - if it doesn't then why are you worrying about it? Yes, by all means, search and discuss but if it needs to be done then do something - one of the better things about programming is that it is possible to refactor (sometimes on a truly epic scale) the solutions you have.

share|improve this answer

Seems to me like a case of Cost-Benefit Analysis. You take your different solution options (and BTW, "don't do anything" and "defer the decision" can both be options). You list out all of the pros and cons to each option. Then, you figure out a way to quantify those different pros and cons. The quantification could be in dollars, or it could be in arbitrary "points", development hours, technical debt, etc. Yes, this is going to be subjective, but you make your best educated guess at things. It is better than nothing.

After you have done this, you will end up with a metric for each option's costs and benefits. Most likely one option will have either less cost or more benefit or both, and will be the most appealing choice.

It is highly unlikely that all of the options will end up at the same amount. But if they do, then they really are equivalent, and you can pick arbitrarily or pick your favorite.

share|improve this answer

The idea that I would randomly choose, or try to push the responsibility to someone else doesn't sit well with me. I had to work for about a decade before I started getting real responsibility for architectural decisions. I would have a hard time throwing that privilege away for brownie points or to "let someone else take the fall." No guts, no glory.

That said, some projects are Doomed to Fail. In which case, I see it as my job to become a thorn in the side of the person or team pushing for the project in order to get it canceled. On one such project, I would meet with my manager every single day and say, "You know there is no business reason for doing this?" She would say, "I know, but we still have to..." By the end of the first month, the meetings were very short. "You know what I'm going to say?" "I know." But after about 2 months, she had gotten the project canceled. 1-5 programmers had worked on that for 5 years. I felt very proud that I had succeeded where so many others had failed.

Sometimes, asking the questions that would encourage the business sponsor to give up or cancel the project teases out some expectation or aspect of how the software would be used that makes the project solvable, or maybe lets you come to a compromise that brings the possible software solutions back to the land of reality. Sometimes it gives me the necessary business understanding to justify a somewhat limiting or costly architectural decision, or a willingness to take on massive technical debt in order to keep the business running.

The sub-conscious mind is a powerful tool. If you have the problem loaded into your subconscious, then time can do wonders. Often a solution will just pop out when you least expect it. Review the problem whenever you feel your subconscious has moved on to digesting other things.

The more ways you can learn to think about a problem, the more likely you are to improve your potential solutions, so talking to people is a great idea.

Obstinately keep on looking for alternative solutions.

Sometimes this pays off, but sometimes this is a trap that makes you mentally spiral into an unhealthy place while getting nothing done. If if you feel you are just banging your head against a wall and you have the option to take a break, definitely take it (work on another project for a few days or a week), let your subconscious do the heavy lifting for a while, and come back to the original problem after some time has passed.

One thing that I have not seen other people suggest is to ask yourself two questions:

  1. Which technical solution is most compatible or most flexible with the ways the business might use the software?

  2. What kind of software are you building? Are there common themes that fit with one answer better than another? This may be a question about the business direction of the company.

The multiple-bad-solution situation moment is also the opportunity for the greatest creativity. It forces you and your business partners to ask the essential questions that define your software and your business. There is usually a "win" situation hidden in the moment of deepest darkness. If that's not the case, then maybe it's time to update your resume.

share|improve this answer

One approach is to pick the least destructive, easiest to back out approach. At least if you have to go back to square one it won't hurt as much.

share|improve this answer

For the time being set aside the solution and revisit the problem and really get a handle on the root issue. Ask why 5 times. Sometimes a bad solution is a symptom of a poor understanding of the problem.

The other thing I've encountered is that sometimes there is no perfect solution. This may be what you're describing. In that case, I like to prioritize and weight the criteria so that I can choose the best of the worst.

And sometimes you need to find someone with more experience or a fresh perspective.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.