When I arrived, we spent six weeks finding out what challenges lay ahead, where we would have problems and on their solutions...
Turned out that zero of what we did during that time was useful.
Problem was, we did not know what we did not know. Sounds like a redundant statement but it's not. IOW we did not know where the holes in our knowledge was. We did not know web services enough to realise that we were going to have problems interfacing via web services between dotnet and Websphere. We did not know hibernate enough to know that using inheritance and putting sub types into collection was going to be problematic. We did not know that we would have to work very hard figuring out the issues with JNDI and session beans.
We wasted a lot of time because of this. We should have got someone in, not to help us with the problems, but simply to tell us where the problems were going to be. We had the ability to solve the problems, we proved that as we solved them, what we didn't have was the knowledge to know where the problems were going to be.
1 comment:
I agree getting someone in to point out obvious (to them) obstacles would be first prize. But how do you find that person? I don't know anyone personally that has done .net to websphere via webservices.
If you can't find anyone - why not just start... when you have the issue then deal with it. So often on projects the idea is to do a Proof Of Concept (POC). But if the POC is too simple then does it actually prove anything? And if its too complex, it will take time, and then shouldn't you rather have just started working and found the issues along the way?
I don't think theres a "silver bullet" answer here, but people want to cater for all problems right in the beginning of projects - we should try and just start - I'm betting the times won't differ all that much.
Post a Comment