At 10:47 AM 11/14/2006, Jon Rothlander wrote (in part) >So in my opinion the client would simply choose Java over .Net since .Net >cannot handle this.
There have been multiple solutions to the specific problem of maintaining a buffer with 3 separate sections that can be addressed as a single section when desired. From what perspective could anyone say ".Net cannot handle this"? What you've heard more of is that people who use .Net don't want to be involved in building a system that repeats the design decisions made 35 years ago when big mainframes had 64k of memory. We've learned how to build better (more flexible) systems during that time, and you don't do it by duplicating questionable decisions. The data is on disk/tape in the format you've specified. There is almost certainly nothing in the spec for the project that says it can't be in a different format when it's in memory -- only that the program has to be able to read and write the old formats. If the people making a decision about what technology to use don't understand that, they have no business making decisions like this. >The estimates that we are coming up with are about $20M to rewrite and about >$300K to $600K to migrate the code in Java. [...] No matter how many points we >give them in regards to how .Net compares to Java, the price tag along [sic] >will kill it. I'm willing to wager that the people estimating $300K to $600K for a conversion to Java would not be willing to write a _fixed-price_ contract to deliver the system for $700K. They are estimating a lower price for the solution they prefer to use, and estimating a ridiculous price to deliver the solution using a technology that they do not want (or know that they're not qualified) to use. They know that if they get the contract, it won't matter to them how much more time or how much more money it will cost than what they said -- it's not their money, and it's not their business that will fail if the project is 2 years late. They know that they want to get the contract -- the client will not abandon the project after half the time has gone by and $200K has been given to them. They will keep billing the client for the time it's taking, and won't even be embarrassed if there's no evidence at that point that there's any hope of having the project completed on time for $600K. They'll tell the client "that's the way software development is, it's hard; no one really knows; it was just an estimate; the contract says we bill you for the time our people spend; we're doing the best we can, we just didn't know all the problems we'd encounter; blah blah blah." Projects of this size are always at risk of failing. Anyone who says that the technology you choose is going to make or break the project is full of it. It matters more how the project is managed, how the decisions as to what really needs to be done (and in what order) are made, and whether the people who do the key parts of the project are idiots or gurus. If the people offering to do the work have no track record of delivering huge projects on time and on budget, why should anyone believe that they can do it just because they said they can? (Should I and a few of my really bright programmer friends bid on this? We'd be willing to promise anyone anything for $300k, provided we can bill for any extra time it actually takes <g>.) If the decision is being made on the basis of this one technical issue, and not on the track record of the people who will do the work, something is seriously wrong with the decision-making process. 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
