I'm not worried about your little-picture situation (the overlapping buffers). It's pretty clear that there's nothing deficient about .Net that would prevent this project from being successful if it's done using .Net rather than the consultants' preferred Java. Do you agree? But the big-picture situation seems really scary to me.
The people who are talking to you about doing this project are trying to convince you to select them, and their chosen technology, by giving you biased estimates and helping your management fixate on minor technical details. (I can't help but give away what I think is their identity, or at least their "affiliation", later on.) You need to bring in someone else to estimate the .Net cost, and you need to ask the Java people for a firm, fixed-price quote and see what their reaction is. If they say that can't work fixed-price, ask them how you can trust their estimates. I'm a consultant myself. I absolutely hate giving fixed-price quotes. I tell the client that I have to at least double the cost that I think the project would be, as I'm being asked to take on 100% of the risk that what needs to be done isn't what we think it is as we begin. It's stupid to work with a fixed-price contract in place, because you're almost certain to get into a situation where you and the client both agree that doing "what's in the contract" is very bad, but it's necessary for you to do it that way or some adjustment to the contract needs to be made. "Some adjustment to the contract" means lawyers, money, and wasted time and money. It's stupid to get into a situation where it's not in everyone's best interest for things to be non-confrontational with the project definition flexible based on what's been learned as the work goes on. The problem is that you're unlikely to get a "big consultancy" to actually behave as if it's in _their_ best interest to finish the project more quickly and at a lower cost. They make their money by putting bodies in your building at $N/hr and paying them 40% (or less) of N/hr. If they succeed in putting people in your building for 2 years, they make more money than if it takes 1 year. It's not their fault that they work that way; that's the way their business works. If it's the case that you -- who I surmise works for the company with this set of legacy systems -- are currently the "someone else" trying to talk about doing the work with .Net, you've got a problem. Your management seems to have proven by their behavior (insisting that this one technical point has to be addressed before a .Net-based solution can even be considered) that they don't think your opinion means as much as the opinion of the big consultants with the Cobol-to-Java tools and the 3-letter name (starts with I and ends with M). You need to find another set of credible consultants to pitch the other side. It couldn't hurt to call the MS salespeople in your area and tell them the situation; they'll happily provide people with good credentials who will make estimates that say doing it with .Net will be cheaper, and they might work hard to help some .Net consultancy in your area get the project by making the same kind of (empty) promises that the Java people are making. What you want to have happen is to find some consultants who honestly believe that it's in their best interest to help you get this work done as fast as possible, at the lowest possible cost to you, using the technology that they best understand. They would be thinking that they want to do all the projects your company will ever need, and that if they get a(nother) "client for life" they'll be fine with having left some money on the table when doing your first project. They'll sleep soundly at night, knowing that they're not being evil. The big boys are happy to get that one contract, never finish the project, generate a threatened lawsuit (that they wouldn't lose, because of the way the contract was written, and your lawyers will spend a lot of time and money figuring that out so you won't actually go ahead with the suit), and end up with a "client" that would never imagine working with them again and will bad-mouth them at every turn. And the client doesn't have a working system at the end. (If you need any real-world examples of this, read the business pages.) If you can find people who will be on your side, you're way ahead. If people who can actually run and succeed in a project like this work for your company, that's ideal -- but few companies have such people; they're rare birds, and they could make more money being entrepreneurial (unless your company recognizes their worth by paying them way more than is typical -- not likely). If you manage to find consultants who will be on your side, you will be much better off in the long run. The real issues on a project like this have nothing at all to do with technology! Good luck. At 12:12 AM 11/17/2006, Jon Rothlander wrote (in part) >Let me back up and see if I understand you correctly. What you are saying >is that you can implement this in a good or bad way. Either way it will >work. But why implement the bad option if you can just as easily implement >the good? Is that what you are saying? > >Let me see if I am following what you are saying in regards to the code. >[snip] J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
