Comment On Talkin' Bizness

 

Ugh.  Anything requiring speed should avoid BizTalk.  I've never met a piece of software that was a bigger pain in my side.

That's pretty enterprisey.

Actually, I didn't know Biztalk could do all that. Good to know...

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.

Would have been first if not for BizTalk. Argh~!

"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).

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.

I like the workflow...

sjees.

Alex Papadimoulis:

1. The page builds an EnterpriseQuery object. This object has, among other attributes, an ArrayList of search criteria and a placeholder for an EnterpriseResultset.


2. The page calls, via remoting, a serialization service that converts the object to an array of bytes


3. The page passes the byte array, via remoting, to another service that communicates with BizTalk

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

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?

 

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*

DisturbedSaint:

Alex Papadimoulis:

1. The page builds an EnterpriseQuery object. This object has, among other attributes, an ArrayList of search criteria and a placeholder for an EnterpriseResultset.


2. The page calls, via remoting, a serialization service that converts the object to an array of bytes


3. The page passes the byte array, via remoting, to another service that communicates with BizTalk

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

Isn't that where the BizTalk comes in? 

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".

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.

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

 

Anonymous:

can I request some good c++ or heck even some vb or c# or.. java.
 anything else please.

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!

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".

Anonymous:

how about stupid process in game development?
 got any good game code that need's to be laughed at?

http://www.advsys.net/ken/klab.htm

Download LABFLSRC.ZIP. Guranteed at least one WTF every line.

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?).

Bus Raker:

Anonymous:

can I request some good c++ or heck even some vb or c# or.. java.
 anything else please.

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!

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.

Anonymous:

how about stupid process in game development?
 got any good game code that need's to be laughed at?

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?

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.

13 steps in a class A enterprise application?  That's just not trying hard enough.

Alex Papadimoulis:

Anonymous:

how about stupid process in game development?
 got any good game code that need's to be laughed at?

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?

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?

Anonymous:

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".

Today's WTF reminded me of another JP line when I read your post:

(paraphrasing) "Goddamn, I hate this hacker crap!" (Samuel L. Jackson)

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!

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.

Where's the XML?

 

Not very "Enterprisey" without some XML.

The architect's name was Rube Goldberg?

And why would you want to use an ArrayList for keywords, when a HashSet has a much better complexity?

 

/Esben

Anonymous:

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.

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.)

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!"

*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....

Anonymous:

"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).

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.

Anonymous:

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).

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.

Satanicpuppy:

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.

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.

Anonymous:

Alex Papadimoulis:

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?

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?

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.

Anonymous:

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

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.

sinistral:

Satanicpuppy:

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.

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.

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).

sinistral:

I haven't heard of any non-JS AJAX, but maybe there is some.

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.

Good god.... that webpage design is a huge WTF in and of itself... forget the code.... damn....

Anonymous:

Anonymous:

Alex Papadimoulis:

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?

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?

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.

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.

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.

>> 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.

masklinn:

sinistral:

Satanicpuppy:

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.

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.

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).

sinistral:

I haven't heard of any non-JS AJAX, but maybe there is some.

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.

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.

Anonymous:

>> 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.

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.

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.

Tsk tsk, you misspelt "brillant". :)

Anonymous:

Alex Papadimoulis:

Anonymous:

how about stupid process in game development?
 got any good game code that need's to be laughed at?

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?

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?

Can you say Doom-3 engine?

BizTalk is only good for "talking" or "facilitating" communications between dislike systems, if you go further than that then it gets really messy...

Anonymous:

DONT WRITE YOUR APP IN "BIZTALK!"

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...

Anonymous:

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?

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.