ie8 fix
madison

Enterprise software is crappy and it isn't going to change any time soon

By | December 10, 2007, 5:50am PST

Summary: What started off as Bill Gates wondering why Enterprise software can’t get some blogosphere love and attention has turned in to a raging debate on why Enterprise software sucks.  First Robert Scoble chimes in and asks why enterprise software isn’t sexy, then Michael Krigsman says Scoble doesn’t understand enterprise software, then Nick Carr says Krigsman [...]

What started off as Bill Gates wondering why Enterprise software can’t get some blogosphere love and attention has turned in to a raging debate on why Enterprise software sucks.  First Robert Scoble chimes in and asks why enterprise software isn’t sexy, then Michael Krigsman says Scoble doesn’t understand enterprise software, then Nick Carr says Krigsman is the one not understanding, and then it goes back and forth.

Of course everyone is generalizing here since “enterprise software” is a huge category of software that encompasses many things and many aspects so there’s probably a lot of talking past each other going on.  This is a classic case of the more technically oriented Krigsman giving perfectly good reasons for the state of enterprise software and the user oriented Scoble and Carr saying I don’t care why it sucks just fix the damn thing.

These are all valid points but it’s kind of like asking why business computers don’t come in rainbow colors like the iMac and why the business suit is so boring.  So now I’m going to chime in on this discussion based on my experiences on the front lines of IT.

  • Enterprise software generally has lower usability and more bugs than commercial software.  That’s sort of counter intuitive to the word “enterprise” but the name is a joke in IT circles since enterprise software is typically painful.
  • Enterprise software is designed for and sold to IT departments so the expectation is that you have trained people supporting the software whereas commercial off-the-shelf software has to more or less be self explanatory.  Enterprise isn’t sold to the end user and the end user doesn’t sign the check so their considerations are secondary to enterprise software makers.
  • Enterprise software requires a lot more interaction between multiple systems which makes it fundamentally more complex to develop, deploy, and support.
  • Enterprise software also typically addresses a much smaller user base than off-the-shelf software like Microsoft Office so the development budget to user ratio is smaller.  This means programming shortcuts like Java are often taken which makes the software horrendously bloated and inefficient.  You’re not going to see enterprise software developed in light-weight C++ like MS Office any time soon because that level of skill is too rare and difficult and expensive to acquire.

There are exceptions to the above rule for major ECommerce sites.  Those sites are basically purchase/payment transaction systems that only require a simple web interface that doesn’t really require business-specific customization.  The back-ends are very complex but they’re hidden to the user.  The front-end user interface must generate minimal support issues or it wouldn’t even fly since there’s no feasible way to support a million users.  Even though ECommerce is a form of enterprise software, it’s a completely different animal than something like SAP or Siebel.

But when you add up the number of users between the various businesses using a enterprise software, it’s substantial so it’s perfectly reasonable to ask why it needs to be so bloated, buggy, and hard-to-use.  I think part of the reason this is the case is because there isn’t enough light (media coverage) on the shortcomings of enterprise software.  If all the dirty laundry was aired more frequently like all of Microsoft’s shortcomings which are few by comparison, enterprise software vendors would be forced to spend more money on quality.

But Robert Scoble hit the nail on the head when he explained that enterprise software stories don’t bring in the CPMs (ad revenue from one thousand page views) because the general public has little interest in enterprise software.  So at the end of the day they’re all right in their own way but not much is going to change.  The users will continue to complain that the software is too complex, the IT guys will sometimes complain but bear and grin it because it’s job security, and the enterprise software will continue to sell because it more or less works and there’s a massive sales force to propagate it.  Is that too cynical?  Probably but it’s unfortunately true.

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Disclosure

George Ou

http://blogs.zdnet.com/Ou/?page_id=557

Biography

George Ou

George Ou, a former ZDNet blogger, is an IT consultant specializing in Servers, Microsoft, Cisco, Switches, Routers, Firewalls, IDS, VPN, Wireless LAN, Security, and IT infrastructure and architecture.

118
Comments

Join the conversation!

Just In

Why do you keep saying "Desktop" in an Enterprise thread?
SourceFly 27th Dec 2007
So you are insisting that Enterprise software includes the desktop? SAP Gui represents how much of the SAP stack? Or are you saying that Office is Enterprise software in the same way as SCM or CRM software is?

Sorry but my "George Ou Secret Decoder Ring" has gone missing.
0 Votes
+ -
terminology
Erik Engbrecht 10th Dec 2007
A lot of enterprise software *is* commercial-off-the-shelf software, or at least COTS with customizations.

You're really talking about shrink-wrapped software vs enterprise software.

But other than that, a much more sane analysis than what others have said.

Iterestingly, none of them have really addressed the question of why people don't blog more about enterprise software. They're just running with Scoble's idea that it is because it isn't sexy.

I think there are other reasons.

http://erikengbrecht.blogspot.com/2007/12/why-isnt-enterprise-software-sexy.html
Actually, scoble was right to blame lack of coverage on lack of CPM. When you write about enterprise software, the eyeballs and thus the $$$ doesn't come.
0 Votes
+ -
CPM versus sexy
Erik Engbrecht 10th Dec 2007
He's asserting (or proposing) that it has a bad CPM because it isn't sexy, and that there is a lack of coverage because there's no money in it.

But there's a lot of good information in blogs that people write "for fun" or for "professional development" as opposed to earning money. Honestly I think there is more solid, useful information lurking in unpaid blogs. Paid blogs tend to focus too much on generating controversy and too little on content.

If CPM were the primary problem then I think you'd see a lot more unpaid bloggers talking about enterprise software, but a lack of paid bloggers. That would indicate that there is an insufficient market.

But the situation is that blogs on the specifics of enterprise software are almost entirely missing.

There are a lot of people working in enterprise software. There should be at least a couple people making a little side money from AdSense by blogging about the enterprise applications that they support. Or consultants trying to build up a reputation. But it's simply not there.
0 Votes
+ -
Or, that they're all very busy.
Absolutely 16th Dec 2007
If CPM were the primary problem then I think you'd see a lot more unpaid bloggers talking about enterprise software, but a lack of paid bloggers. That would indicate that there is an insufficient market.

But the situation is that blogs on the specifics of enterprise software are almost entirely missing.

There are a lot of people working in enterprise software. There should be at least a couple people making a little side money from AdSense by blogging about the enterprise applications that they support. Or consultants trying to build up a reputation. But it's simply not there.


The work to do is on customizing those monoliths to interact with existing systems, work that varies too much to support blog-style discussion. Also, there are very few potential customers for those products, so an open forum would be irrelevant. The makers of enterprise software can get all the customer feedback they want on the golf course.
Also, perhaps I should have said "shrink wrap" software rather than "off-the-shelf".
0 Votes
+ -
Close enough.
Absolutely 16th Dec 2007
He was able to guess at your meaning, correctly.
All enterprise software is based on SQL-DBMSs.

The main performance issues are in the SQL-DBMS and sending data over the network, not in the application programs.

Java is part of the problem in that many Java programmers assume that code will run faster if you take all the data out of the database first and then run cursors against the result. Nothing could be further from the truth.

In general, the nearer the "processing" is to the data, the faster the performance; cursors, and in particular client side cursors (and in this context an application server is a client) are murderous to performance.

I would say a lot of the performance problems in enterprise software arise from excessive use of procedural languages like Java (and C++ for that matter) against data structures that are fundamentally declarative in nature.
0 Votes
+ -
Java is the front end bloat
georgeou 10th Dec 2007
Java is the front end bloat and it is a programming shortcut in the sense the developer doesn't have to write as much code.

As for database performance, it's actually not the network or the application. It's usually disk IO performance that's the biggest bottle neck.
Oracle Applications is mainly Forms and PL/SQL.

SAP is ABAP.

Forms generates Java, to be sure, but this is using Java in the correct way; as a systems programming language. Java is wholly unsuitable for commercial application development.

Writing application code in pure Java is only a tiny step forward from C++ in terms of productivity (though the end result will be more reliable).
0 Votes
+ -
Speaking of Oracle...
JCitizen 11th Dec 2007
I don't mean this to come across as a rant-just as input to the discussion. George and others say there seems to be a lack of feedback from customers of these kinds of software; so here goes.

I didn't actually work with Oracle at Eaton Corp., because I was on the G code end of industrial production. In one major incident we completely lost 500 factory orders on the Oracle database and it was totally unrecovered disaster. The end users at that plant never did seem to get a grip on how to effectively implement that supposedly powerfull data base.

I think it put us behind on production on more than one occasion. Do you think this is more or less a side effect of the complicated science of "just on time" logistics in manufacturing?
0 Votes
+ -
There are an awful lot of J2EE business applications out there now, and increasingly the underlying middleware software is being written in Java.
However my comment was rather to be around C++: whilst it might have merits in good application being leaner and faster, one thing it absolutely does not guarantee is that your enterprise software will be any less crappy ! A good C++ coder will write great code, but most coder are around average, and average C++ code is not good !
0 Votes
+ -
There is no way that writing the application in C++ would make the DBMS write to disk any faster.
0 Votes
+ -
Again, I'm talking about the frontend
georgeou 10th Dec 2007
Again, I'm talking about the frontend. When I say bloated java applications, I'm talking about the frontend. When I talk about slim software, I'm talking about uTorrent http://blogs.zdnet.com/Ou/?p=153.

Nobody writes a an enterprise DBMS in Java anyways so I don't know why you would even debate this.
0 Votes
+ -
I would question
jorwell 10th Dec 2007
Whether application specific client software is needed at all for ERPs.

However, I don't want to give too much of the game away at this stage, you'll have to work it out for yourself.
0 Votes
+ -
George is on drugs again...
bmerc 11th Dec 2007
Contradicting himself left and right in his own talkbacks, changing his definitions on the fly so as to always avoid being wrong, and generally jacking up the English language and inductive reasoning in the process.

First he complains about enterprise software. Then he says Java is to blame for it being bloated. Then he says Java is irrelevant, and it's all about disk IO. Then he says by "Enterprise" he really means some sort of desktop client application, which is of course, utterly trivial when one is talking about ENTERPRISE software, that runs on big iron.

When people call him out on his stupid shenanigans, he just changes the story as fast as he can.

George is a master of using deliberately ambiguous language so that when someone rightfully calls him out on his ignorance, he can simply shift the definitions a bit and claim that's what he meant all along.

Congratulations George on yet another column filled with random gibberish and links to other people's blogs who actually know how to write. Perhaps you should skip the whole "writing" part and just post links.
0 Votes
+ -
Contradicting himself left and right in his own talkbacks, changing his definitions on the fly so as to always avoid being wrong, and generally jacking up the English language and inductive reasoning in the process.

I've noticed a distinct pattern among you and the other George Ou-haters; overuse of generalization.

First he complains about enterprise software. Then he says Java is to blame for it being bloated. Then he says Java is irrelevant, and it's all about disk IO. Then he says by "Enterprise" he really means some sort of desktop client application, which is of course, utterly trivial when one is talking about ENTERPRISE software, that runs on big iron.

He did comment on some of those topics, but he did so with much greater care to the context of his remarks than you haters.
0 Votes
+ -
C++ has other issues too..
ja4509 11th Dec 2007
Ever seen a blue screen or had a memory segmention error? Hanging pointers and memory leaks are a bit of a problem with C++. I admit that if you are an experienced developer these are minimal but they drive up the cost in enterprise software and when the systems typically change a lot for new business rule accomadation a solution like Java is somewhat more attractive. And the overhead is not that visible to the user.
0 Votes
+ -
Java has other issues too..
PMDubuc 11th Dec 2007
These aren't issues with any programming language they are issues with the care and experience of programmers. Java doesn't help at all. It used to be a simple language. Now it's gotten much more bloated and complex. All the hype about Java has turned out to be hot air. Meanwhile C++ hasn't stood still. It's gotten much better over the last 10 years. Java isn't just a language, it's a programming application environment that has theoretical portability and programmer efficiency (writing less code) over C++ but also has performance and "lowest common denominator" programming issues that C++ application frameworks deal with much more readily. Java is an example of trying to do software development on the cheap. I heard one very well know Java expert call it "the next Visual Basic". It turns out not to be so cheap in the longer run.
0 Votes
+ -
The problem is not with
alaniane@... 11th Dec 2007
the language itself, but how it is used. IMO it's a mistake to think that you can have one silver bullet language to cover everything. The old way of having languages developed for specific areas of application is better. Cobol was developed for business apps and Fortran for scientific. Java and .Net is useful for writing code that is portable across platforms. C/C++ are good for writing high performance apps where speed is more important than cross-platform portability. PL/SQL or T-SQL are excellent languages for performing database operations.
Cobol is excellent for transactional and batch processing.

The problem comes in where programmers try to use the same language to do everything. It often leads to bloated and inefficient code simply because the language was not designed to do what they are using it for.
0 Votes
+ -
You sir...
ego.sum.stig@... 12th Dec 2007
Are a scholar and a gentleman. I'd doff my cap to you (if I owned a cap).
0 Votes
+ -
Java is not bloat
alaniane@... 11th Dec 2007
in of itself. However, when programmers only understand Java or C/C++ and have no idea how to leverage SQL, you get poorly written database apps. SQL has been optimized to perform database operations efficiently; however, I have seen many database apps that use SQL for little more than returning the entire table and then the summarization is done in the app itself. Also, cursors are used far more frequently than necessary. Cursors fail to make efficient use of the indexing in databases. Basically, a cursor is little more than a loop through the entire dataset.

Also, the slowest component in the hardware is the network cable. When you transfer large amount of data from the backend to the frontend for processing, you are going to get a slow app. Another problem with many Enterprise apps is that they are still treating RDBMS as filesystem databases. It's not the matter of just Normalization versus Denormalization; it's also the matter of lack of relational integrity. Our Enterprise accounting software is a good example of this. A lot of work went into the frontend app and making it look nice; however, the backend database is a mess. The design is absolutely horrid. There is little to no relational integrity and trying to pull data from the tables for custom reports is crapshoot. Some of the queries, I have had to write contain lengthy case statements to take the data out of horizontal format and then convert it to vertical format so that it could summarized. So instead of just writing:
SELECT SUM(sales) FROM tblProducts WHERE year = 2007
I have to write
SELECT SUM(jan + feb + mar +...+dec) WHERE year = 2007

For SUM its not too bad; however, when you need to Average the data, you have to go through loops trying eliminate the extra zeros.
0 Votes
+ -
Proof?
mejohnsn 11th Dec 2007
I'l love to see some numbers, such as profiling results, to back up the claims that:

1)Disk I/O performance is the "biggest bottle neck" and
2)"Jave is the front end bloat".

After all, twenty years ago, it was considered pretty normal for a relatively sophisticated app to be I/O bound (this usually means disk I/O), but nowadays, I see a lot of apps that are _compute_ bound, whether the app is 'enterprise' or 'consumer'.

This of course, raises another question: is database performance really where the bottleneck is? And where it is the bottleneck, if it is spending too much time doing disk I/O, that often means a poor algorithm is being used, _not_ that one needs to optimize disk I/O.

In general, Java turns out to be "the front end bloat" only if it is poorly written Java. After all Sun really has made great strides in the efficiency of their JVM recently. Although still not competitive with _well-written_ C++ for speed and efficiency, it is at least easy to get into the same ballpark now.
0 Votes
+ -
The real problem with Java
jorwell 12th Dec 2007
Is not with the language but with the "philosophy" behind it.

We have been told for almost 20 years now that people think "naturally" in terms of objects and methods.

I often ask for people to point me to the presumably substantial amount of experimental psychological evidence that supports this, frankly rather dubious, hypothesis, but no one has ever been able to do that.

On the basis of my own experience (which is of course only anecdotal and not scientific) I can state that in more than 20 years of talking to users I have never witnessed any business user express requirements spontaneously in terms of classes and methods. If this is how people think "naturally" then you would expect to encounter people talking in these terms all the time, yes?

On this basis I would put forward the proposition that OO is computer wishful thinking rather than computer science.
0 Votes
+ -
Wrong.
raggi 12th Dec 2007
" As for database performance, it's actually not the network or the application. It's usually disk IO performance that's the biggest bottle neck. "

No.
Bad SQL and bad design is. Then IO is blamed.
Ask any seasoned DBA.
0 Votes
+ -
I'lll have to disagree on some points
tombalablomba 10th Dec 2007
Enterprise software is designed for and sold to IT departments so the expectation is that you have trained people supporting the software whereas commercial off-the-shelf software has to more or less be self explanatory. Enterprise isn?t sold to the end user and the end user doesn?t sign the check so their considerations are secondary to enterprise software makers.

In all my years with enterprise software have I yet to meet an IT department that has bought enterprise software like SAP. This has always been a decision made by the business. In most cases the IT department is a bystander which has had marginal input into the decision..

Enterprise software also typically addresses a much smaller user base than off-the-shelf software like Microsoft Office so the development budget to user ratio is smaller. This means programming shortcuts like Java are often taken which makes the software horrendously bloated and inefficient. You?re not going to see enterprise software developed in light-weight C++ like MS Office any time soon because that level of skill is too rare and difficult and expensive to acquire.

The biggest one (SAP) is mostly written in C, reason for most of them to write in Java is not a shortcut but because they need the software to run on as much OS's as possible. None of the big players in the enterprise has focussed on one platform solely...

Budgetwise i think that players like SAP and Oracle are having much larger budgets dedicated to development than the Office division, as the software is way more complex and functional than MS office.
0 Votes
+ -
"The biggest one (SAP) is mostly written in C, reason for most of them to write in Java is not a shortcut but because they need the software to run on as much OS's as possible. None of the big players in the enterprise has focussed on one platform solely..."

Ironically, they don't really need multi-platform since almost all the customers ONLY run their business software on Windows.
0 Votes
+ -
Strange then
tombalablomba 10th Dec 2007
That of all the ERP implementations I have seen, none of them have been running on Windows on the server side.....

That most businesses run it on the client side on windows is a given, but in most of these environments the client side isn't the interesting part as it doesn't have a lot of functionality.

Most of the big players are actually moving into browser access as this makes a lot more sense. (deployment is a lot easier..)
I have never seen the back-end on a Microsoft Server. :P

I'm sure they're out there but most high-end ERP's demand Unix or some form of it.
0 Votes
+ -
Not quite
jorwell 10th Dec 2007
I've seen a world-wide SAP implementation done on Windows, so it can be done, but I would agree that the majority have the "back end" software on Unix.
0 Votes
+ -
Never said it wasn't..
ju1ce 10th Dec 2007
If you look.. I know they do have Windows implementations, but by far in my experience doing ERP implementations I've always went from Unix to Unix or some flavour.

Never have done an install on a Windows Server although I know they exist.
0 Votes
+ -
I'm not talking about server side
georgeou 10th Dec 2007
I'm not talking about server side; I'm talking about the client side. Yes it's true that ERP often runs on Solaris systems ESPECIALLY if you're talking about Oracle. However, there are still plenty of Windows systems running MSSQL server. I've also seen plenty of SAP backends running on Windows and MSSQL for very large deployments. But on the desktop/frontend side, it's almost ALWAYS Windows.
0 Votes
+ -
The Oracle client
jorwell 10th Dec 2007
being generated Java, can run on any platform with the JVM (but I have never seen it in the wild on any platform other than Windows.)

The trend is towards web front ends and away from Windows, but it will take a while.
0 Votes
+ -
Yup agreed.
ju1ce 10th Dec 2007
The company I currently work for is looking at Deltek Vision as our ERP which is completely web based. Which will also be on a Windows Server.

The only issue with web based software is they will still use proprietary solutions. Alot of them will still gravitate towards IE Active X only solutions which will still lead them to a Windows environment.
0 Votes
+ -
I think you can stay open
jorwell 10th Dec 2007
But you need to think very carefully about what actually needs to be done on the client and how you derive the user interface rather than having to program it (and the consequent improvement in reliability and maintainability that comes with this approach).

I don't see any need for ActiveX to do business software.
0 Votes
+ -
This isn't correct
jorwell 10th Dec 2007
SAP is mainly written in ABAP, SAP's proprietary language.

SAP runs on a wide variety of systems, including IBM mainframes, Unix and Windows and is also DBMS cross platform (Oracle, DB2, MS SQL Server).

I believe the majority of Oracle Applications implementations are on Unix.
0 Votes
+ -
The topic being discussed by Carr and Scoble is the frontend. This is why Carr referenced the web UI.
0 Votes
+ -
Not entirely accurate
SourceFly 27th Dec 2007
SAP applications are written in ABAP, but I think the the pre-Netweaver paltforms are written in C. The Netweaver stack is predominantly Java-based to make support on a broader range of platforms easier.
0 Votes
+ -
Funny George
mrOSX 10th Dec 2007
Since I have worked for Several Big Enterprises, Most of the business processing goes on the mainframe, and from what I remember it does not run Windows, it will run Linux happy
0 Votes
+ -
Only on Windows?
TheBoyBailey 10th Dec 2007
I cannot comment on SAP, but as an Oracle Applications consultant it as been a long, long time since I've seen implemented on a Windows Server, maybe the last time being late 2003? Ever since then its been Solaris or Linux Red Hat.

George, if your experience of ERP software comes from running it on Windows only, you cant really chime in on this Enterprise Software debate and expect to be taken seriously.

Timbo.
0 Votes
+ -
Agreed, Green Screen or Fail
nucrash 10th Dec 2007
Green Screen has been around for years for a reason. Not because it doesn't work, but quite the opposite. When you had more bell and whistles, you only add confusion.
I'm talking about the desktop side being dominated by Windows in the enterprise. Yes, Oracle on the backend is almost universally on Solaris. I knew the guy that headed the Oracle developer user group and to them it was inconceivable to run Oracle on Windows. However, I have known very large SAP implementations to be based on Windows Server 2003 running MSSQL server.
0 Votes
+ -
Green Screen IBM 5250 Emulation on a Windows Desktop. Stripped down it runs extremely fast. No problems what so ever as long as nothing graphical is needed, why put it in place.
0 Votes
+ -
So C++ software is not bloated....
alf@... 11th Dec 2007
That's interesting, because before reading your comment, I'd have thought that "bloat" and "MS office" (Open Office too) were almost equivalent.

Cheers.
I'm talking about resource bloat, as in memory and CPU consumption. MS Office feature bloat doesn't worry me especially when the features are presented well in the new UI. I look at it as a buffet where I might only eat 10% of the offerings and someone else might eat 10% of the other offerings.
0 Votes
+ -
Few things on my box are as resource hungry (or leak memory) as the MSOFFICE beasts. Or have the same disk footprint.

Or start "search optimization thingies" that freeze my box when they optimiza and play hide and seek with me 'till I find where they are and kill them (the office indexing whatever - that was some time ago, but still). I could go on.
0 Votes
+ -
Bloated code...
dwain.erhart@... 11th Dec 2007
Try this... write the "hello world" code in C. Compile and link it using Visual C# (from MS) and then use some cheap generic compiler (Miracle C or something) and notice the difference in the size of the executables. In some code, Visual bloats the exact same executable by a factor of 10. When I tried a simple program to check on size - a little printf coded "hello world" to stdout; it took those few lines of code and bloated it to 5 times the size in an executable - the one on the C compiler was less than 1/5 the size of the executable using the Visual studio product!!!
As some people here have stated, a front end need not be complex or bloated in order to display data, offer data entry, etc. Users want a tool to access and enter data efficiently and easily. They are not looking at the complexities of the product, rather, they are focusing on getting their respective work done in a timely, organized, and less frustrating manner. When I observe the intense training some of these administrative personnel have to go through in order to run a simple query, I am shocked and disappointed at the level of complexity in the software here where I am employed. (I am also thankful I do not have to use it on a daily basis) Yes it runs on a Windows front end, and it is using an Oracle back end on a Unix platform.
One point I make here is that tight code practices are rather meager efforts if the compiler and linker bloat the results this much.
As George rightly points out - it also looks bad if an office like software that is basically slapped on a desktop as a matter of routine appeals to our users more than our expensive enterprise software does.
They (the users) are the ones who look at us askance and wonder if we have lost our marbles. This super expensive software is (in their eyes) junk, compared to the stuff that came bundled with their computer (they think).
0 Votes
+ -
Microsoft Office never used Visual C++ which includes a lot of bloated libraries. They use a stripped down library. Remember that MS Office was created in the days when computers ran on Windows 3.0/3.1 with 4 to 16 MBs of RAM so it had to be extremely lean. I remember having 64MB Windows XP systems that ran MS Office 2000 just fine.
0 Votes
+ -
If you really want to strip out
alaniane@... 11th Dec 2007
bloat then take that same Hello World program and write it using Assembly.I did a comparison one time using the old Borland compiler version 5.0 (before Builder)
C came to around 20K using printf
C++ about 35K using cout
Assembly to 512 bytes.

However, code bloat is usually not the result of the language used, but the code the programmer writes. Too much code I have seen is written without a basic understanding of the underlying systems. If the programmer only knows how to use a high-level language without understanding the architecture he is designing on, he's going to write inefficient code.
0 Votes
+ -
What software do you use at work?
notsofast 13th Dec 2007
I work with billing software from a 3rd party that you've likely never heard of and the problems we have with it DWARF any problems I've ever had with virtually any commercial software from ANY company, including Microsoft.

These problems are not just on Windows. Several back-end parts of this software have to be restarted every few days (if not every day) or processing becomes slower than my dog (and he died 3 years ago).

Is MS software perfect? Nope. I find outlook 200x frequently performs poorly (whether this is the client or exchange, i don't know). OTOH, the rest seems to work fairly well...and I love office 2007 though I only use it at home.

All in all, what George is saying rings true to me...even if this software is running on Solaris.
So you are insisting that Enterprise software includes the desktop? SAP Gui represents how much of the SAP stack? Or are you saying that Office is Enterprise software in the same way as SCM or CRM software is?

Sorry but my "George Ou Secret Decoder Ring" has gone missing.

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix
Click Here
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix