Microsoft .Net software's hidden cost

Yahoo ^ | Sat Jun 22,11:11 AM ET | Joe Wilcox

[discostu]

Of course he's also ignoring the fact that the second ime you write a program is always easier because you've solved the logic already. That's to be expected though, he's also chopped your estimate in half. That's how things go on these threads.

[Dominic Harr]

Ever hear of training expenses? Learning curves?

In my experience, trying to pay a vendor like MS instead of paying for training and in-house expertise will burn you every time.

As I said, in my experience there are better, cheaper solutions available that will involve less risk and fewer unknown product defects (which are *ceratinly* in .NET right now). MS has burned you already. Ya'll don't know it, because you don't know the alternatives.

IIS isn't "free", nor is SQLServer. I wouldn't use stored procedures for data input, I would seperate that logic out into code (it will run faster, and won't be a 'single-db' lockin).

I'm always amazed that MS's sales pitch of "use our solutions, you don't even have to be an expert to use them!"

Yes, you do. Or else you pay for it in the end, every time. If you're paying MS instead of developing your own tech expertise in-house, you will get burned. You'll pay more, and end up beholden to that single vendor. You have to use IIS (which is *very* inferior). And SQLServer, which is adequate but far over-priced (even compared to Oracle, because Oracle is a better far, far better DB as far as scalability is concerned).

Don't get me wrong. Java is not for everything. It is slightly slower to execute, so if you've got a flight-sim or something that has to number-crunch a million policies overnight, then use either C++ or Cobol on a mainframe.

But for web work, it is absolutely the very best, cheapest, fastest technology going. You are paying more for the MS solutions, and you're getting an inferior product. If you're "MS-Only", you might consider doing an analysis of non-MS techs and see if you really want to stick with the single vendor lockin.

Just a suggestion.

[Dominic Harr]

That's to be expected though, he's also chopped your estimate in half.

I was being generous, in fact.

If the ASP code just has a web form that takes parms and then kicks off an SP, then spits out links to the screen, it likely would have taken me less than a day to do.

Assuming he wasn't too experienced with Java, I allowed a week.

That's pretty basic functionality.

I've written a similar reporting system here at CSC, for our HR dept and 'Program Office'.

I have to pull data from the 'MARS', 'RequisitionRequest', 'PIC' and 'Status' dbs in Lotus Domino, the Oracle db that accounting uses and the 'Hawk' SQLServer db to build reports.

The front-end is an applet, so it can do full data validation. The middle-tier is a servlet (we call it 'SQLServlet') that takes SQL calls and routes them to the correct DB, then builds the report data before returning the data to the applet -- which then formats and allows them to print the data.

.NET can *not* do that.

[discostu]

You weren't being generous, you were being rude. He said he thinks it would take 2 weeks to rewrite the program in Java. Now you may or may not know Java better than he does, but I'm damn sure he knows the program better than you do. Either you believe him or you don't. If you don't believe him then you should ignore the entire post. If you do believe him then you should take his estimate at face value and work with that.

[Dominic Harr]

If you do believe him then you should take his estimate at face value and work with that.

If he isn't very familiar with Java, then his estimate at how long it would take in Java is suspect.

I have a lot of recent experience building *exactly* that type of tool, and I would think that *my* estimate might be a little more accurate.

But who knows? I could be wrong. I'm just giving you my best guess. You disagree with pretty much anything I say anyway, so I imagine that this discussion is moot?

[discostu]

But you know neither his java skill nor much about the program. His thumbnail outline hardly gave any indication of the depth of the program or complexity. So again lacking any knowledge to the contrary the only polite thing to do is accept is estimate as given.

[Mr. Jeeves]

I wouldn't use stored procedures for data input, I would seperate that logic out into code (it will run faster, and won't be a 'single-db' lockin).

Please. There is no way that database statements embedded in code (which make programs harder to maintain, BTW - since you have to touch your code every time there is a database change) will run faster than compiled stored procedures.

But that's all beside the point. You just have a grudge against Microsoft, and I'm not going to help you indulge it any more this morning.

Ciao...

[Dominic Harr]

His thumbnail outline hardly gave any indication of the depth of the program or complexity.

He completely described the app.

Ah, well. You disagree with me. I can live with that.

[Dominic Harr]

There is no way that database statements embedded in code (which make programs harder to maintain, BTW - since you have to touch your code every time there is a database change) will run faster than compiled stored procedures.

I once thought so too. But test it side by side.

And now that I've looked into it, it makes perfect sense.

A DB is not optimized for number-crunching. It's only optiimized for data storage and retrieval.

As you know, there are a hundred ways you can code the number-crunching part of report building. You often have to try it a half-dozen different ways to get the best performance. The DB will not do this.

Having the DB "build" a report is going to be slower than having a programming language build the report. The SP will have to build temporary tables, and the like, and that stuff is *slooooow*.

Try it. Try just doing simple SQL calls and bringing back the raw data as much as possible, and then building the report yourself. If you're MS-only, try C#.

And you do *not* have to touch the code when the db changes -- unless they change the names of fields, which would also disable the SPs.

In fact, you have a much *easier* time both writing and maintaining the code if it's in a language other than SQL.

Programming a complex report in SQL is a nightmare, compared to Java or C#.

And then there's the portability thing -- with SPs you're going to have a major problem migrating to other DBs. And with your architecture, if you have to add into that report some data that comes from another DB you're dead in the water, and need an entire re-write. That architecture will not scale.

I'm sorry you're closing your mind to non-MS solutions. I suppose if you work for an MS-only shop then that's sort of where you started, so I guess that's why you see me as just someone with an axe to grind.

Oh, well, good luck on your work.

[CLRGuy]

>>.NET can *not* do that.

Actually it can.

There's a little thing called a winform that I can deploy on my webserver, if you browse to it it will download itself and all of its dependencies. From my wiform I can use web-services or remoting to get all my data. Winform does everything your applet does and more.

Glad you're still living in fantasy land Harr... I'm living in the real world doing all that stuff you're telling me I can't.

[Dominic Harr]

Actually it can.

Hello again.

We've been thru this. Even Bush2k has admitted that there is no .NET equivilant of an applet. Web Forms are *not* even close. But whatever.

Altho I'll ask you, since I can't get any details from anyone else --

I'm looking for a success story of .NET deployment similar to the one I just posted.

You must know of at least one successful .NET implementation of a major production system?

[Bush2000]

Upon further discussion, it turned out he could have done it better, faster and cheaper in Java

A. It would have taken him longer.
B. It would have been more costly.
C. There's no proof that it would have been any more scalable or robust under Java.

[CLRGuy]

Did I say Web Form? Nope I said Winform, there's a HUGE difference.

Admitedly webforms are just html and javascript.

Winforms are fully functional independent rich client applications.

And yes I know of several large scale applications currently being implemented on the .NET platform. I've worked on a few that have been mentioned earlier in this thread.

I know of several others, but because of my position and the company I work for it would be imprudent, and unprofessional in the fourum to mention them by name. I'm sure as a professional you can understand that.

[Bush2000]

Please. There is no way that database statements embedded in code (which make programs harder to maintain, BTW - since you have to touch your code every time there is a database change) will run faster than compiled stored procedures.

Don't waste your time with Harr: It's obvious that he doesn't know what he's talking about. As you've correctly pointed out, stored procedures are faster precisely because they're precompiled and the SQL engine doesn't have to build a query plan -- it's done in advance, at the time you add the stored proc to the database. Likewise, stored procs are not susceptible to SQL injection attacks because all of the incoming data is considered literal and not part of the query semantics.

[Bush2000]

Welcome to reality, Harr...

.NET Zero Deployment: Security and Versioning Models in the Windows Forms Engine Help You Create and Deploy Smart Clients

[Dominic Harr]

I know of several others, but because of my position and the company I work for it would be imprudent, and unprofessional in the fourum to mention them by name.

Actually, a developer would be encouraged to share their opinions and experiences with new technologies, especially one like this that is trying to gain acceptance.

I talk openly here about the projects I work on, and give as much detail as you'd like. My company loves that, in that it means I'm out here learning 'best practices' and exchanging and gaining knowledge. All the developers I know are the same. We *talk* about what we build.

In my experience, only a salesman would claim to know about great things they won't talk about.

And -- I thought that the 'WinForms' I read about didn't run in the browser, but had to be downloaded to the client and ran locally as a local application. Very, very different technology, more akin to a java application without the 'Java Web Start'. Am I mistaken?

[PatrioticAmerican]

" people specifically paid "

"Paid"? Microsoft PAYS Partners??? I want my check!

[Dominic Harr]

Yeah, exactly, thanks for that link.

The 'Windows Forms' are more akin to the 'Java Web Start' tech. Downloading an app that executes locally on the client as a local app.

Very, very different from an Applet executing only in a browser, with no ability to affect the local machine.

[Dominic Harr]

As you've correctly pointed out, stored procedures are faster precisely because they're precompiled and the SQL engine doesn't have to build a query plan -- it's done in advance, at the time you add the stored proc to the database.

You've never done any DB work, so you probably don't realize that the delay is the actual processing of the data. The DB has to build temporary tables and does all the number crunching in a very, very inefficient manner, processing data relationally.

In an language like C# or Java, you do number crunching in an OO manner, optimized to the specific report to be churned.

For any complex report, the DB will be the absolute slowest way to number crunch possible.

[PatrioticAmerican]

"ASP, even ASP.NET, doesn't scale very well."

Where is your proof?

Harr, listen, guy, you make such accusations and then claim that "everybody knows it", but Microsoft and millions of people have the benefit of success. Plus, I don't know it, and after 20+ years developing systems, and 23 years using Microsoft products and technologies, I totally disagree with you, so I guess it is "everyone but PatrioticAmerican"?

If Java is the only thing going that works, why are there so many people benefiting from Microsoft products and technologies?