I have got 2 days for making a very serious decision about the tools and platforms that my company is going to use in order to port its WPF application to Linux / Android / iOS whatnot.

Obviously I can point to my seniors that 2 days is hardly enough for reading about all possible options, and what about trying, making prototypes etc. I can say it, it won't help me a bit, I have got 2 days, and after 2 days the decision would be made. Period.

From one side I am frustrated, from other side I think there is a grain of truth in this approach, otherwise I can easily find myself buried under dozens of downloaded SDKs, frameworks, APIs, blog articles etc etc doing bench-works, running samples and forgetting in the process what it all was for.

Still I am afraid that a wrong decision will cost the company dearly. So what do you think is an "ideal" process for making such decisions?

  • 4
    Write somewhere that the decision is nearly impossible to take in two days. Then try to make a not-too-bad decision, and document that your decision is not the best. In other words, cover your ass. Qt5 might be considered. Or make your product an HTML5 web application (possibly using some HTTP server library e.g. libonion or FastCGI) – Basile Starynkevitch Jan 20 '15 at 11:20
  • 2
    @gnat I do not agree, that it is a subjective question, even if there is more than one possible answer still we all can gain from others experience. – Flot2011 Jan 20 '15 at 11:25
  • 9
    There is no 'best option' in many cases, you could write it as a PHP webapp and it'd work. Or you could write it as a Qt program and it'd work. It could be a openGL game-interface UI. All of these are acceptable choices, the trick is to choose one and then set about making it work. Do not paralyze yourself with doubts once you choose something. – gbjbaanb Jan 20 '15 at 11:44
  • 5
    Very bad example because in the case of the example there is one technology that is an obvious choice for this - Xamarin. Keep the .NET backend code, just replace the UI with something. Handles all given cases. So, this is more a case of "I know nowthing about cross platform systems for .NET". – TomTom Jan 20 '15 at 13:21
  • 7
    Saying that 2 days is not enough is not very constructive. Is 3 days going to be enough? Or do you actually want to spend 2 months on it? And how much better is your decision likely to be? ~~~~ If you say that you need a week and are confident that this is easily going to save hundreds of hours of development time down the line make sure to mention this. It may not help, but there is always the chance that the stakeholders like your business case. – Dennis Jaheruddin Jan 20 '15 at 16:07

If all you have is 2 days and no time to prototype or even read upon all the alternatives then there's really only 2 options:

  1. ask someone who knows and follow their advice. This may not necessarily mean asking an individual but spend the 2 days searching through blogs and articles to glean enough information to make a slightly-better-than-uninformed decision.

  2. Do a little research into all the mainstream options and then pick one. Sometimes leadership means not being afraid to make the wrong decision, its often more important to make a firm decision than to vacillate.

You can cover yourself by coming up with architectures that are more decoupled and therefore easier to change - eg a client/server model will allow you to replace your UI technology with another with minimal disruption.

  • 10
    +1 for "don't be afraid to make the wrong decision" Sometimes getting caught up in 'analysis paralysis' is worse than making no decision at all. We are all human. Do your best and get on with life. – semaj Jan 20 '15 at 15:58
  • 1
    vacillate: alternate or waver between different opinions or actions; be indecisive. – TankorSmash Jan 20 '15 at 19:25
  • 10
    +1 for "cover yourself by coming up with architectures that are more decoupled and therefore easier to change" – Darth Egregious Jan 20 '15 at 19:40
  • 2
    @emodendroket Windows Workflow Foundation. – MetaFight Jan 21 '15 at 0:52
  • 2
    If your problem isn't mainstream, don't expect mainstream solutions to work out well. This is where decoupling and flexibility is crucial. Look for frameworks/libraries that make it easy to go do your own thing instead of making you shoehorn something into their expectations when they didn't seem to anticipate what you need to do. – jpmc26 Jan 21 '15 at 2:28

It may seem that I am going against the stream, but I have recently read the book Creativity, Inc. by Ed Catmull and there was a really nice paragraph tackling this situation:

Andrew Stanton spoke next. Andrew is fond of saying that people need to be wrong as fast as they can. In a battle, if you're faced with two hills and you're unsure which one to attack, he says, the right course of action is to hurry up and choose. If you find out it's the wrong hill, turn around and attack the other one. In that scenario, the only unacceptable course of action is running between the hills.

I am sure it can be applied for your situation as well. Maybe you can make the decision today by picking one and start working on it. If it works, then you'll have something ready in those two days and you'll say - "I picked this, and I can show you what we can do with it because I ran few tests...". If you notice in a day that the picked solution is totally not worth it, you can then choose a different one and work with that the next day. The worst case scenario is that you'll use both days to test two platforms, finding out that neither of them works - but that's ultimately the right answer, isn't it? Take out the weed, get rid of wrong possible choices, so any next decision will be much better than the previous one. The best case scenario is that you'll pick the right one right away and will have something ready to show after two days.

Obviously you won't master any platform in two days, but picking one ASAP will definitely give you a better perspective on how it works (much more than just reading about it) and will lead you to a better answer.

  • 12
    Though I agree with you at a global level, sometimes rushing forward on a war field is pretty suicidal. – Flot2011 Jan 20 '15 at 14:26
  • Nobody mentioned rushing though. I never said to walk to the boss today and say - "Here is the solution. Right here and right now.". Instead I am proposing to pick one in the head and try running it and tinker with it. Simply reading about it and discussing it with somebody else won't do the trick. I do believe that going ahead and trying it out will lead to choice that has much higher quality. – Michal Jan 20 '15 at 14:39
  • 6
    @Flot2011 though if you have a MBA, you stay where you are and send all your troops to fight either hill. If they all die, oh well, you get more troops and continue but this time saying that your experience as a general makes you so much more ... deserving of monstrously more salary. – gbjbaanb Jan 20 '15 at 17:55
  • 1
    "Picking one ASAP, then prototype" strikes me as very bad advice in this situation. Yes, prototyping is important, but also time consuming. Non-trivial problems often have more than 2 possible solutions, and 2 days are not enough to prototype several technologies. – meriton Jan 20 '15 at 20:20
  • @meriton I feel what you mean - I agree, prototyping is time consuming. I did not explicitly state "do prototyping" - that's why I carefully chose the word tinker - explore the platform, write some little code, open some basic implementation files, see how it works inside. The chances are that the decision maker will not get all the details right but by trial and error he/she can definitely improve the quality of the decision. – Michal Jan 21 '15 at 14:05

gbjbaanb makes some very good points. I just thought I'd add a bit.

It's obvious you don't have enough time to make a perfectly informed decision. Your only option is to try and make a decision that will minimize future pain. I'd suggest:

  1. Clearly document the nature of the situation: Send an email to your manager(s) and CC their managers and the stakeholders. Explain that the problem you've been assigned is a tricky one but that you're willing to give it your all. But note that, given the strict time constraints, you can't guarantee your findings to be optimal.

  2. Find a framework/platform with a large and active online community. The last thing you want is to be stuck debugging an obscure framework alone.

  3. As previously mentioned by gbjbaanb, mitigate your porting pains and risks by using a loosely coupled architecture. If everything goes pear shaped with one of your technology choices, this will make it easier to swap it out.

I've been in your situation before and it eventually turned into a political nightmare. When the system didn't magically work people began pointing fingers and things got ugly. That's why my #1 recommendation is to clearly document that you did your best against impossible odds.

Good luck :)

  • 17
    Re: #1. Nobody likes a whiny loser, so just highlight you've done the best you can against impossible circumstances, then you look like a go-getting team-playing pro-active winner! Management likes that kind of thing. Incidentally, there are many reasons why the big rewrite doesn't work, the choice of one tech over another is usually the least problem. – gbjbaanb Jan 20 '15 at 11:41
  • Yeah, I realised it was a bit whiny so I modified it. – MetaFight Jan 20 '15 at 11:43
  • Personally, I'd be more specific than "not optimal", as the does not specify the severity of the uncertainty. A manager with a "it doesn't need to be perfect, just good enough" mentality will blithely ignore this warning, unaware that you meant to say that the technology might not be good enough. – meriton Jan 20 '15 at 20:28
  • 3
    Instead, I would identify concrete risks and escalate them to management. For instance: "Based on our current knowledge, we think technology A is the best choice. However, due to the short deadline, we were unable to verify that this approach can handle the workload expected of this system.". Management can then either accept the risk, or reduce it by ordering further analysis. – meriton Jan 20 '15 at 20:31
  • +1 for point No. 2. Go for a solution that has a mature and well developed community behind it.If you fine more than one such solution, you can always browse online forums, blogs, post questions etc and find out which suits you best – A Nice Guy Jan 21 '15 at 7:37

Since they've effectively given you little time to do more than pick candidates out of a hat, I'd adopt the following approach.

Select technologies that:

  • Have a large user base
  • Have active support (via whatever channels)
  • Are being actively developed

By definition, this would rule out any bleeding edge technology, however good it may be.

Also, resist the urge to go with technology X without further analysis simply because Fred the developer has used it in the past. It is unlikely to be a perfect fit, and if Fred moves on to pastures greener, there goes your domain expert.

  • Although if technology X is a good enough fit, and Fred is willing to educate the other developers, doing so may be a good way to kick-start the team. – user Jan 20 '15 at 15:43
  • For sure - if it ticks the other boxes... – Robbie Dee Jan 20 '15 at 21:46

2 days is a very short period for making that kind of decision, but since you have to do it in 2 days list following,

  1. What are the target platforms
  2. What are the custom / third party components used in current app where it might require considerable effort to port. for example : chart components, grid components, reporting components, etc..
  3. How is the current app connecting to the world and how is the security is handled (database connections / web services / etc...)
  4. How it's distributed and how updates provided

Now you need find alternatives you can use for all the target environments

For each alternatives find out the support for each to use the connectivity / security that current app is using.

then for each custom / third party components find out if there are easy to use alternatives for each.

And then think of how the distribution can be done for each alternative you found.

I think for 2 days this should be the scope you should be able to cover and based on the results you can provide a solution.


As much as I like to learn and experiment new stuff, under time constraints the best option is always to go for whatever is or feels more comfortable to work with. Stick to what you know.

Even if in the long run it becomes clear you didn't choose the best option, anything you developed meanwhile continues being valuable and wraps a kind of field knowledge that is still completely usable and portable. And that's exactly because the comfortable context, tools, platform you chose to use stay out of the way and make you see what really matters.


Make a list of the factors that should go into choosing, things like: Performance security cost ease of use ability to do X ability to do Y developer familiarity time to market etc.

This should take less than an hour (actually it should take less than 15 minutes), then sit down with management and have them prioritize those factors. (The chances of their priorities and yours being the same are remote although you can guide thier choice somewhat with suggestions as to priorities.) Now you know what to evaluate about the technology.

Pick three or four common solutions to your problem based on an internet search.

Then read enough to make a good guess about how well each of the choices fits their top 3-4 priorities. Assign a numeric value to each choice. Do the math by multiplyig the rating of each priority times as value set on that priority (10 for Number 1, 8 for number 2, 6 for number 3 4 for number 4 or what ever numeric you like). Now you have a numeric score for each possibility. Generally it will be obvious which best meets the assigned priorities. Even better you now have something analytical to take to them to prove your choice. They will usually buy off on your choice because you have the numbers to support it. If the numbers don't support it then you need to ask yourself why you prefer the other one and either go with the best one numerically or revisit the assigned numbers.

By concentrating on what the real priroites of the choice are you can cut out a lot of research time. You can probably have a guess within a day and then have a day left to take the top 2 possibilities and download trial versions if need be and play a bit with them.

  • What you described is called the "Analytic Hierarchy Process". It is the most common technique I've seen used for performing trade studies. Its strength is that it helps decide the best option in a fairly objective manner and takes all stakeholders opinions into account. I was surprised to see how complicated the websites make this technique seem. Don't let the apparent complexity shown by websites sway you, it really is very easy to use. Anyways, since I couldn't find a good example I suppose Wikipedia is as good a starting point as any en.wikipedia.org/wiki/Analytic_hierarchy_process. – Dunk Jan 21 '15 at 19:26
  • 1
    It takes less than ten minutes to set up the structure in a spreadsheet (the most complicated part is deciding what factors you want to compare priorities on) and then it is easy peasy to fill in. – HLGEM Jan 21 '15 at 20:14
  • It really is that easy. We also do surveys where everybody assigns a value to each category to determine what everybody thinks is most important so we can apply weights to each category. After all, the software team thinks processor speed and memory is always top priority, but the hardware guys seem to have opposite opinions because battery life is important to them. Of course, the customer typically counts towards at least half the rating weights and doesn't give a darn about software or hardware concerns. The descriptions online seem really complicated when it is not. – Dunk Jan 21 '15 at 22:56

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