How do you deal with over-the-head APIs/technology

Question

I guess most people have been in this situation.

The initial project planning begins. The requirements are outlined. After architectural review and sorting through APIs/Frameworks the fitting technology is picked. The development starts.

And then it starts. As soon as you need to do some supposedly simple supporting things, framework/API start to backfire, and instead of doing any work you end up fighting against the technology. The research time skyrockets, forums are silent, nothing seems to be done, and even when you get something to work, you're not really sure it's done right.

How do you manage in these situations? Do you go for hacks, do you research further, what do you say to management?

Answer 1

Prototype, Prototype, Prototype!!

If your team is not familiar with a particular framework then prototype something in it to evaluate where the pain points are.

Matt Raible (Java Web framework comparator guy) suggests working with a framework for one week if possible.

Prototyping includes investigating the community support behind a framework and other factors

Answer 2

Managing external dependencies is the bane of many an IT project. Many years ago the experienced programmers I worked with always made sure they had control over their dependencies - Usually by insisting that source code licenses were bought.

Personally, that has not been my approach. I tend to be of the under promise, over deliver school of thought. There are times when I have had to stick my neck out, but I do private research beforehand to be 99% sure - usually doing a private project often in my own time to make sure the technology can deliver. In effect prototype, test, validate then promise.

There are situations where I do get caught out - and have to either backtrack or be inventive. Having a creative mind with plenty of broad experience helps here, but so does talking to other people. - and not always programmers. Sometimes the solutions come from really strange places.

As for dealing with management, the key is honesty. Talk early, and often. Don't leave it to the last minute as letting down managers/customers the day before a big delivery just makes you look like amateurs. Being able to say 2 months before the deadline that the managers need to choose between dropping a few features and/or delaying the shipping might not be popular at the time, but it does allows the rest of the organisation to do their jobs and to plan. The key to being able to do this is having a good task management system that tracks times and task estimates. Having solid evidence to back up your point of view makes it much more likely for you to be listened to.

Answer 3

"How do you manage in these situations?". What I have seen / experienced:

the number 1 point I agree with Ptolemy: be honest:

If it is really a problem: go to that room, tell the problem, sit back to await the anger response and then ... work towards a new plan/solution. (the guy is not angry at you personally).

There are IT courses which deal only with this situation. You are placed with actors and they place the angry client who hears this news. You get a lot of tips around it. Sounds stupid but probably only after doing it you notice the value of it. I left with a sheet with 80 points to remember in those situations... (and practice).

This situation is typical probably even more so today where budgets are tight, sales are done on "lowest offer", the planning you gave is trimmed 5 times before it is accepted by the customer... (including that prototype since "he is hiring you because you are the expert and otherwise it is 10 others waiting") etc...

-- Another thing might be lateral thinking: if it can not be done in this way try to propose something completely different that provides the same value for the customer. If the technology does not work AT ALL / is broke / jumps out of the deal / etc... If the customer buys in to this it can deliver the same value at the end. But bringing it is also pretty hard. (for some and totally not for others). You need the really experienced guys for this. A likewise situation is that the Technology is NOT YET up to it... it takes some months... So you need to convince to customer to replan and accept the replanning and impact on his organization...

-- Another 'lesson learned' is to invoke the senior senior guys as soon as you notice that it goes in this direction. They often have dealt with troubled projects and are really helpful in these situations. Often they only travel from troubled project to troubled project.

-- Another lesson learned is to let your architectural stuff go through verification channels especially on the bigger projects. A signature can cover your ass. (save all your e-mails LOL)