How to make significant technical decisions given very little time

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?

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:

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.
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.

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.

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:

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.
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.
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 🙂

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.

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,

What are the target platforms
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..
How is the current app connecting to the world and how is the security is handled (database connections / web services / etc…)
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.

Filed under: softwareengineering - @ 19:49

Thẻ: development-process, time-management