When you come to a fork in the road, take it!
Yogi Berra
Q1: How much control and authority would you have given to this fourth voice in our choice of platforms (HTML5/native iOS)?
Given that it was both the fourth voice and the sole coder who would be implementing the bulk of the code, they should have the most say, as they are the ones who understand best and have to bear most of the brunt of this particular platform choice.
That said, I gathered that the fourth voice was leaning more towards iOS since it was the platform he had greater familiarity with, while I assume the other coder was not so keen on picking up a new platform, and vice versa. I think that if the one who is more experienced with their preferred platform sets up some boilerplate code which others can learn by example from, and is ready to give pointers where needed, picking up a new platform could be approximated as a fixed cost.
Hence, for pragmatic reasons, given that the fourth voice would be spending say about 40% of the time the other coder would be spending on this project, it would probably have been more efficient to let the fourth voice have their choice of platform, as the other coder has more time to get up to speed on the platform, and then the actual coding workload would be spread more evenly.
Also, I feel that since the fourth voice is going out of their way to help another group, he should be given some sense of ownership in the project as well, instead of being treated more like just a helping hand. There is always the fear that he might bail when the going gets tough, but if you were in such dire straits already, it might be better to err on the side of trust instead of alienating him and risk losing someone who can potentially help to save your project.
Q2: With the deadline just 2 weeks away, how would you, as project manager, have resolved this problem if it were to occur within the team?
Putting myself into the project manager’s shoes is pretty hard, as it is quite inconceivable to have allowed the problem to drag on for so long in the first place, or even have let it become a problem in the first place. I suppose that this originally might have also been a way to hedge their bets, since they were not sure of the commitment level for their external help. However, the same answer applies whether the deadline was just 2 weeks away, or 7 weeks away.
If the contention is too personal, and you do not want to be the one to make the hard decision, then flip a coin and leave it up to fate. Any choice is better than none. The point is to get from idea to product as quickly as you can. The choice of platform is not going to affect the validation of your product much, if at all, at that stage. Evaluating platforms by building separate prototypes would be more appropriate for a bigger company, which had the resources to spare.
Q3: What are some of the issues that we presented that could have happened to any team? List down 3, and talk about how you would have resolved these issues.
Putting off tough decisions
Nobody likes to be the one to make them, which is why you need to have a project manager who is willing to put their foot down when it matters, and trust in their decisions even when you might not be on the side which agrees with them.
Much of the time, if the decision is contentious, there are probably good reasons for both sides of the argument. Even if it turns out in hindsight that going the other way might have been better, the margin would not be that big anyway, and making the decision early would have made up for it by saving time that could be put towards making other aspects better.
Wasting resources
Unless you have prescient vision, some waste is probably inevitable. Taking an Agile / Lean approach helps to minimize waste by failing fast, so that you can recognize that a change of direction is warranted as soon as possible. This could be a change of direction for the whole project, or all the way down to individual implementation details. Having smaller iterative development phases lets you make these course corrections en route, instead of only realizing near the end that you are hopelessly off course.
Making technology decisions
This is distinct from the tough decisions above, which refer more towards decisions which have some degree of interpersonal conflict involved. Even though in the case presented, one of these tough decisions did involve a technology decision, technology decisions are generally not this bloody, editor wars aside.
However, especially in more developer-heavy teams, it’s easy to fall prey to what I’m going to call “Shiny New Framework Syndrome”. For example, in Assignment 1, the general consensus in my team was: Why stick to what we know? Let’s try some stuff none of us have any experience with so that we have a learning experience!“. It was a learning experience indeed.
New frameworks and tools are interesting, but despite their advertised promise, they are never going to just drop right into place and solve all your problems. We would like to think that we are aware of the costs involved in trying out new technology and can account for it, but we all know how developers usually are with estimates.
Also, it is sometimes easy to get caught up in cross-comparing frameworks so that you can pick the perfect one for your project. Next thing you know, you’re writing a comprehensive benchmark to help you pick.
Just pick one and get some real work done. This is a reminder to myself as well – I have definitely been guilty of Shiny New Framework Syndrome on various occasions too.
