- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Ugh. Anything requiring speed should avoid BizTalk. I've never met a piece of software that was a bigger pain in my side.
Admin
That's pretty enterprisey.
Actually, I didn't know Biztalk could do all that. Good to know...
Admin
It forgets the steps where it prints an image of the transactions and then scans them on a desktop to get the wood border.
At least the potential customers (if there are any) can justify the high price tag, even without XML.
Admin
Would have been first if not for BizTalk. Argh~!
Admin
"And since Enterprise Financials was to be a real enterprise solution, it was to use BizTalk. Of course, the only problem was that the architect (whose decision it was to use BizTalk) had never used BizTalk before. Neither had anyone else in the company."
That has to be one of the bigger WTFs that I've had to deal with at times. Someone (usually not even a developer) who has never used a product/service before claiming it to be some "silver bullet" that will solve all of the problems of a project.
The separate WTF, of course, is this "over-engineering" mentality that comes into play when dealing with an "enterprise architecture". Somewhere along the line these idiots decided that the KISS mentality was just not enterprise enough. Of course then they will stand up in meetings and say their application is done the "right" way and while other applications might work faster, they are "garage" apps (usually they go on to imply that the faster apps are somehow insecure).
Admin
I've run into this type of situation before. Some architect falls in love with remoting, webservices etc and the system as designed spends so much time converting, serializing, sending, receiving, deserializing, converting, etc that you have to jump through a ton of hoops just to execute a simple report query.
Then the business users wonder why everything runs so slow. I actually had an experience where I went outside the pattern and got the data correctly for a report that was taking 2-5 minutes to run. I got it down under 30 seconds and was told to roll it back because it didn't match the architect's template. I quit the job 2 weeks later.
Admin
I like the workflow...
sjees.
Admin
If the serialization takes place in a separate service accessed via remoting, how does the page know how to serialize the object to make the request? This architect must be utterly brilliant to have solved this dilemma.
-ds
Admin
Remember when you used Excel (VisiCalc?) to enter some numbers and computed a result? Now, it's some table-variant on a web page sending an ajax-esque request to a server that interprets the request and redirects it to an appropriate service that redirects it to some reporting subsystem that finally accesses the real data/cells to compute the results only to send the answer back.
Sounds like job security to me. What was the line from Jurassic Park; "they were so busy figuring out if they could that they didn't consider if they should".
Do we never learn from history?
Admin
yea who cares..
let's get something juicy up in here.
this is Crapola.
:)
I hope some people enjoy it cause I dont :)
can I request some good c++ or heck even some vb or c# or.. java.
anything else please.
Biztalk and stupid process does nothing for me.
how about stupid process in game development?
got any good game code that need's to be laughed at?
if not I could prolly pull some out here somewhere grin
Admin
Isn't that where the BizTalk comes in?
Admin
I don't see the problem. Unless the problem is that there isn't enough XML in the transaction? Or, no milk for the serial(ization)?
I think it is "brillant".
Admin
Isn't BizTalk a Mi$rocoft product? I bet the architect got a big kickback to 'lock-in' his company's architecture to M$ so that it could never escape. Of course, M$ wins the money they gave to the architect back many times over as they keep selling upgrades and new versions to improve performance, speed, etc in the following years.
Admin
As an architect myself, I can't understand why anyone would (could) design something like this and not realize how bad it is. What's worse, how can the people that worked on the system not have raised red flags?
Not that I would, but if I ever designed anything this bad, I would be mad if someone DIDN'T tell me I f'd up
Admin
There has been a trend of decision making / management WTFs and no good 'in the code trenches' ones in a while. It's like the difference between hearing someone talk about a nasty car wreck or actually getting to see pictures of the wreck.
We need some shock value!
Admin
I met one piece of software, that was even worse than BizTalk. IBM WebSphere MQ Enterprise(y) Message Broker. Pretty same functionality as BizTalk, but with IBM salt of "being different".
Admin
Download LABFLSRC.ZIP. Guranteed at least one WTF every line.
Admin
How ignorant I have been all these years! My definition of an enterprise class application was that it
1) is secure,
1) scales well,
2) is robust and
3) meets auditing/compliance requirements.
How naive I was! An enterprise class application is one that
a) is deemed so by some buzzword-spouting salesperson representing a major vendor,
b) costs a lot of money,
c) uses every conceivable technology/design pattern the "architect" picked up at the latest dev confab he went to on company dime, and
d) crawls between its frequent breakdowns (so the support folks and on call people will have something to do)
If your application serves thousands of users, is snappy then you don't know what you are missing. You should upgrade to something with an enterprisey sounding name and costs lots of money (the more the merrier) .Also, make sure it breaks often, requires lots of highly paid vendor-supplied consultants, and is slow enough to force the guys in Accounting to take frequent coffee breaks and leave long after 5 pm on most days (who do they think they are, bankers?).
Admin
If a picture is worth a thousand words, then a code/SQL/HTML/XML snippet has to be worth at least 255 words for the purposes of eliciting the WTF reaction. I'll never forget my first daily WTF experience: the for-case paradigm. Or the moment when the lightbulb went on when reading about tossing the SQL cookies.
I too would like to see more code-snippet WTFs over "description" WTFs. Maybe stuff the "wtf-stories" into the Friday pot-pourri as a counterpoint to the "lovely" screenshots. The stories do have their place, but perhaps a smaller one.
Admin
If you have a game-dev story, by all means feel free to submit it.
As far as game code, I doubt I'd post something from a game. Video games are designed to be one-time products with no future maintenance needed. As long as it works once it's out the door and the original developers understand the mess, who cares?
Admin
In the voice of Buffalo Bill:
"It queries the data from the database. It binds to a data grid! It does as its told!"
Geez. How many extra steps can you get? Someone needs to tell that architect the first rule of distributed computing by Martin Fowler: "Don't distribute!"
Add BizTalk on top of that and you got yourself a crap sandwich.
Admin
13 steps in a class A enterprise application? That's just not trying hard enough.
Admin
I'd think so too, but wouldn't they sometimes reuse some code (like a physics engine) from one project to the next, and continually evolve it?
Admin
Today's WTF reminded me of another JP line when I read your post:
(paraphrasing) "Goddamn, I hate this hacker crap!" (Samuel L. Jackson)
Admin
Wow. And I thought it was bad when, at the heart of the financial services framework I have to work with, I discovered that every service request would be serialized into a byte array, which would be Base64 encoded into a String, which would be optionally compressed, then serialized into a byte array before finally being serialized AGAIN to be sent over the network. Between all those serializations and conversions, the data was held in memory simultaneously in about 8 copies, causing the system to fail with an OutOfMemoryError when faced with the epic task of displaying a full list of more than about 5000 accounts each consisting of a couple of dozen fields (the data objects were badly bloated as well).
But doign the serialization itself by using a service over the network - pure brillance!
Admin
This "solution" reminds me of a thread we had a while back about stored procedures. Someone mentioned that they never use stored procedures, since they get all the data abstraction and security they need by using web services for all database access.
Admin
Where's the XML?
Not very "Enterprisey" without some XML.
Admin
The architect's name was Rube Goldberg?
Admin
And why would you want to use an ArrayList for keywords, when a HashSet has a much better complexity?
/Esben
Admin
and 8) can do numbered lists properly.
No actually, what you've missed is: 5) extendable/adaptable.
The problem is firstly that people get obsessed with this one to the exclusion of other requirements. And secondly, they fail to realise that extendability requires intelligent decisions as to which directions the extensions are likely to be needed. What are the priorities? Instead they try to make everything "flexible". And prioritising everything is of course the same as prioritising nothing.
(Unlike one or two other posters I like the development/boss stories just as much as the code snippets. Keep them all coming.)
Admin
Admin
Most architects, 'specially the ones with degrees BEFORE BizTalk hit the scenes, jumped on it like it was some panacea. Instead, it has since caused a data diaspora.
And like the diaspora with the Jews, data and processes remain mangled, munged, and inherhently linked since most developers will slack in places around a project (as well as architects) and let dependencies creep in. Thus, you get complexity for the benefit of NOTHING.
BizTalk, Gentran and Mercator are useful tools for communications between business partners or even getting despondent legacy systems to interoperate...
BizTalk is a BAD choice for actually implementing the LOGIC GUTS of your software!
DONT WRITE YOUR APP IN "BIZTALK!"
Admin
sigh...
Why don't companies do REAL research... .By that I mean creating test servers and test applications that represent what they want to do, but largely scaled down. That way they can test how easy it is to develop on the platform, how fast the platform is, how stable it is, etc...
If they spent a month doing just that, they would realize that BizTalk has no place in their design. Awell...
"Enterprise"
lol....
Admin
I worked on a web app in an environment with a ton of different browsers, ranging from Netscape (!), to Opera, to Explorer, to Safari.
Almost immediately I decided to use no javascript if at all possible, because I knew that it would be a nightmare. Instead I set it up to do all the code serverside, and output only standards compliant HTML.
Now, obviously I lacked some of the sexyness that only Ajax can add, and I spruced this up with a little flash and a few animated images to make the site seem a bit more mobile, but it still had a very static feel to it.
So along comes some joker who decides that I made it the way I made it because I was techinically imcompetent, and he talks up all the page reloads, etc, that my application has to do because I don't have any client-side processing, etc, and he gets permission to re-write the entire frontend in .Net with TONS of javascript. He demo'd it to the bigwigs, and it was a tremendous success, and then he deployed it company wide.
It lasted 17.5 hours. The only people who could use it were the few manager machines that were running the absolute newest everything, and not even all of those, because the managers who did work mostly used macs. This is a mission critical application, mind.
My frontend wasn't sexy, but it loaded almost instantly, and it looked exactly the same on every computer in the building. Didn't matter which browser, didn't matter which OS. Looked great in Lynx even.
Fancyness has its place, but functionality is king. If it works well, people will call it "simple and elegant" if it is the most boring thing on the planet. If it works poorly, it doesn't matter how cool it looks, it's still crap.
Admin
Yes! This hits it on the head.
It seems to be getting worse. I've seen so many over-engineered super-generic thoroughly cryptic monstrosities in the last year that I'm thinking of writing a book about just that one antipattern.
For those who didn't know, KISS means "Keep It Simple, Stupid." Just do it the direct way. If you ever need something generic it's easy enough to wrap it later.
Admin
Amen, Brother! Preach it! Preach it! I'm seeing Digg and Slashdot links now that are for improving the accessability of Ajazified apps. I haven't spent much time reading, but I can say for sure that if you are shooting for WAI level 2 or 3 complance, AJAX is not going to fly, because you have to provide the exact same data (not functionality, but data), in scripting vs. non scripting environments. I haven't heard of any non-JS AJAX, but maybe there is some.
In addition, the technology now lets you use CSS to make elegant designs without sacrificing people using screen readers, text browsers, or JS-turned-off browsers.
Admin
Right. Then there's patches, bug fixes and expansions.
Just think about Duke Nukem Forever. It's been in development for 9 years and is the quintessential WTF in itself.
Admin
Some people have a far bigger ego than yourself. It's amazing the effect that can have on a person. There is a sect of people in technology out there who believe simple solutions mean not enough work is being done. Such a person will overthink even the most mundane problem and produce a solution that looks more like a Rube Goldberg machine than a working software application.
Admin
It's actually very doable, and not that hard to do. It's at the heart of the "Progressive Enhancement" and "Graceful Degradation" philosophies: add fancy stuff on a solid, working, deeply rooted in the basic (read: standard, clear, rock-solid raw HTML), layer your application, with each upper layer depending upon the lower ones, but the lower ones being fully independant of the upper ones so that the application/website will still work flawlessly if an upper layer fails or isn't available (with less bells and whistle, less buzzwords, less graphics, but it'll still work), layer your CSS on top of a working and usable HTML base, layer your javascript on top of your working HTML+CSS base, layer some more CSS on top of it, sprinkle with fancier JS and remote calls (e.g. AJAXy stuff). And ALWAYS have a fully working application if a layer fails (at least if the upper layers fail from top to bottom, the best designers/coders can create applications that will still be usable whatever layer fails unless it's the HTML).
AJAX is a buzzword. Not a philosophy, not a technology, nothing but a buzzword. And if you haven't heard about "non-AJAX js" then maybe you'd need to get out more.Admin
Good god.... that webpage design is a huge WTF in and of itself... forget the code.... damn....
Admin
Actually, Duke Nukem Forever is the opposite of that. While other publishers are happy to dump a barely-out-of-beta turd on the shelves and release patches for the next year and a half, 3D Realms is sitting on their product until they're satisfied it's truly done. For that they have my admiration.
Of course, if it sucks when it finally comes out, I'll be among the first to bash them. After such a delay, they certainly better get everything right and it better not feel like a sloppy beta.
Admin
That's funny. When I was working at Microsoft, I got to hear about how BizTalk was created: a group of marketing guys were putting together a press release to announce new initiatives, and included some vague idea of backend business process talking to each other. This was the birth of BizTalk. In other words, they were announcing a totally undefined product as a way to generate buzz and motivate engineering to create some product (any product) they could sell.
Admin
>> Actually, Duke Nukem Forever is the opposite of that. While other publishers are happy to dump a barely-out-of-beta turd on the shelves and release patches for the next year and a half, 3D Realms is sitting on their product until they're satisfied it's truly done. For that they have my admiration.
BS. Bungie managed to get Halo 2 out the door with only a small delay, and it's one of the greatest (if not the greatest) FPS games of all time. Half-Life 2 was a year late, but, again, turned out to be a great game. As far as I know, every version of Unreal has been rock-solid on schedule, and they set the standard for quality graphics every time.
Games that are delayed longer than a year almost always turn out to be total crap. Look at Daikatana or Tribes 2, for examples.
Admin
masklinn-
I'm pretty sure it was "non-JS AJAX", not "non-AJAX js". You're coming down a little too harsh here for not even properly reading what is being asked. AJAX might be a buzzword, but there are certain technologies, ideas, rules, and expectations involved with AJAX. In other words, it is a little bit more than just a buzzword.
sinistral-
Since the "J" in AJAX stands for Javascript, there is no AJAX without JS. You could maybe do some AJAX-like stuff with fancy uses of frames or iframes and so forth, but AJAX implies the use of Javascript, or of at least some interactive layer supported by the browser (XUL). Strangely, it does not imply the use of XML (check out JSON). Anyways, if you're interested in learning about alternatives to the "normal" AJAX style (ala, JS with XMLHttpRequest), or better ways to incorporate AJAX with usability in mind, such as masklinn aluded to, check out http://ajaxpatterns.org. Great site for learning lots of down and dirty things, and certainly one of the most complete I've come across for advanced AJAX/AJAX-like topics.
Admin
I have to agree. If DNF is 9 YEARS overdue, its probably because of project mismanagment, and its codebase is probably a big WTF, which in turn will be probably mean a crappy end product. You can add "Ultima IX" to that list. It was also years late and it sucked pretty bad.
Admin
When MS Commerce Server 2000 first came out, I had some training on how it (And Biztalk) were meant to work together.
The impression that I came away with was that Biztalk was meant to be a "Inter-System translator". Basically XSLT with knobs on for handling different kinds of inputs and outputs (e-mail, fax, modem, reel-to-reel-tape, you name it). And the main reason for getting Biztalk was the BizTalk designer, which essentially was a graphical (And powerful) way of making XSLTs. No business logic was meant to be in this layer, it was merely a way for (Say) your ASP eCommerce site to talk to your Universe backend, and your Universe backend to talk to your Java based suppliers and your Fax-based customers and so on.
[rant]
Though, TBH, I'm kind of against making things "Many-Layered" for the sake of it. Why should your Webpage call a Webservice that uses a Business Object that talks to a Data object that calls a Stored Procedure that queries a Database (That runs in the house that Jack built), when the whole process is within one application.
Certainly, if you're going to have an externally published API, that should remain constant (And should have consistant interfaces), but for an internal structure, why do you really need ALL those steps? All it does is introduce more failure points, more complexity, and greater server load. And throwing more hardware at a problem (IMHO) is only a solution in the worst possible case.
[/rant]
But then, I've seen SQL Stored Procedures used to write, build and compile VB apps, so I guess just about anything can be repurposed in a hideous and rube-goldbergian manner.
Admin
Tsk tsk, you misspelt "brillant". :)
Admin
Can you say Doom-3 engine?
Admin
<FONT face=Tahoma>BizTalk is only good for "talking" or "facilitating" communications between dislike systems, if you go further than that then it gets really messy...
<FONT face="Times New Roman">
</FONT>
i agree...
like what everyone said, this is just over engineering in an effort to make the application "enterprisey" for the cost of speed and maintainability...
</FONT>
Admin
Physics engines are actually outsourced nowadays. Does Havok ring a bell? Even the whole game engine is often licensed from an another developer. ID Software (Quakes & Dooms) & Epic (Unreal series) are currently the most popular game engine developers. While this does free up a lot of resources that can be used to develop the actual content, it also does set constraints for the developers.
There's still room for innovation, though. For example, the fabled physics engine of Half-Life 2 (Havok) was also used in Max Payne 2. However, while the physics was mainly used for eye candy in the latter, the former integrated it into an essential part of the gameplay.