11

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?

Coder
  • 6,958
  • 5
  • 37
  • 49
  • +1: What a great question. Worthy of a +10. I've had the same experience. – Jim G. Nov 20 '10 at 16:41
  • It is a great question. So many times I've seen where words like "leverage" and "synergy" were used to sell some 3rd-party stuff. So then you get locked into it, and they go and pull it out from under you. (MS likes to do that.) Meanwhile, the original evangelists are long gone. – Mike Dunlavey Nov 20 '10 at 17:37

3 Answers3

9

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

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
  • +1 for prototype. Having something actually working even if it is put together with duct tape and propped up with sticks, and will crash if you leave it alone for five minutes, is an invaluable milestone to reach. –  Nov 20 '10 at 15:51
  • if the initial project planning starts, as indicated in the question, it means that the go for the project has already been given thus it has ALREADY been sold to the customer. So... if there is no "prototyping" and that costs in hours is taken into this WBS then there is no prototpying in place. Ideally you would want this to take place before even selling the solution. So before one or more projects role out of it. So long before that project you want to put "prototyping" as part of the hours needed and some evaluation. This is hard with most customers since they want a solution. – edelwater Nov 21 '10 at 13:59
  • en dan willen ze ook nog de exacte server specs van te voren.... – edelwater Nov 21 '10 at 14:08
6

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.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • I've done a lot of the same things you've mentioned here and it has worked very well for me. To the best of my knowledge the client's I've worked with have been very satisfied with what I delivered because I generally exceeded the expectations they had. They also really appreciated the communication of how things were progressing and when there were problems what they were and the impact. – Ken Henderson Nov 22 '10 at 02:19
2

"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)

edelwater
  • 544
  • 2
  • 7