Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

The bloated, dysfunctional world of Enterprise Solutions

By thasmudyan in Technology
Tue Jan 27, 2004 at 12:40:30 AM EST
Tags: Software (all tags)

What the hell happened to the "best tool for the job" policy? Does the industry really have the money to invest in bloated projects, implemented with non-productive technologies that are just not right for the job at hand? I think not. Why then, does it happen? My theory it has to do with the magic slogan "Enterprise Solution".

PHBs love to buy things with the "industrial strength architecture" label on it. Hordes of young programmers are being indoctrinated at universities to use only the "cleanly designed, pure" languages because they are so well suited for teaching abstract CS concepts. It's almost as if nobody notices how little actually is being achieved at such a high price in software.

Fellow developers, make no mistake, I'm about to attack your favourite technologies now, read on if you dare - or if you had the feeling you have been "coding in the Matrix" lately (like the famous ad said).

"Java beats the crap out of .NET any time" I hear a colleague scream across the dinner table to a group of arrogant C# Jedis. Interesting. Let's have a closer look behind the scenes. Have a bit of patience and follow me while we explore some of my company's project management folders together:

Wow, I think by myself, maybe Java is the hot productive technology of the future! Let's have a look at the time tables for some of the Java projects at my company, then! Alright, what do we have here, a relatively simple web application for example. Hm, deadline slipped six times already, stability problems, 300% over budget, cannot get simple things to work properly, over 10000 lines of code in utility classes alone just to get a few bytes from a database? I actually took time to compare projects like these with equivalent PHP projects, and not a single one of them had those problems. In fact, the PHP projects produced consistently better solutions faster with more features.

And what do we have here? Novell Portal Services - "the industrial grade portal solution for all your enterprise needs"? Sounds solid, all right. Let's open the project management folder to have a closer look. I see: stability problems, deadline was 18 MONTHS ago, 200% over budget, thousands of lines of bad code to get plugins to work but failed anyway, total database crashes in the staging area, severe security problems - and all that for a portal project with almost no more features than a static website? Hm.

Ahh, there, an Oracle project! The leading database company, mind you. Says right on the box that it saves you tons of money in development and operations! OK, just why are the developers still trying to get this project to work, 3 months after the project should have gone gold? I asked them. Problems with reading data from BLOBs, setup problems required specialists to constantly tweak the config, features hard to use. There is a team working on a MySQL solution right next door, I asked them, and they just laughed at those problems! They were happily implementing features, while the Oracle team was still trying to figure out how to even get basic things done.

But wait! PHP is not a real programming language. MySQL is not a real database, right? I just read the MySQL tweaking article here at K5 and the comments were all like "fuck MySQL, use Oracle/PostgreSQL". Righteous bashing. Maybe those are not "real" technologies, but if I can actually get the job done with them, I'd use them regardless of their image problems. OK, let's close the corporate project folder now and get some questions out there that just beg to be answered.

Why is it so freaking hard to just create working software with "Enterprise Solutions"? I'm beginning to suspect that maybe the main reason why enterprise grade software is so expensive is not because of features and stability (the gods know those are marketing myths anyway) but because actually implementing stuff with it is nearly impossible.

Why is the industry willingly wasting so much money? The conspiracy theorist in me begins to wonder if there is a purpose to it, a purpose that comes from keeping prices high, dominating people and technology by putting software out there that requires large training programs so developers can get basic things to work. I mean, look at those companies behind the examples above: Sun, Novell, Oracle. Don't they have something to gain from making their solutions hard and slow to use?

Why are most developers part of this? There are many reasons for this. First, no one gets fire for using IBM^H^H^H Java. Second, we're being fed these technologies from the start (school, uni). Also, our managers love those consultant people who tell them to migrate to ...a Novell-only shop, for example. And peer pressure constantly reminds us that there is something very wrong with us if we're beginning to wonder why our company purchased that ridiculous ATG server in the first place.

I think the industry needs to wake up. Is Java the wrong tool for everything? No, sure not, but there is a whole buttload of things you better don't touch with Java. Yes, technologies like PHP and MySQL lend themselves to being used even by lesser programmer-wannabe kids - but maybe it's time to think about why 90% of the professional world denies itself the benefits in productivity that the hobby sector has been enjoying for years now.

I know that many developers feel the same way about those over-designed solutions that do nothing but eat time and money and keep the development costs up. Ask yourself why you have that "wow-cool" moment when you finally succeeded in serializing and unserializing an object in C# when the PHP geek next to you simply did it with one lousy method call and moved on to other things 3 hours ago!


(to the tune of Rage Against the Machine)

And yes, I know that this is an invitation to righteous flamewars. As long as it reaches one other geek our there who feels the same way, this was worth it.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Also by thasmudyan

Display: Sort:
The bloated, dysfunctional world of Enterprise Solutions | 145 comments (118 topical, 27 editorial, 2 hidden)
Attn troll ahead. (1.72 / 11) (#1)
by tkatchev on Sun Jan 25, 2004 at 12:15:59 PM EST

The bloated, dysfunctional world of Open Source?

Please sombody please please kill X11 already.

Also, WTH is the Gnu Hello World implementation a 380 kilobyte archive? What is the world coming to?

   -- Signed, Lev Andropoff, cosmonaut.

Not about that (2.25 / 4) (#2)
by thasmudyan on Sun Jan 25, 2004 at 12:27:15 PM EST

This was not meant to be about closed vs. open source products. X11 belongs right up there, I agree. Also, Perl is not a programming language, it's a religion. The list can be endless. I chose to write about 3 examples to make some sort of point.
Oh, well.

[ Parent ]
I know. (none / 1) (#18)
by tkatchev on Sun Jan 25, 2004 at 04:27:52 PM EST

That's why I honestly warned that I was trolling.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

GNU Hello (2.00 / 4) (#8)
by grouse on Sun Jan 25, 2004 at 01:04:51 PM EST

I've always thought that GNU Hello was an elaborate joke. Some people have too much time on their hands.

You sad bastard!

"Grouse please don't take this the wrong way... To be quite frank, you are throwing my inner Chi out of its harmonious balance with nature." -- Tex Bigballs
[ Parent ]

Sadly, no. (none / 2) (#19)
by tkatchev on Sun Jan 25, 2004 at 04:28:56 PM EST

It appears that these very serious people lack a sense of humour.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Would you know humor (none / 3) (#26)
by Djinh on Sun Jan 25, 2004 at 05:39:00 PM EST

if it bit you in the ass?

We are the Euro. Resistance is futile. All your dollars will be assimilated.
[ Parent ]
read what's at the end of that link! (none / 1) (#29)
by jnana on Sun Jan 25, 2004 at 07:04:08 PM EST

Yes, this really is the classic program that prints "Hello, world!" when you run it. Unlike the elementary version often presented in books like K&R, GNU hello processes its argument list to modify its behavior, supports internationalization, and includes a mail reader. The primary purpose of this program is to demonstrate how to write other programs that do these things; it serves as a model for all of the GNU coding standards.

[ Parent ]
WTF was wrong with that comment, drduck (none / 1) (#44)
by grouse on Mon Jan 26, 2004 at 04:39:17 AM EST

Quit modbombing me.

You sad bastard!

"Grouse please don't take this the wrong way... To be quite frank, you are throwing my inner Chi out of its harmonious balance with nature." -- Tex Bigballs
[ Parent ]

Don't be a dick, Ivan. (none / 2) (#27)
by it certainly is on Sun Jan 25, 2004 at 06:08:31 PM EST

GNU Hello is not intended as a very bloated way to print Hello World messages. It's meant to be a coherent example to developers of how to write software that uses the GNU autoconf and automake tools, and how to localise their software.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Yes. (none / 1) (#41)
by tkatchev on Mon Jan 26, 2004 at 04:26:14 AM EST

Which was exactly my point.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

P.S. (none / 1) (#42)
by tkatchev on Mon Jan 26, 2004 at 04:28:19 AM EST

Things like configuration and localisation should just work automatically by default.

Otherwise, your OS/runtime/library is severly broken.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

They do. (none / 2) (#49)
by it certainly is on Mon Jan 26, 2004 at 07:13:22 AM EST

Each OS vendor has their own fully functional configuration and localisation system, each one completely different from the other. This is why it's useless for multi-platform software, and a generic solution that works on the lowest common denominator is needed. But you knew that.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Yes. (none / 1) (#61)
by tkatchev on Mon Jan 26, 2004 at 11:17:10 AM EST

I'm just raving because of my irrational hate for Unix.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

This is a stupid article (2.00 / 19) (#3)
by zipper on Sun Jan 25, 2004 at 12:27:48 PM EST

You're not attacking the technologies, you're attacking idiot managers/developers without the common sense to use the right tool for the job.

Comparing MySQL to Oracle is like comparing apples to oranges. Sure, they're both vaguely similar, but they're different animals. Blanket statements like "TECHNOLOGY X IS TEH SUCK, YOU SHOULD ALWAYS USE TECHNOLOGY Y" are absurd generalizations.


This account has been neutered by rusty and can no longer rate or post comments. Way to go fearless leader!
No (2.16 / 6) (#5)
by thasmudyan on Sun Jan 25, 2004 at 12:33:05 PM EST


Just where exactly did I say something about that? This is not PHP advocacy. I was just trying to do a comparison. Oh, I'm so sorry that your favourity technology didn't fare to well.

Just tell me how I can get the message across without refering to some specific technologies? I'm not suggesting that everyone moves to PHP or something, I was just wondering why Java projects were so bad in comparison. Then again, maybe our company is located in Bizarroworld where everything is just the other way around???

[ Parent ]

...and you started off so well. (none / 3) (#13)
by zipper on Sun Jan 25, 2004 at 02:30:34 PM EST

Java projects are 'so bad in comparison' because they're clearly not the appropriate tool for the job. The companies that I've worked for have all been intelligent enough to choose the proper solution to the problem, so hey, it's quite possible you're located in 'Bizarroworld'.

This account has been neutered by rusty and can no longer rate or post comments. Way to go fearless leader!
[ Parent ]
Heh (2.14 / 7) (#7)
by regeya on Sun Jan 25, 2004 at 12:53:23 PM EST

I'm still waiting for corporate IT to send the copy of Retrospect they promised; in the meantime, I'm doing incremental file transfers from one harddrive to another via psync, which boasts lower overhead than Retrospect.

I don't know why the industry wants to waste money, either; my own limited experience tells me that bosses like something they can get an invoice for and pull out of a box.

[ yokelpunk | kuro5hin diary ]

It's not that. (none / 3) (#43)
by tkatchev on Mon Jan 26, 2004 at 04:36:19 AM EST

Basically, I think bosses like solutions that outsource responsibility.

You feel much safer when there is a huge, multi-national company you can fall back on and blame.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

more about attitude than tech (2.80 / 20) (#11)
by speek on Sun Jan 25, 2004 at 01:33:34 PM EST

I'm of the opinion that what you're seeing is more the result of certain attitudes than about tech choices. There are some teams that just get things done, often without designing carefully, doing one-offs, sloppy code that deoesn't separate concerns, etc. Such programmers are often viewed by their managers as really good workers that they can depend on. These people finish the work requested of them ahead of time. You ask for it, they do it. Period.

Other teams/people are more methodical. When you ask for something, they start thinking ahead and come back with lots of questions about stuff you haven't considered. They have code reviews. They write object-oriented "well-designed" code. They document their work. They're slow, behind schedule, and over-budget.

So guess what? The former tend to like PHP and Perl; the latter Java, Oracle, and XML.

These are incrediblely gross generalizations, but I think what you're seeing is the difference between a team focused on getting the job done, and a team over-focused on getting the job done right, with quality processes and such. I think one can combine the former attitude with technologies like Java and Oracle - but it's hard. However, the benefits can be startling too. You can also combine it the other way. It's just rarer.

I'm all in favor of more agile development of software - I think people often focus on the long-term to the detriment of the short term, thinking their doing quality work, when actually they're wasting time. I also happen to really like - enjoy - making highly structured code (generally using Java), that let's me add new stuff easily. That joy is just an aspect of my personality, just like my preference for getting the job done without over-emphasizing "quality" is an aspect of my personality. These two aspects are often in conflict, and the only way I know of reconcile them well is to reverse the usual scope of the two. Ie, I try to make my big picture attitude one of "just do it", while allowing myself the pleasure of good design on smaller scales - shorter time frames and small sections of code.

But, now I'm rambling. I would just like to see this discussion to morph from one about tech choices, to one about development process choices - regardless of what you think about my preferences. Because that's what I think this rant is really about.

al queda is kicking themsleves for not knowing about the levees

Culture of self-perpetuating overengineering (2.76 / 17) (#15)
by Hatamoto on Sun Jan 25, 2004 at 03:14:57 PM EST

As others have already pointed out, the problems are largely the result of a broken way of thinking, although it does originate from a solid basis.

Back in the day, when computer science and engineering was a new and rapidly growing field, everyone just basically hacked away at things. Huge edifices of terrible code resulted (take a look at any circa 1970s banking system written in COBOL and you'll see what I mean). These systems worked, but were unmaintainable, ugly, and often deliberately obfuscated by the hacker-tyrants who lorded over their domains jealously.

Today's 'best practices' are largely a result of corporations losing their tyrants (due to death, downsizing, whatever) and finding that their systems were nearly un-maintainable and had to be replaced. They need code that can be worked on by anyone who's been sufficiently indoctrinated by the scholastic system, so that programmers and maintainers can be swapped in and out like every other part of thier company. The practices used are there to facilitate coder interchangability, and thus there's a lot of over-engineering.

The upshot of it all is that code gets bloated and ugly as a direct result of companies wanting to treat their coder-peons as disposable. Of course, throw-away people are going to generate throw-away code in many cases.

That being said, if you're someone coming into a scenario where you have to maintain some mad haxx0rz code, you end up really really really wishing they were forced into using strongly typed languages and so forth. A company I'm contracting to right now has an extensive codebase of mod_perl/mason constructs which are damn near indecypherable... the woman who made them was brilliant, but didn't comment for shit and opted for power/flexibility over comprehension in her design. It's taken a couple months of serious codebase sifting to suss it all out, and even still there's "voodoo" spots that people avoid for fear of breaking the whole damn thing.

Me, personally, would say "just rewrite the important bits in php and fuck that bloated mod_perl bullshit" (my god, mod_perl is a *huge* pig of resources), but it's hard to convince the chequesigners that their $100k+ perl development dollars would be better left to rot, even if it does mean throwing good money after bad to bring it up to maintainable levels.

"Innocence is no defense." - Federal District Judge William H. Yohn (People v. Mumia Abu-Jamal)

Well (2.00 / 5) (#84)
by CaptainZapp on Tue Jan 27, 2004 at 05:14:18 AM EST

and often deliberately obfuscated by the hacker-tyrants who lorded over their domains jealously.

I for one welcome the new overlords of obfuscated hacker-tyrants

[ Parent ]

heh (n/t) (none / 3) (#107)
by Hatamoto on Tue Jan 27, 2004 at 08:00:49 PM EST

n/t: No tyrant!

"Innocence is no defense." - Federal District Judge William H. Yohn (People v. Mumia Abu-Jamal)
[ Parent ]
static/dynamic, strong/weak typing (n/t) (none / 1) (#145)
by ksandstr on Sun Feb 29, 2004 at 09:13:30 AM EST

[ Parent ]
Nice rant (1.00 / 10) (#17)
by wiredog on Sun Jan 25, 2004 at 03:33:36 PM EST

+1, fp

Wilford Brimley scares my chickens.
Phil the Canuck

if you don't like it... (2.14 / 21) (#20)
by reklaw on Sun Jan 25, 2004 at 04:36:23 PM EST

... then go and start your own software company. You can be the director and the manager, and you'll have a clue instead of opting for these stupid "enterprise solutions". In this way you can save tons of money and undercut your larger competitors.

If you're too scared to do that then quit whining, bend over and keep taking it from your corporate masters.

Not a sustainable business model (none / 3) (#111)
by greenrd on Tue Jan 27, 2004 at 09:54:07 PM EST

Economics dictates that eventually everyone will get a clue and you'll lose that key advantage you had over your competitors - a clue.

However, economics seems to have failed in this instance. Better arrest those responsible then... they're surely breaking a law of economics.

However, it must all be temporary, anyway. Economics will eventually win in the end, as k5's resident free market zealots continue to assure us.

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

people are the problem, not the technology (3.00 / 13) (#21)
by Mindcrym on Sun Jan 25, 2004 at 04:36:23 PM EST

At the last place I worked we were using Resin and Oracle to create an intranet site for our company. We never delivered anything on time and the code was a big ball of mud. We weren't taking advantage of things like EJB/CMP that were available to us in Resin. Oh, no. Our lead engineer was more interested in creating his own job security so he created incredibly bloated pieces of software to handle low level things like object persistence and logging, two things that just about evey other piece of software in the entire company were written on top of. Of course, he appointed himself to maintain these pieces of software, which he never documented or subjected to peer review.
  Our management was sufficiently clueless so they didn't see what was going on. This developer was effictively running the show and wasting enormous amounts of company resources by doing so. I tried to bring this to the attention of our management and all it got me was inclusion in the next round of layoffs.
  I've been doing contract work for the past couple of years using Resin and Postgres on a public website. We're taking full advantage of EJB and CMP and it is really working out well for us. I started this project from scratch so I guess that makes me the architect. If I see something we're doing that's too bloated we toss it out.
  I think the reason the author is seeing Java projects take longer and go so far over budget is largely due to the misconception that enterprise software should be extremely complex and expensive. Oracle charges so much for their products and services because they can. Large companies have just become accustomed to paying too much money for too little in return. As a result I think this also attracts expensive, non-productive people who see a way to make lots of money without working very hard.
  Just my $0.02.

PHBs think bigger is better (2.93 / 15) (#24)
by swr on Sun Jan 25, 2004 at 05:07:44 PM EST

I think there is a "bigger is better" attitude among PHBs. I've seen this applied to hardware too. "That box in the corner has ample horsepower for this kind of thing" "What? Are you sure? What if the company gets really big? Let's get a quad Xeon with RAID-5!"

Small projects need to make themselves look big in order to be taken seriously by management. This can cause small projects to actually become big projects, in a very dysfunctional way. Instead of projects being right-sized they are inflated in an effort to justify their existence.

Most projects are (read: ought to be) small projects.

I prefer PHP for small projects, Java for medium/large projects. I find Java encourages added structure that is essential for medium/large projects, but just gets in the way for small projects.

What about Ada 95? (2.85 / 7) (#63)
by bsavoie on Mon Jan 26, 2004 at 11:52:57 AM EST

Maybe I am just an old gray hair. Yes, I know, Ada 95 was a government sponsored project, but it was designed for very large projects. This all seems like trying to use Basic (or Java, or another interpreter) to do something it was not designed to do. (Just because one person can code a GUI does not mean that all the different threads that must be managed will work correctly.) Ada 95 is open source, and I have used it on projects that have 300 computers networked together, running millions of lines of code, and every byte was analyzed for correctness. (Star wars simulations) If you want a GUI with Ada use Glade and GTK to produce portable code that will run in any environment. Yes I know I am wasting my breath, but it is still the truth, even if no one is listening.

Bill Savoie
May Peace and Love be your path
[ Parent ]
I know, this might sound rediculous (3.00 / 4) (#86)
by CaptainZapp on Tue Jan 27, 2004 at 05:26:38 AM EST

The only major project I ever worked in, which got finished within time, scope and budget was implemented in Ada under OpenVMS with a Sybase SQL Server as the backend.

The system is still in production 9 years later - The database backend moved to ASE on TruUnix (or whatever the hell they call it this week), though - and hits 8 million bookings on a mediocre day (each consisting of ~ 8 TPC/C transactions), and some 20 million on a good years end processing.

So I for one certainly don't doubt the qualities of Ada with it's drawbacks:

It seems quite hard to find qualified people and if you want a good laugh then send your database vendor a reproducible example in Ada after hitting a snag :)

[ Parent ]

Indeed (none / 1) (#93)
by myshka on Tue Jan 27, 2004 at 10:30:19 AM EST

Perhaps universities should employ Ada 95 as the first or even the principal language of instruction? It's mostly well designed and supports a lot of the concepts one looks for in a modern compiled language.

It seems quite hard to find qualified people [in Ada]

Equally hard is finding a non defense-related company that understands the benefits of using Ada.

[ Parent ]

Java is misused but it is fine for webapps (2.83 / 12) (#34)
by MSBob on Sun Jan 25, 2004 at 11:00:23 PM EST

Java is horribly misused in many organizations because people tend to learn java the language without learning the supporting frameworks and frequently end up reinventing the wheel. Your very example points to this problem. Anyone writing their own database code in Java should be fired on the spot. That is what Hibernate has been invented for. There is no excuses for messing with JDBC connections and resultsets yourself. Hibernate does all you'd ever want out of a persistence layer and more.

For building the user interfaces I pick Struts from Jakarta. Another wonderful product from the Jakarta team. The only trick with struts is that you have to be really well versed in it to use it effectively. Most struts applications I've seen so far are seriously underutilising that framework. I also pick Velocity from Jakarta for doing generating some content based on templates and It's all that 90% of so called enterprise applications ever need. Maybe throw in GLUE from MindElectric for a good measure when you need to talk SOAP with the outside world.

Java enterprise apps can be finished on time and within budget but you have to know what you're doing but that's true of any technology. Trouble is that even after the recent shakedown we still have many people around who shouldn't be working in this industry.

I don't mind paying taxes, they buy me civilization.

Here here! (none / 2) (#50)
by Milo Minderbender on Mon Jan 26, 2004 at 07:16:26 AM EST

What a lovely comment. I'd give you a 4 if I could.

I've been using Jakarta-Struts for three years now and I'm about to change to a job that doesn't mention struts on the requirements, and I'm a little apprehensive. Do people still use straight doPost() servlets? I can barely remember life before form beans.

Where I'm currently working, before I got here, they closely evaluated EJB's and the option of writing their own database tier, complete with transaction management, and the idiots made the decision to write their own database tier! If I never see another rs.next(), it'll be too soon.

This comment is for the good of the syndicate.
[ Parent ]
This is true.. (none / 3) (#81)
by ekj on Tue Jan 27, 2004 at 02:14:36 AM EST

But it also means that as a starting java-programmer you will, if you decide to do things rigth, spend 90% of your time not actually writing any code, but instead searching documentation for already existing frameworks for the wanted "CenterStringAndPrintInRed" function.

[ Parent ]

Which raises the question (none / 3) (#110)
by greenrd on Tue Jan 27, 2004 at 09:45:20 PM EST

So why aren't realistic programming assignments set more at universities - when there is actually the chance to sit down and learn how to code well?

(Don't do that in the first year, though. They'll be scared enough by having to write three moderately non-trivial classes between three people, trust me. I've tutored first years. No need to scare them any more than that.)

But university computer science education could do a great job of educating students about various Java frameworks, class libraries and technologies - how to use them, when they're applicable - and what they do under the hood, so you really understand what they're doing. That's exactly where theory can come in handy.

But what do they teach in the way of theory? In my (admittedly limited experience): Relational operators, assembly language and the nitty-gritty of bottom-up parsing. All very low-level. And if you're lucky, maybe a bit of complexity analysis (rarely enough so that students actually understand it though), and a bit of informal waffle about program design (no design patterns though). So some high-level stuff, but not much. Not much at all. Certainly nothing really on choosing between real-world technologies like Struts or Cocoon.

Theory that's actually relevant to the Jakarta and J2EE and object persistence technologies that people will be using when they leave university, would be a lot more useful to the vast majority of people. Maybe keep some of that stuff, but don't focus on those old-school things exclusively.

You may say the old-school stuff is more generally applicable and the hip stuff will date quickly. I say rubbish. When was the last time the typical programmer implemented a bottom-up parser? When was the last time a typical Java programmer used J2EE technologies - probably badly? I think my point is made.

And if you get to understand a moderately complex, moderately well-designed, object-based free software project quite well - other than operating systems, which are taught anyway at universities and are quite uniform at the text-mode programming level, all things considered - far from being quickly dated knowledge, that can become a source of wisdom on things like software architecture, design patterns etc. which doesn't date so fast. If taught well, with an eye to deep understanding not rote learning, that is - and tailored to the aptitudes of the students so that they can grok it from where they're coming from.

Of course, where are you going to find that in a university CS department these days?

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Software Engineering vs Computer Science (none / 2) (#122)
by Will Sargent on Wed Jan 28, 2004 at 07:19:55 PM EST

The relationship between Software Engineering and CS is about the same as the relationship between Civil Engineering and Physics.  You can't have Engineers running around without a good understanding of the basic principles, but it doesn't make any sense to have a physicist explain how to build a bridge.  

There is actually a Masters of Software Engineering at the University of Washington, and I think Software Engineering as a field is becoming more distinctly defined.  Books like Design Patterns, and the whole bloggy thing about refactoring and unit tests makes a point of managing code, as opposed to just illuminating the concepts.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

Bang on.... (none / 3) (#94)
by JohnnyCannuk on Tue Jan 27, 2004 at 10:59:17 AM EST

You got it.

I've become very disappointed in the EJB part of J2EE (the rest is quite good) and I agree with everything you've said.

What a lot of the whiner's on this list forget is it's not so much the language or even the platform, but how you use them.

I can write a peppy, simply, scaleable app in Java using the JSP/Servlet Struts webapp part, asynchronous messaging using JMS, persistance using JDBC (inside Hibernate/OJB/Castor of course) and scale/failover it using Jini and Javaspaces. Use Axis for any "Web Services" stuff.

A poor programmer or beginner in the field seems to think J2EE==EJB and then proceeds to use all of the parts of the spec incorrectly and using poor code. And when things go south, they blame the platform...remember, a poor worker blames his tools.

I suspect in the example the author gave, those teams would have been overbudget and behind schedule even if they had been using PHP, or PERL, or what ever other language/platform the anti-${favorite "Enterprise Framework" here} zealots trot out.

But I guess its easier for the workers to blame Java for their technical shortcomings and Project Managers to blame Java for their inability to manage a project team or a client...
We have just religion enough to make us hate, but not enough to make us love one another - Jonathan Swift
[ Parent ]

I feel old (2.80 / 10) (#35)
by JayGarner on Sun Jan 25, 2004 at 11:07:25 PM EST

Early in my career, Java was the hip new gee-wiz thing everybody wanted to do but almost nobody could get into due to corporate inertia. That and the web-crap, of course, but everybody figured out pretty quick that any monkey can do HTML, and soon every monkey was.

Now Java itself seems to have COBOL-ized, and with the help of J2EE, devolved into some stodgy corporate behemoth chock full of impressive sounding doo-hickery and more config files than a project put together by recent college grads who never talk to each other.

On the other hand, people still want the Java jobs, mainly because Java jobs are a subset of jobs.

Sacrilege (1.83 / 6) (#40)
by wji on Mon Jan 26, 2004 at 02:25:55 AM EST

The best technology is C. C++, Perl, Python, and the rest are decent as well. Screw enterprise solutions.

In conclusion, the Powerpuff Girls are a reactionary, pseudo-feminist enterprise.
C? (none / 3) (#48)
by tkatchev on Mon Jan 26, 2004 at 05:16:50 AM EST

U iz clown.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Nah (none / 1) (#79)
by kraant on Tue Jan 27, 2004 at 12:05:10 AM EST

C is great if you're working on your own without deadlines. It's portable, has an huge collection of third party libraries that do everything under the sun, and the base language is simple enough that it can be learnt in a day given a couple of decent tutorials and references.
"kraant, open source guru" -- tumeric
Never In Our Names...
[ Parent ]
If I have to choose a religion... (2.40 / 5) (#53)
by l3nz on Mon Jan 26, 2004 at 08:24:29 AM EST

I'll take Lisp. My hopes stand for a better future, not a glorified macro assembler.

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)
[ Parent ]

To be honest... (none / 1) (#62)
by tkatchev on Mon Jan 26, 2004 at 11:31:49 AM EST

The world really does need a good macro, platform-independent macro assembler.

Besides, Lisp is a bit outdated conceptually.

(When I win the lottery and retire before turning 30, I'll write a decent replacement for Lisp... Sigh...)

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

lisp outdated? (none / 1) (#80)
by donio on Tue Jan 27, 2004 at 02:10:40 AM EST

How so? Would you please point out one or two ways in which a modern
lisp dialect like Common Lisp is outdated compared to <your
programming language of choice>?

[ Parent ]
But that's the point. (none / 1) (#88)
by tkatchev on Tue Jan 27, 2004 at 07:06:09 AM EST

"Modern languages of choice" are even more conceptually outdated than Lisp, a language designed in the 1950's...

Anyways, what we really need are balanced b-trees instead of lists, and some inherrent support for SIMD. (On a conceptual level, I don't mean supporting MMX and 3dNow or whatnot.) Also, standard, simple, first-class object orientation and a standardised, compilable virtual machine.

And of course, lots of other goodies I can't think of now.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Indeed (2.66 / 6) (#47)
by Betcour on Mon Jan 26, 2004 at 04:59:51 AM EST

I've spent some time coding with Delphi in places where nobody had ever used it. I was fun watching the guys sweat for months with C++ while I had my work done in a handful of days with Delphi and the right components. The Delphi app looked better, had better ergonomics and fewer bugs too :)

Perl one-liners (3.00 / 4) (#52)
by l3nz on Mon Jan 26, 2004 at 08:22:39 AM EST

I remember when I impressed a large number of C and Visual Basic programmers writing Perl scripts that in five minutes of tweaking were often more powerful than the utilities they spent days programming....

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)
[ Parent ]

but... (none / 2) (#97)
by guinsu on Tue Jan 27, 2004 at 12:54:16 PM EST

The nice thing about Delphi was it was shorter, easier to write and ALSO was readable. Perl loses that contest hands down.

[ Parent ]
RTFM (2.33 / 6) (#54)
by duffbeer703 on Mon Jan 26, 2004 at 08:57:06 AM EST

Nearly all of the examples that you gave above were examples of semi-competent programmers and IT dorks futzing about with software that they do not know how to use.

If it takes anyone three months to create oracle config files for an application not yet in production, your "DBA" is a serious liability.

MySQL, Perl and other technologies are great for most projects. (Probaly like 80%) But in larger projects, they just don't scale.

This is just a rant - missed core issue (2.42 / 7) (#55)
by lukme on Mon Jan 26, 2004 at 09:17:32 AM EST

Core issue - why does software fail?

I bet in each case you cited, involving large teams that ran over budget, the real reason why they failed to meet the deadline was due to any number of reasons such as a missunderstanding of the minimum requrements for the project, a missunderstanding of the complexity of the project, or a dramatic change in the requirements.

In the projects that you seem to be talking of are selfcontained, and involve a limited number of people. Here there requirements are well know to all involved parties and the project is probably of limited scope.

Use the appropriate technology for the project.

It's awfully hard to fly with eagles when you're a turkey.
Jack of all trades. (2.90 / 10) (#56)
by OzJuggler on Mon Jan 26, 2004 at 09:21:07 AM EST

Well whoah there, steady on Silver!

I should probably disclose at the outset that I work at a mainly Java/Oracle house. :-) So I'm trying to keep my emotions under control as I respond to your flamebait.

We use Oracle mainly because we get it essentially for free under a larger enterprise licensing arrangement.

We use Java because... well someone had to make a decision back in 1999 about what our inhouse development platform would be. Micro$loth .NET was still vapourware at that time (or a marketecture as some say), and J2EE was already out at v1.2 and had the extra advantage of being free of Microsoft's stench, so I guess it was a no brainer for our Technical guru to make the call.
The lesson to be learned is that all these tech decisions get made at one point in time with a subset of requirements to be met and only certain information available. The most you can do is explore lots of options, clearly document the requirements and the rationale, and then get on with implementing it. Anyone can diss you about it later with hindsight, that's easy.

But one thing I do notice about these technologies is exactly the thing you're railing about. Scalability (or allegations thereof).

The PHBs don't want to have to support 10 different technologies, even 5 is maybe too many. They want a small number of techs which can be used on a project of any scale. You might argue that such a thing is impossible, and you're probably right. But you must admit that in a comparison of capability between PHP and Java that Java must be more favourable because no-one would ever dream of implementing complex behaviours in PHP with any degree of developmental efficiency and maintainability. So in this one specific comparison the PHB will pick Java because he gets to leverage skills more often and instead of having a lot of people who know two technologies, he employs less people who know just one.

This Jack-of-all-trades approach is not without the obvious criticisms of runtime performance and developmental overhead. But when it takes months just to get the customer to signoff on requirements, and then takes days or weeks to even design the darn thing properly, nobody is going to spot the difference between a 4-hour implementation and a 4-day implementation.

And then there's evil tools like CodeCharge which make language choice moot because it friggin' generates the code to do what you want (within many constraints of course).

The day I first saw CodeCharge in operation was probably like the first time the HTML coders saw FrontPage in operation back in `94. They knew their days of hand coding were numbered.

With Java it is already the case that I design new classes in a CASE tool and click "Generate" to make the skeleton of the class structure. If you specify requirements in behavioural terms then for most projects you're going to be generating over half of the code directly from the requirements document. That's scary for us coders. Damn!
"And I will not rest until every year families gather to spend December 25th together
at Osama's homo abortion pot and commie jizzporium." - Jon Stewart's gift to Bill O'Reilly, 7 Dec 2005.

hand-coding (3.00 / 7) (#60)
by F a l c o n on Mon Jan 26, 2004 at 10:58:11 AM EST

The day I first saw CodeCharge in operation was probably like the first time the HTML coders saw FrontPage in operation back in `94. They knew their days of hand coding were numbered.

And man were they wrong.

GUI HTML editors did one thing: They removed the clueless from the market of HTML writing, and into the market of clicking websites together.

It's 2004 now, 10 years later. Webpages are still being done by hand. The higher quality the website, the more likely it is that it was at least tweaked, if not entirely done, manually.

Ho, ho - don't hit reply yet. I know that we don't build websites anymore like we did in '94. The entire site is not coming out of vi anymore. Some CMS system is messing it up and spitting it out.
But look closer. More often than not, the individual pieces that are fed to the CMS are still made by hand.
Back in Beta (too many new features added): BattleMaster
[ Parent ]

Agreed. (none / 3) (#72)
by bigbtommy on Mon Jan 26, 2004 at 04:06:06 PM EST

Give me BBEdit or give me death.

Website development starts off in text editors, then authors think "Hey cool! $gui-based-tool will solve all my hand-coding woes."

And then about sixth months later they'll go back to text coding. Earlier if they are programming PHP or, shudder, ASP.

Others will become Flash-addicted dorks who will advocate the use of Flash to everybody and anybody around them (yes, the Flash zealot is intolerable).

All my PHP is done in BBEdit or pico or whatever crap they have running on my hosts ssh server these days.
-- bbCity.co.uk - When I see kids, I speed up
[ Parent ]

Pico :) (none / 2) (#87)
by trezor on Tue Jan 27, 2004 at 06:49:18 AM EST

At my shell that means Pico :)

And yes, I'll gladly do a site in pico than in any gui-based semi-intelligent shitpile anyday.

Richard Dean Anderson porn? - Now spread the news

[ Parent ]
It's RMS TIME, folks!! (none / 3) (#109)
by greenrd on Tue Jan 27, 2004 at 09:21:31 PM EST

Your friendly Free Software representative speaking. RMS can't be everywhere at once so I'm standing in.

pico is not Free Software. You can avoid supporting Un-Free Software by using GNU nano instead. As a bonus, it even has more features!! (Unusual in the Free Software world, I know...)

(I've been using it recently, and it doesn't seem to have many bugs.)

In future, apt-getting the stallman package will allow you to avoid these kinds of problems.

(No, that's not a joke. There really is such a package. Both nano and stallman are real programs.)

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Don't you mean vrms? (nt) (none / 1) (#144)
by ksandstr on Sun Feb 29, 2004 at 08:50:32 AM EST

[ Parent ]
Pico is neat (none / 2) (#118)
by bigbtommy on Wed Jan 28, 2004 at 03:14:12 PM EST

As is whatever RMS advocates in it's place.

Don't dismiss BBEdit too quick. The current version has a CLI tool which lets you create or open files or pipe stuff straight through to BBEdit, and you can execute shell script in it. It also has CVS support and a built in FTP client. Not too shabby for GUI. Especially if you combine it with LaunchBar.
-- bbCity.co.uk - When I see kids, I speed up
[ Parent ]

code generators (2.50 / 4) (#78)
by JyZude on Mon Jan 26, 2004 at 10:15:15 PM EST

I saw a demo of a really sweet code generator system for J2EE development, and it was actually pretty cool. You'd define a data object, and the program would write the DB schema, EJB home interface, EJB remote interface, EJB implementation, JDBC calls, etc. etc. It wrote about seven .java files. I was impressed.

After the meeting, though, I thought "why in Bog's name do you need seven classes for a single business object? Why isn't this repetitive logic in the language?" By the time I got back to my office, I had imagined a system in Python using metaclasses and other OO goodness whereby all of these parts could be generated on the fly at runtime (or initialization-time) using object introspection of a single Class object.

Java, in its quest to be "enterprise grade" is afraid of doing anything without at least seven classes to back it up, so that it's REALLY SURE it knows what you want.

k5 is not the new Adequacy k thnx bye

[ Parent ]
The problem with Java "Enterprise" stuff (none / 3) (#91)
by Simon Kinahan on Tue Jan 27, 2004 at 09:24:50 AM EST

... is that it really shows up the weaknesses in the language design. It doesn't have any kind of support for meta-programming at all: not even C++-style template evil. So when you want to do something like create objects and a DB schema based on some common specification, you can't do it in the language. Hence all the code-generation tools and ten megabyte XML files. But the trouble with generated code is that its hard to maintain, and the problem with massive XML files is, well, just existing.


If you disagree, post, don't moderate
[ Parent ]
1.5 is supposed to have metadata (none / 2) (#106)
by Will Sargent on Tue Jan 27, 2004 at 05:39:38 PM EST

Supposedly there's a metadata feature that can automatically do code generation for you in 1.5.  I haven't looked at the details.  And yes, there are templates/generics as well.

But you have to remember these weaknesses only show up because the state of the art has advanced so far -- back when Java was being compared to C++ and Visual Basic, no-one (besides the lisp and smalltalk freaks) would think you'd want metadata in the programming language.

FWIW, I don't consider the C preprocessor to be a metadata feature.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

Metadata, JDO, Generics (none / 2) (#108)
by greenrd on Tue Jan 27, 2004 at 09:14:19 PM EST

Supposedly there's a metadata feature that can automatically do code generation for you in 1.5.

There is - JSR-175 - but it can't do code generation for you. You have to do that yourself, or use runtime reflection.

However, it's pretty easy to parse and use.

I haven't looked at the details. And yes, there are templates/generics as well.

There are generics, but they're not as general as C++ templates. You can't, for example, write the equivalent of a Fibbonaci function in C++ templates, in Java with generics. I approve of that decision to make it simpler.

However, they do support wildcards ("<?>") and "<C extends ?>" style generics (I forget what that's called), which makes it a pretty powerful, flexible generic type system. Definitely more of a "clean, pure" type system than a code generator like C++'s "template engine" - although it's slightly dirty because of the next point: Everything has complete binary compatibility with existing code, of course (in the sense that e.g. you can use old code with the new Collection classes).

Now, add in Java Data Objects, and you have Java Data Modelling Nirvana.

I reimplemented part of JSR175 myself, and I'm using all of these technologies on a tech support database project now - and let me tell you, they are sweet.

One class for one domain model class. No extra classes. No code generation. No maintaining separate XML files. Just one class in one place for one domain model class. It sounds unimpressive, but it's not.

This is a future for Java object persistence (not the only future but certainly a future), and I intend to release the tools I've been creating to help me do this (such as Java Annotations Filter & Parser - JAFP).

These things are what I've been waiting for in Java for a long time.

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Metadata versus metaprogramming (none / 2) (#113)
by Simon Kinahan on Wed Jan 28, 2004 at 05:40:54 AM EST

In general metaprogramming techniques are those that allow programs to manipulate (or at least specify) other programs in a logically coherent way within the language. C++ templates are often used for metaprogramming, as are metaclasses in Smalltalk and Python. Lisp is essentially all about metaprogramming. C, as you rightly say, has no metaprogramming features.

I came to Java from a Smalltalk background, so I have a slightly different take on this to other people. Java was clearly intended not to scare people who came from a "blue collar" programming background, so it has no fancy-schmancy academic features - or at least, not on the surface. But since it is a VM-based language, these features would, for the most part, have been very simple to add. Since I knew the value of some of these things, that irritated me rather. Java is now getting some of the stuff it should have had to begin with, but in some areas (eg. the interaction between reflection and generics) the damage is probably irreparable.


If you disagree, post, don't moderate
[ Parent ]

you are missing an important point (2.93 / 16) (#58)
by circletimessquare on Mon Jan 26, 2004 at 10:24:12 AM EST

you are obviously a lively intelligent optimistic programmer

but you see, working for a corporation is a soul-sucking experience

the fundamental flaw in your analysis is that you are seeking happiness and sanity in your work

get back to us in a few years after you have had your spirit crushed

The tigers of wrath are wiser than the horses of instruction.

Just to add (2.40 / 5) (#66)
by atarola on Mon Jan 26, 2004 at 12:19:40 PM EST

Working in a .gov shop is just as bad :(

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"
-- John F. Woods
[ Parent ]
Truth (2.87 / 8) (#59)
by F a l c o n on Mon Jan 26, 2004 at 10:46:02 AM EST

I actually took time to compare projects like these with equivalent PHP projects, and not a single one of them had those problems. In fact, the PHP projects produced consistently better solutions faster with more features.

Oh yes.

I used to work for a dot.com. While the business model was flat, the technology rocked. We had a major DB application, half a million users, and it was all PHP. We had 4 machines (2 web-, 2 db-servers), plus the usual firewall, backup, etc. stuff.

I learned about the technology of our competitors when they bought us. They did essentially the same thing, if anything then less on the functionality side. They used "enterprise level" crap. Intershop, Oracle, hordes of programmers and high-level approaches.

You won't be surprised if I tell you they had ten times our hardware, and I'm not kidding.

But you'd expect that their code was easier to maintain and upgrade, better documented and structured.
On the contrary, their entire system was such a mess that they were about to create a special team just to sort that out.
Back in Beta (too many new features added): BattleMaster

Yes, but... (none / 2) (#89)
by dcheesi on Tue Jan 27, 2004 at 08:11:02 AM EST

...who ended up buying who?? :)

[ Parent ]
Its not just "enterprise software" (none / 2) (#96)
by guinsu on Tue Jan 27, 2004 at 12:51:16 PM EST

At my company we use ASP (JScript, no VBScript for me b/c the syntax drives me up a wall). And MS SQL Server. We have competitors who use ColdFusion and MySQL. They have 5 web servers, 4 database servers, 2 servers just for the forums... We have a web server and a database server.

I've found anyone using CF needs way more servers than a similar ASP, PHP whatever solution.

I've also realize MySQL just doesn't do what I want, that is why I use SQL Server. Stored procedures are a blessing, plus there are a few complicated SQL queries we run that probably would never fly in MySQL.

I love Java as a language, but it does make it hard to do simple things like connect to a database and go. Plus I do like IIS and nothing Java ever integrates as seemlessly as I'd like. I've messed with python a bit lately and like it, I'd also like to try Ruby and some of the newer languages that are made for web sites. I avoid perl like the plague.

[ Parent ]
My Sympathies (none / 3) (#100)
by hansel on Tue Jan 27, 2004 at 02:20:23 PM EST

Java suffers from spec bloat that makes people like you write it off because it's so fucking hard to find the easy way to do things.

It is easy to connect to a database and go; certainly as easy as ASP.  But I deeply sympathize with your frustration, because it took me a long time to stumble over the right javadoc to find out how.

[ Parent ]

WTF? (1.85 / 7) (#64)
by Run4YourLives on Mon Jan 26, 2004 at 11:54:27 AM EST

"No, sure not, but there is a whole buttload of things you better don't touch with Java."

Um, yeah, whatever.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown

It seems (2.00 / 7) (#65)
by srutis on Mon Jan 26, 2004 at 11:59:25 AM EST

that this Story is not so much about the technologies choosen, but about the company  thasmudyan is working at ...

This is so funny, (none / 2) (#70)
by thasmudyan on Mon Jan 26, 2004 at 01:32:15 PM EST

because we do a lot of contract work for other companies and I've seen what kind of horrible projects they have been doing themselves...
Maybe it's a European problem though or something like that.

[ Parent ]
-1, Wankery (2.70 / 17) (#67)
by Valdrax on Mon Jan 26, 2004 at 01:05:52 PM EST


"I'm a PHP programmer who hates Java, C#, and really probably any other object-oriented language.  I work with idiots who are all over-budget and behind schedule who all happen to be working with expensive, non-OSS tools.  I like to imply that there's a casual relation here, and not just a correlation.  They are inferior to me."

"I will now procede to get very defensive about the shortcomings about my own favored tools and dismiss their critics just like they dismiss me -- the nerve!  So-called "enterprise solutions" are all expensive, and figuring out how to use them is hard!  I like to think that anyone who uses them or buys them is selfish and short-sighted.  Once again, PHP rulez, C#/Java droolz!"

[Insert crappy rebel-rock reference here.]

"I blatantly admit that I posted this thread to start a flamewar.  If I've gathered fellow zealots to me, it was worth it."

1, Review of my own post. (2.77 / 9) (#68)
by Valdrax on Mon Jan 26, 2004 at 01:08:33 PM EST

"I'm bitterly irritated at people who think that their favored tools are always the best solution for everything and imply that they are smarter than everyone who doesn't use them, and yet I can't spell 'causal' correctly."

[ Parent ]
Actually (2.00 / 8) (#69)
by thasmudyan on Mon Jan 26, 2004 at 01:24:35 PM EST

Reading comments like yours also made it worth it. Because of people like you I get the reassurance that my assumptions can't be that wrong, after all ;)

First they laugh at you...

[ Parent ]

Stupid, stupid, stupid (2.87 / 8) (#98)
by hansel on Tue Jan 27, 2004 at 12:54:41 PM EST

No, your assumptions are wrong, and oblique comparisons between yourself and Ghandi don't make you more credible.

You correctly identified the (obvious) problem, and then completely mis-identified the cause, blaming Java, the language and platform, and "enterprise grade" applications as the cause, when it's obvious that the problem is your idiot coworkers.

I've written large web apps in PHP/MySQL, and you're right, it's easy and fast.  I've also done the same things in Java and MS SQL Server, and it's just as easy and fast.  10,000 LOC in utility classes is the sign of a fucked up design; there's nothing inherent in Java requiring that much bloat, and my own Java code is no larger or smaller than my PHP.

The real problem is that the design of those projects is bad, and no language or platform will save you from that.  There's a related difficulty, namely that enterprise scale development projects usually suffer from lack of focus and requirements bloat, but from the tone of the essay, I doubt you're mature enough to appreciate that.

[ Parent ]

Boo: Brings up maturity. (n/t) (none / 2) (#102)
by Kax on Tue Jan 27, 2004 at 02:34:44 PM EST


[ Parent ]
It's all about resumes (2.25 / 4) (#73)
by smallstepforman on Mon Jan 26, 2004 at 05:40:01 PM EST

It's all about resumes. Developers/engineers get to play with a new tool (solution), get to learn it on company time, and it looks good on their resumes. Thats the only reason why bloatware gets shoveled into large coorporations. Managers approve because they've heard of the products involved, yet haven't specialised in the field so they dont know the difference between Oracle and MySQL.

Um (2.57 / 7) (#76)
by trhurler on Mon Jan 26, 2004 at 08:54:59 PM EST

Actually, Postgres in modern versions is as easy to use as MySQL, if not easier, and is actually stable, unlike MySQL, the leading cause of downtime on dynamic websites using free software the world over.

PHP? Thanks, but I prefer my security holes to at least be visible to the programmers. As such, I use languages that don't suck. Java is not one of them. (Perl is pretty coo.)

In short, yes, commerical products often suck, but the notion that just swapping in some small free replacements will solve everything is a religious belief rather than a solution.

'God dammit, your posts make me hard.' --LilDebbie

but you miss the point (none / 1) (#77)
by speek on Mon Jan 26, 2004 at 09:03:42 PM EST

If you insist on the best security, the best stability and uptime no matter what project we're talking about, then you're part of the problem. More than likely, you're also the type to insist always on proper designs before coding, fully-fleshed out requirements, proper code reviews, designated test teams, etc. Part of the point here is that these things do have costs that are not worth paying for on every project.

al queda is kicking themsleves for not knowing about the levees
[ Parent ]

No (none / 2) (#104)
by trhurler on Tue Jan 27, 2004 at 04:35:15 PM EST

I am not one of those. On the other hand, I do think that if you don't do SOME planning ahead of time, you're going to end up doing more work down the road, including more planning than it would have taken to do it right the first time.

That said, I don't think this was the poster's point. His point is that these commercial products really don't work as advertised, and he's right. BUT, his somewhat religious fervor for this tool and that is still distasteful; as we all know, the only things worthy of such drooling are BSD and vi. :)

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Why people buy enterprise solutions (3.00 / 12) (#82)
by Will Sargent on Tue Jan 27, 2004 at 03:02:50 AM EST

I go through this in theserverside.com every so often, but I didn't think this would pop up here.

So okay.  Here's some things that MySQL doesn't do.

It doesn't support inner queries.  Want to do a select in a select?  You're out of luck.
It does support transactions.  Finally.  Now let's see it do two-phase commits.
It doesn't do aliases for tables.  At all.

You would expect an SQL92 compliant database to do this, but MySQL just crumbled horribly under me.  I  tried to do the job with MySQL and I couldn't.

Okay, so let's look at some bigger concepts.  Take a look at your persistence layer.  Are you writing directly to the database?  Do you have the concept of caching built in?  Do you have more than one server?  How do you handle cache consistency between servers?  Does your solution support threading?  How about error handling?  What do you do if a server fails?  What do you do if some of your information is in SQL and some is in LDAP?

Stuff like this comes up all the time.  There's a book out by Martin Fowler called Enterprise Application Patterns which goes into some of the solutions for these problems.  There's a book called Bitter Java which says what happens when you don't solve these problems.

There are a whole bunch of PHP solutions and Perl solutions which have lots of functionality which have to be scrapped because they don't fit into the enterprise.  They work fine as a piece, but they don't work when you put them altogether.  

The reason why you buy enterprise solutions is because they're solutions for the ENTERPRISE, not just for the project.  Yes, they force you to do things their way and stop you from taking the most direct route.  That's a feature.  If you took the most direct route, you'd end up screwing yourself.

Unfortunately, many programmers ignore the whole reason why they bought the thing and try to do things the way they did it before, instead of working with the platform.  As a result, they end up with the worse solution, because they're having to actively ignore the platform they're working on.  Go figure.  If you want a hack you'll get it, no matter what you're working on.

Properly used, enterprise software does things that you just couldn't do otherwise.  The fact that you can misuse it is more to do with the programmers than the technology.  But that's a whole nother topic.

Email me if you're having any specific problems with ATG in particular, as long as it's not something like "there are too many properties files."
I'm pickle. I'm stealing your pregnant.

Most Enterprises don't need Enterprise solutions (none / 3) (#90)
by World66 on Tue Jan 27, 2004 at 09:02:35 AM EST

I think the point of the article is not so much that enterprise strength solutions aren't needed at all, but that in a lot situations you'd better of with a simpler system, even as a Big Enterprise.

We do a lot of smallish projects for biggish companies and they big companies always insist that we use Enterprise stuff. It might be that having all your stuff running in one framework makes things easier to handle, but it does make stuff very complicated and expensive. In 9 out of 10, a Zope based solution beats the Enterprise content management solution in terms of money, functionality and implementation time

- - - - - - - - - -
World66: The open content travel guide
[ Parent ]
Missing the point of my comment though (none / 3) (#105)
by Will Sargent on Tue Jan 27, 2004 at 04:43:17 PM EST

At some point the big company is going to want those two systems to work together or exchange information.  If it's written in roughly the same way using roughly the same tools, it makes it easier to integrate and maintain those systems.

The cost to the development of the project is not the total cost of the project.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

Postgresql though? (none / 2) (#114)
by ph317 on Wed Jan 28, 2004 at 08:56:33 AM EST

I can see your MySQL arguments - but is there any good reason not to use PostgreSQL, which does support a lot of the more advanced functionality some code needs?

The only reason I haven't recommended it at my place of work is that for the projects I work on fault tolerance is a big deal, so the RAC concept sells a lot better than what PostgreSQL has right now (which amounts to master/slave thingies of varying degrees of sophistication).

[ Parent ]

Postgres is mostly fine (none / 2) (#119)
by Will Sargent on Wed Jan 28, 2004 at 03:43:17 PM EST

I haven't tried scaling it to anything, but I'm using it.  It doesn't have a lot of the fancier features like a full text search engine, XA support, and I think I had problems with BLOB/CLOB data types.  

The only really serious problem I've had with it is that there's a bug with the SQL query generation between longs and double precisions, so I can't do "WHERE foo < bar" if they're of those data types.  Luckily this hasn't impacted me too much, but you might be SOL if it's something you need.  They say this is fixed in the next release.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

XA? (none / 1) (#123)
by ph317 on Thu Jan 29, 2004 at 08:38:16 AM EST

I always thought XA support just meant transaction support?  I use transactions in postgresql all the time.  Does XA mean something else? (obviously, I'm not a DBA, just a coder that uses databases sometimes :) )

[ Parent ]
XA definition (none / 1) (#125)
by Will Sargent on Thu Jan 29, 2004 at 05:19:00 PM EST

XA is a transaction standard.  You can find more about it here:

I'm pickle. I'm stealing your pregnant.
[ Parent ]

but... (none / 2) (#127)
by teichos on Fri Jan 30, 2004 at 10:58:51 AM EST

...a properly normalized database does not need any more bells or whistles than what MySQL provides... Stop defending bloatware and learn how to design.

flames and modbombs are the most pathetic forms of flattery
[ Parent ]
"Properly normalized" (none / 1) (#131)
by Will Sargent on Sat Jan 31, 2004 at 08:38:35 PM EST

I'm sure this must be a troll, but...

Normalization is a good habit to get into.  Third Normal Form will not, however, save you from the realities of production.  There will be times when you want to explicitly break normalization so you don't have to do an extra join on a query that is in the critical path.

In essence, learning "how to design" means coming to the understanding that design comes FIRST and properly normalized databases come AFTERWARDS.  I didn't just want those features, I required them.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

wrong (none / 1) (#134)
by teichos on Sat Jan 31, 2004 at 10:15:46 PM EST

Starting from scratch, the data schema comes first, and third normal form is a good start. Joins are not a problem to be avoided, but an asset of the elemental set theory SQL is based upon, an essential component of scaling. After that, then you can design anything on top. Avoiding normalization and getting your data into a single table is building a spreadsheet, not a database. "Production" means having a system that works, scales, and allows for growth. If you're having problems, review the above.

flames and modbombs are the most pathetic forms of flattery
[ Parent ]
data warehousing (none / 0) (#135)
by macu on Sun Feb 01, 2004 at 07:25:47 AM EST

Not all databases should be in third normal form. On OLAP systems, avoiding joins is a good thing.

[ Parent ]
No, not wrong. (none / 1) (#136)
by Will Sargent on Mon Feb 02, 2004 at 06:10:05 AM EST

Design comes before implementation.  I'm talking about doing a professional database job here, not a CS homework assignment.

First you have the requirements.  The requirements include how fast the response needs to be, what data needs to show where, what the avenues for growth are.

After that, you come up with a design.  You review that design to make sure that the technologies you intend to use can match the requirements.  This typically involves a whole bunch of UML diagrams as well.

After you have a design, then you start talking about normalization and defining a schema.

After you define your schema, you realize that because of some special requirements, some queries at some times will be dependent on a bunch of extra tables (i.e. in 2003 a bunch of tax calculations apply that didn't earlier because of a change in the rules.)  This would totally hose the application if progressing normally -- however, since the results will never change, that data can come out of a different table, even though the data is functionally identical to some joins of some data in some other tables.

Normalization and joins are tools, to be used as I see fit.  If they do not serve the rules of production, I can and will ignore them.

"If you're having problems, review the above."

Erm... why should I take your advice again?  You haven't said anything I didn't know already.
I'm pickle. I'm stealing your pregnant.
[ Parent ]

Doh (none / 0) (#137)
by Will Sargent on Mon Feb 02, 2004 at 06:11:01 AM EST

"rules of production" == "requirements"
I'm pickle. I'm stealing your pregnant.
[ Parent ]
though... (none / 1) (#138)
by teichos on Mon Feb 02, 2004 at 11:55:16 AM EST

...you are using "design" in a different sense than I assumed before, you are still missing the point. I agree, then, that the design ("schema", as I called it) of a project needs to precede the implementation, and I was not claiming otherwise. Duh.

Your argument, though, is that standards are only good to use when they suit your particular fancy, and to chuck out the window when they do not, because they appear to be in your way. If you follow your own principle in all programming matters, as logic would dictate, you are never going to have a system which works correctly for very long, and you will constantly be in debug mode. Standards, like 3NF normalization and higher, are in place for good reasons. There is no valid counterexample when standards should be ignored. You should attempt to use standards to your advantage, rather than avoid them, for example, to make your SQL query slightly shorter.

It is because of invalid thinking like yours that many problems exist in IT. People, and companies like M$, jettison standards when it suits them, rather than seeing the bigger picture, or even seeing down the road regarding their own particular application. So, regarding DB's or any other programming, the old motto is "do it once, do it right, forget it forever." If we were to follow you, it would be "do it n times, do it sloppily, debug it every weekend."

flames and modbombs are the most pathetic forms of flattery
[ Parent ]
"No valid counterexample"??? (none / 1) (#139)
by Will Sargent on Mon Feb 02, 2004 at 01:15:34 PM EST

Like... data warehousing?
I'm pickle. I'm stealing your pregnant.
[ Parent ]
Not the same scale as SQL Server/Oracle/DB2 (none / 2) (#129)
by DaChesserCat on Fri Jan 30, 2004 at 12:28:56 PM EST

I recently developed a site in Perl and MySQL. No, you can't do inner queries in it. Of course, you can't do those on MS Access, either. Transactions? Aliased tables? Sorry, Charlie. MySQL is the OSS version of Access. It's meant to be lightweight and relatively fast.

There is some truth to "the right tool for the job." If you need to browse lists with a couple hundred to a couple thousand records, MySQL works nicely, doesn't use as much memory or CPU as PostgreSQL, Oracle, DB2, etc. If you routinely need to mess with bigger tables, and you have the system horsepower (or a need to distribute the load of multiple servers), MySQL will not do it.

When the client outlined what they were looking at, in terms of dataset size and complexity, I knew that MySQL would do the job for him. On the other hand, I've had another client tell me about a project they wanted to tackle, and they were spec'ing something rather large and complex. They were an MS shop, so I told them they'd need SQL Server, not Access. They had a a dedicated SQL Server, so we put the tables on it and ran with it.

For small, simple stuff, MySQL and Access will do (think pickup truck). For larger, more complex stuff, PostgreSQL and SQL Server are better (think semi). If you need REALLY heavy-duty service, you're looking at Oracle or DB2 (think locomotive; you can distribute load over multiple servers, just as multiple locomotives can be linked to operate as one).

What really killed me was a previous employer who was converting everything to Oracle, even the small stuff. They were coughing up loads of money to get everything moved from Access and SQL Server (they were still, predominately, an MS shop), because they wanted ALL databases located on a couple machines for easy administration. Yeah, there was some logic to it. For some of the projects, they were using a GE AC 6000 locomotive when a Dodge Dakota would've been quite enough. Then, they decided to put the database servers at a central location, meaning that the ODBC connectivity had to go through the WAN, and the PHB's in charge couldn't understand why everything was running so SLOOOOOOOW. They were still bleeding money, still running behind, when they decided they couldn't afford to keep everyone and laid off a significant fraction of their workforce (myself included). And yes, they're still going, but they've outsourced it all to India.

There are jobs where Perl or PHP will get you running in a minimum of time, and do the job. There are jobs where the complexity of the dataset gets to be a bit much for Perl or PHP, and something more heavily OO might be a better fit. I've worked with Java, but not C#; I sort-of like Java, but it can be too rigid at times. I love Perl, simply because 100 lines of Perl does so much more than 100 lines of just about anything else. Additionally, the "develop-test-tweak" cycle tends to be much faster under Perl. However, if I had experience with EJB and JSP (both Java technologies), I'd be making 2-3 times as much money as I am. Any questions why people are flocking to Java, instead of Perl?

Trains stop at train stations Busses stop at bus stations A windows workstation . . .
[ Parent ]
Bloat (none / 2) (#85)
by Highlander on Tue Jan 27, 2004 at 05:15:46 AM EST

I think one reason why you need experts and so called enterprise solutions is the - seemingly human - tendancy to bloat everything till almost nobody understands it anymore. Just see what happened with HTML. In the beginning you didn't need to know more that a dozen tags, now you need to know html, forms, css and javascript. And even better would be to know php and perl. I believe the number of people who actually not only copy code from others but who would be able to write it from scratch without a reference book is comparatively small.

Same thing with a database server. Simple SQL is easy to use almost with all databases, but if you want to use stored procedures and to optimize queries, difficulty rises.

I guess you need enterprise solutions sometimes, but often people use this when they are not really experts and when an enterprise solution is not needed. And it sure looks better on the resume.

Moderation in moderation is a good thing.

Yeah, Enterprise Coding is Hard, But... (3.00 / 4) (#92)
by ChaseS on Tue Jan 27, 2004 at 09:59:11 AM EST

You make the case fairly well that enterprise coding is very difficult and error prone.  I'm sure that some folks needed to be clued in that most software projects go over budget and schedule.  

You also imply that (a)it's amazing the economy tolerates these inefficiencies, and (b)"hobby tools" (e.g. PHP) are somehow better at solving these problems.  

Examining these in turn:  no, it is not that amazing, if you look at the forest through the bramble-patch: Most economists (and CEO's) agree that technology (for which software is a critical component) is chiefly responsible for productivity growth worldwide.  Software is a huge pain, but once it works it is free to reproduce and requires remarkably few resources to do its job (i.e. CPU time/disk space).  On balance, these benefits obviously outweigh the challenges.  (This is not to say that companies rarely make unwise software investments)

The second premise, that hobby languages are somehow better at tackling these problems, is not accompanied by any argument.  You simply assert that productivity is far better with your favorite open source platform.  The one comment that approaches an example is:

--> Ask yourself why you have that "wow-cool" moment when you finally succeeded in serializing and unserializing an object in C# when the PHP geek next to you simply did it with one lousy method call and moved on to other things 3 hours ago! <--

My take on this is as follows.  I don't often use Serialization in .NET; if I have done it before, it was at least a year ago.  I just got it working in about 2 minutes flat.  I also just read the man page for serialize() in PHP.  It looks just as quick and easy to me, although I suspect that it might take me a few hours to get it working given my lack of familiarity with PHP.  My point is that this example does nothing more than to express a familiarity, and a preference (for a platform that is fundamentally very similar to the ones criticized above).

"Hobby" tools and "real" tools (none / 2) (#112)
by John Asscroft on Wed Jan 28, 2004 at 04:26:03 AM EST

At my (Mr. Asscroft's Inner Frenchman's) day job, I am currently writing an "enterprise class" application. We have five times the personnel we had at my last job, but it's floundering. The reason: an insistance upon using Unix-"standard" C and db2, whereas I successfully shipped multiple products in half the time with 1/5th the people at my previous jobs by leveraging Python, Ruby, MySQL, lots of shell scripts, and minimal "C" (just enough to solve the few performance problems inherent in scripting languages). And those products are still being sold on the market today.

Why are we using "C" and db2? Well, gosh darn it, it gives us the maximum performance with minimum resource usage. Only problem: Our #$%@#$ "C" server is using 64mb of memory, about the same as my Python application used, while not doing half of what the Python application did. Even adding up the footprint of MySQL + Python, we aren't getting the bang for the buck that was promised. Lesson: it's as easy to write bloated code in "C" as it is in Python, if you throw enough programmers at it.

When I found my startup, it's going to be Python and MySQL all the way from top to bottom. Screw Java (what my last employer used). Screw C++. Screw "enterprise-class" databases or "embedded" databases. Life's too short for that crap.

We must destroy freedom to save it from the terrorists who want to destroy freedom. Else the terrorists have won.
[ Parent ]

C is for writing device drivers (none / 3) (#116)
by ChaseS on Wed Jan 28, 2004 at 10:35:18 AM EST

Yeah, I hear you on that front.  C is for writing device drivers; C++ is for writing object-oriented device drivers.  I am puzzled by your utter rejection of Java however.  It would seem to be in a completely different class.  I know there is a certain amount of overhead to the environment (all right, a lot of overhead).  I guess that is the appeal of so-called "hobby" tools; I'm sure there are cases in which you can write a routine faster in, say, Python, before you can figure out how Java's (or .NET's) built-in stuff works.  But if one is going to write a lot of code, the advantage would seem to diminish.

[ Parent ]
Java's nice, but ... (none / 2) (#117)
by John Asscroft on Wed Jan 28, 2004 at 11:53:45 AM EST

the runtime sucks. I like Java, Java is what C++ would be in a sane world, but the runtime is slow, buggy, huge, unportable. The last is especially problematic if I want to run my program on less popular processors in an embedded environment using other than one of the OS's that Java has been ported to, I end up having to run Java under some kind of OS emulation there (e.g., running the Linux Java on OpenBSD) which typically doesn't work well. Java also does not fit well into the Unix fork/pipe model, instead forcing you to create multi-threaded programs with all the inherent issues that this creates (though to be fair, the Java runtime handles most of those issues in a very sane manner... it is much easier to write a somewhat reliable multi-threaded program in Java than in any other commonly-used language).

Most of the issues would be solved quickly by the Open Source community if Sun simply released the Java runtime under the GPL, but they refuse to do so. Thus why I say **** Java. Life's too short to deal with buggy bloated proprietary languages.

==John Asscroft's Inner Frenchman
We must destroy freedom to save it from the terrorists who want to destroy freedom. Else the terrorists have won.
[ Parent ]

Java (none / 0) (#140)
by daviddennis on Tue Feb 03, 2004 at 06:06:52 PM EST

I know next to nothing about Java, except for one curious fact: Nine times out of ten, whenever I see the extension of JSP on a web site, the thing runs turtle-slow.

As someone who would love to see just about any alternate to Windows succeed, it pains me to say that ASP sites seem to work a lot better than JSP ones, but it's just the truth.

I code in raw C, under Linux/MacOS X because I'm used to it, and my sites all run fast.   If I didn't hate seeing dollar signs in variable names, I'd probaly get the same results in Perl or PHP.  But JSP seems to be designed as a curse on software performance.

So if it's also slow to develop in, why use it?

amazing.com has amazing things.
[ Parent ]

Great Comments (none / 3) (#95)
by jeremie on Tue Jan 27, 2004 at 11:21:17 AM EST

Very entertaining, parallels almost identically too many of my experiences as well.  An important managerial aspect you're not seeing though:  

The size of a project's budget and buzzword recognition has greater political significance than the actual success or result.  Being that, it's very difficult to talk up or spend that much on working-class technologies.

The Butter Knife & The Chain Saw (none / 2) (#99)
by HiFi78 on Tue Jan 27, 2004 at 01:57:48 PM EST

I think that most of these issues can be resolved by using the right tool for the job.

Both the butter knife & the chain saw are cutting tools, but have you ever tried to cut down a tree with a butter knife? Have you ever tried to cut a stick of butter with a chain saw? Either way, it's not pretty.

PHP, JAVA, .NET... Oracle, MySQL, DB2... Pickup trucks, motorcyles, sedans... everything has a use, and it's the job of the entire team to determine the right tools for each job. If DaVinci had tried to paint the Mona Lisa with a can of spray paint, we wouldn't argue that spray paint sucks; we'd go find another artist.

Boo: Used the phrase 'right tool for the job'(n/t) (none / 3) (#101)
by Kax on Tue Jan 27, 2004 at 02:32:31 PM EST


[ Parent ]
The problem was 'The' (none / 3) (#115)
by HiFi78 on Wed Jan 28, 2004 at 09:48:47 AM EST

I shouldn't have said the right tool for the job. I think a right tool for the job would have been better.

[ Parent ]
The problem is the programmers. (none / 3) (#103)
by Surial on Tue Jan 27, 2004 at 03:12:45 PM EST

There are -many- tools out there. While you can do some really neat stuff if you keep it all 'standard' and 'not reinventing the wheel', the principal problem with the extensible programming concept (where everything you write is jacketed as a useful general purpose library-like thing, ready to be used by other developers) is that it's just not fun compared to writing your own.

I have met programmers who do like reading through documentation all day long. However, in many cases these can't program worth beans.

The solutions to this problem are many.

 - Do not general-purpose everything. Consider making a quick hack, document the hack as a whole (what it does, so that if it breaks, people just rewrite the whole thing), and move on. If later on you notice you did actually need the whole enterprise this or generic configurable that, then just rewrite it.

 - If you think you can do it faster by just coding it yourself instead of using a 'standard solution', do it. As long as you block off the 'hacked together code' and at least do a good job on interfaces and such if other people need to worry about it. The best thing that can happen to your project is for it to be nicely split up in many easily maintainable more or less independent parts.

 - the right answer is somewhere in between. Don't use a standard solution for everything, but if you envision either many hours of programming, or much testing required because it absolutely has to work right, or lots of long hours bughunting because the thing you're building doesn't lend well to testing, consider going with a standard solution.

What most 'standard solution' zealots underestimate is the speed at which something that's essentially quite simple can be whipped together by a good programmer. If it can be isolated with a simple interface or some such, isolate it and write some horrible code to make it work. Mark it 'unmaintainable crud!' if you want.

Java especially suffers here. Java really works best if you use a whole slew of standard solution stuff. Java is like english ; the basics are easy to learn but it takes a lot of hours to become a true native speaker. Fun thing to do is to use Jython for the fast hack parts. If ever it needs to be made more robust, rewrite. Rewriting is not the sin that so many make it out to be.
"is a signature" is a signature.

So... (none / 2) (#120)
by ksandstr on Wed Jan 28, 2004 at 05:58:02 PM EST

Does PHP have an usable language construction (or has a similar idiom developed among PHP users) for catching errors while inside a SQL transaction? For an example of what I'm talking about, take a look at they way that Perl's DBI module(s) handle this. The last time I tried, catching errors in PHP and PostgreSQL involved poking the function return value  every goddamn time I wanted to run the simplest of queries and this eventually caused the PHP side of that particular project to become nothing more than an early prototype of something I ended up re-writing in Perl later. (Mind, this was almost four years ago at a time when MySQL had close to no database integrity guarantees [i.e. "autoincrement should be enough! we only support transactions without rollback! no soup for you!"]. Not that I've felt any need to check on it these days either.)

Frankly, I'd go as far as to say that everyone who lightheartedly flaunts the usefulness of ACID-compliant transactions is either woefully ill-educated, misdirected or just a plain old wanker. This is not to say that horrible, ill-disciplined crap could not be written for a proper database with a proper implementation language by a programmer who really doesn't know just what the hell s/he's doing apart from that those language features he's piling and piling on his prematurely bloated design are plenty_cool. However, I can't help but notice that such... overtly complicated designs tend to crop up with tools that have been marketed with the age-old "you don't really have to know what the FUCK you're doing with this great big fancy tool of ours!" method.

To bring this particular comment to an appropriately rambling and frothy-mouthed close, I'd like to state that most people who claim to "have learned a language" will only know bits and pieces of the syntax. As evidence, I submit all the times I've come across C code that had a "#define begin {", "#define end }" pair somewhere. Really, learning a language is like losing weight in that if someone tells you that losing weight is easy, s/he's fucking lying.


Do it fast and cheap (none / 1) (#121)
by johnnyfever on Wed Jan 28, 2004 at 06:28:15 PM EST

At the company where I am currently sitting, they just finished spending ~50 *million* dollars and several years of effort to get virtually nothing, cancel the project and fire all the developers. This was an Enterprise Java type of project.

Firstly, I find it positively obscene that these corporate mo-fos can burn $50,000,000 for nothing. What I would do for a small fraction of that sum....

Anyways, these folks had purchased every third party product for their Java project you can imagine, toplink, this app server, that framework, etc etc. It was so complicated and convoluted that even if they had any specs to build from (another issue equally related to the projects failure), there were so many crappy APIs to learn how to use all of which had their own little problems that it was an impossible mission in my opinion.

Now, I quite like Java myself, and I also like PHP and Perl. I don't think that Java by itself is the issue. You can build apps very simply and quickly in Java if you set out to do it that way. I thing the problem is that as geeks, we have always been taught to do it the 'right' way, technically speaking. We spend all kinds of time analysing stuff to find the best way to do it, and then we refactor it all regularly just to make sure it's still right.

This is just peachy as a geek, but as a business person who just wants a working application which does X, I don't give a rat's ass how you built, what technologies you used, or how pretty the code is. I just want a fucking application that works, I want it quickly, and for a reasonable price.

It seems to me that this is what IT is failing at, and this is at least partly why we are all being laid off in droves. Businesses are sick of shelling out huge quantities of cash in order to have a bunch of unpleasant, prima donna geeks run around espousing their wisdom, but not ever deliver anything.

I agree with the sentiment of this article ... wake up people ... fast, cheap, and functional wins every time.

Sure (none / 1) (#126)
by Will Sargent on Thu Jan 29, 2004 at 05:23:21 PM EST

I agree completely.  However, these people probably thought they were saving development time and money by buying all the functionality in little API packages and then hooking them altogether, as opposed to writing everything themselves.  There's more than one way for a project to fail.
I'm pickle. I'm stealing your pregnant.
[ Parent ]
I don't really understand all this (none / 0) (#143)
by Verdeboy on Fri Feb 13, 2004 at 01:36:58 AM EST

I program as a hobbyist than as a professional, so put my opinions in that light. When I look at code for a project for some open source project i'm thinking about modifying to add x feature, i'm not looking for perfectly formatted, written-just-so code. I just want it well commented, easy to read (hit tab every once in a while, or use an editor that does it for you), and to WORK. Besides that, why do people even care exactly how it was written or the style? It pisses me off to no end to get some stupid bug pop up when I compile some one else's code, then not be able to find out where the bug is to fix it because their code is so convoluted or poorly formatted that it is impossible to follow.

[ Parent ]
Why did they really pick it? (none / 2) (#124)
by marcmengel on Thu Jan 29, 2004 at 01:07:05 PM EST

The aspect of tool choice that really gets my goat is why people pick particular tools.

The reasons I particularly find bad are:

  • Having programming experience in xxx will look good on my resume
  • Nobody ever got fired for recommending xxx
  • I read an article in "xxx News" that said xxx is really good.
  • Really Big Software Company says xxx is great.
Much more acceptable reasons are:
  • every other component of the Whizzy package is in xxx, so this probably should be, too.
  • if I grab the foobar library module from the xxx package archive, I can complete this in 10 additional lines of code.
  • I'm really familiar with xxx and I can see already how to write this.

you're right (none / 2) (#128)
by teichos on Fri Jan 30, 2004 at 11:17:42 AM EST

I agree with you, and I note that no Java project I've ever seen actually worked as advertised, but there are countless Shell, Perl/PHP, MySQL, XML and other "hobbyist" apps clicking along perfectly well.

The problem is a whole vast food chain of economic dependencies, initiated by Micro$oft, in which programmers get "training" and certs, big customers hire them to write "enterprise" bloatware, and everyone implicitly agrees that results do not matter, as long as they are making and spending money. Nearly all of these projects fail, and as you note, nearly all use technologies, which taken alone, ensure they will fail. Success of the app for the betterment of the enterprise is never one of project parameters, although it might appear in the bullet-point presentation. Keeping the precious food chain going is always top priority. So, the problem is money, and where money is not an issue, better technologies are used, things magically get fixed, or better built from the start, and the app just plain works.

flames and modbombs are the most pathetic forms of flattery
you're an idiot [nt] (none / 1) (#141)
by bg on Sun Feb 08, 2004 at 10:41:59 AM EST

- In heaven, all the interesting people are missing.
[ Parent ]
Have you built a really large scale application??? (none / 3) (#130)
by Alhazred on Fri Jan 30, 2004 at 02:26:08 PM EST

Currently I'm implementing high trading desk systems. These are applications which pull in data from sometimes 7 or 8 different sources (stock prices, trading volumes, you name it) using mostly proprietary protocols, normalize the data, feed it into market information databases (which have to track where each piece of data came from, when it was updated, etc, etc, etc).

On the other side we have large complex analytical processing systems crunching through this data looking for trends, identifying events of various types, etc.

On top of that we have other kinds of things like news feeds.

Finally we have 100's, sometimes MANY hundreds, of users constantly hammering on all of this stuff, making trades, creating analyses of various sorts, and often just sifting through data by hand or watching news feeds. These are the guys with 5 screens each on their desks with stuff wizzing across them full tilt 24/7.

Every time there's a glitch it costs someone 50 grand. Generally if you can't explain the problem it stands a good chance of getting you your ass kicked. In any case you better have TOTALLY stable systems.

Now, NOTHING is wrong with PHP, MySQL, etc. I've built many a web app and I'd certainly pick those tools in probably a majority of cases, but its simply not feasible in the kind of environments I'm describing, and these environments ARE what enterprise software is all about. Its the banks processing checks (100.000000% reliability absolultely demanded 24/7) the stocktraders, the electric power utility control systems, big financial, medical, governmental, and industrial systems that have 1000's of users on them all day worldwide.

These things simply CANNOT be built using tools that don't provide features like type safety, that don't enforce good programming practices, that don't include built-in from the ground up hooks for scalability and reliability features which have been barely thought about in MySQL.

And trust me, the people managing these systems ARE cost-conscious. Not that they make all the right choices all of the time, but the successful ones are successful because their projects come in reasonably on track and deliver high reliability services.

Instead of trying to poke holes in the concept of enterprise solutions, maybe a more reasonable discussion would be 'at what levels are the various classes of tools good choices?', and 'which tools work well in what roles?' and maybe just 'which tools are just plain turkeys?'. I agree that some tools are crap. Some of them are the favorites of well-known vendors, but I can also show you horror stories that were created with the very open-source tools you so love.

And in the final analysis I don't believe the people teaching software engineering are doing an incredibly good job. A lot of people can program, very few of them have been taught decent engineering, and even fewer of those understand how their work relates to business processes in the real world. In many cases I've worked with people that have an MSCS and can't do squat in the real world. Ultimately its the people that make a project, not the choice of tools.
That is not dead which may eternal lie And with strange aeons death itself may die.

PS (none / 1) (#132)
by Will Sargent on Sat Jan 31, 2004 at 08:39:18 PM EST

Except for XA transactions.  That I've never needed.  But bitching is so much fun.
I'm pickle. I'm stealing your pregnant.
Oh dammit (none / 0) (#133)
by Will Sargent on Sat Jan 31, 2004 at 08:41:03 PM EST

I lost my context.  Where the hell is my parent comment?
I'm pickle. I'm stealing your pregnant.
[ Parent ]
Hear Hear (none / 0) (#142)
by Verdeboy on Fri Feb 13, 2004 at 01:28:49 AM EST

I wouldn't mind as much that these companies are pushing Enterprise stuff as much if it wasn't for one word: INTER-COMPATABILITY. I aboslutely loathe stupid companies trying to force the hapless end-user to use their products by making them incompatible with everything else (and in the case of Microsoft [may Bill Gates burn in hell] incompatible with previous versions of their own products). Anyone who has migrated to Linux but still has to keep a minimal Window's installation on his system or use an emulator to do certain silly things just so people he works with can actually use his data can sympathize with this problem. This is not just a Microsoft rant either. Any kind of proprietary system needs to have at least minimal compatibility with the competetion just for the sake of maintaining productivity.

The bloated, dysfunctional world of Enterprise Solutions | 145 comments (118 topical, 27 editorial, 2 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!