SOA benefits: too much reuse of reuse?

Silver bullet.

I think you're perched too high in the tree. You say "We eventually realised that entity relationships did not adequately address business logic". This is absolute rubbish. CASE tools can and do work and re-use does too.

One of the problems is lack of discipline and hiring cheap poorly skilled staff. I've worked with clients who've had this working and had good re-use of software, but it needs people to tow the line and not always be looking for short cuts and cost cuts. Poorly skilled workers can torpedo your re-use strategy because they don't understand how to write re-usable code. Project managers who cut corners can ruin it by becoming too project centric.

Another and bigger problem is the eternal hunt for the silver bullet by senior managers, which leaves organisation lurching from one silver bullet to the next.

SOA comes along and tries to plaster over the mess by promising to connect up all these disparate project centric "solutions". Of course putting garnish on a dogs dinner doesn't stop it being a dogs dinner!

I'm not saying SOA is all bad, just that it isn't any better than what we've had before and that the problem isn't a technology or methodology one as such. The problem is a management one.

We really do work in a fashion industry. We're like kids in the playground all chasing the latest shiny toy.

"Dad can I have some SOA?"

"Why?"

"All the other boys have got some!"

Circular Reasoning .... of CERN Concern.....MetaDataMatters

Tony,

I believe this Adds dDeeper Perspective .....Enhanced Perception .... QuITe Freely available and to All of an Inclusive Disposition. .... A Gift 42 Share/Spend/Give Back to the System.

Palo Alto hits AI Low Point ......a Trough.

By amanfromMars

Posted Saturday 8th March 2008 07:10 GMT

"Thumbs up because I believe the magic could still happen." ..... Xeroids Rule! By Fred Gumby Posted Saturday 8th March 2008 03:18 GMT

And CyberIntelAIgent AESThetans would Rejoice with Xeroids Rule, Fred, and posit that the magic ........ and I will be specific and and give you a particularly and peculiarly focussed rallying point for Innovative and Imaginative Fantastic Strategy Game Virtualisation .... Magical Mystery Turing ...... [and a Hoover through Servers can provide you with Reams of Support Information if you have no Access to or are Denied Access to Original Resourcing Source]

Of course, and I'm sure Ms Vandebroek would also agree, ... [and I wonder if she was disappointed at the lack lustre Second Life awareness/enthusiasm at Xerox or did she realise that the company was hers for the leading, given that the significance of the Virtual Reality World is missing from the company's DNA Portfolio.] ...... that the moniker Virtualisation is something of a misnomer given that IT Realises the CyberSpace Virtualised Programs whenever they are Transferred Back down to Earth.

The Virtual Space Environment, where Ideas and Advanced IntelAIgents Protocols are Constructed and BetaTested in CyberSpace for Seamless Replacement of Siloed and/or Subverted and/or Perverted Sub Prime Legacy Systems ........ the Stealthy Adoption and Adaptation for Survival of the Fittest for Future Purpose Meme/Methodology/Awareness .... is the NeuReal Head Office Environment of Today for Tomorrows' Needs and Feeds.

Miss climbing aboard that Train with a Ticket to Ride and you can watch all the Fun of ITs Fare from the stalls as IT takes you on a Helter Skelter of AIMagic Trip.

MeThinks Ms Vandebroek may have been talking to an Audience who were not nearly as Advanced in their Thinking as she was.

Perhaps someone reading this could forward it to her and ask her ..... for that would be at least three Interested Parties [thus cubing Potential for Powerful Currrent] ....... Thinking Advanced ........ and Mixing Ideas and Advanced IntelAIgent Protocols Creates A.N.Other Artificial Intelligence which is, when Inclusive of All the Best Agreed Protocols, a QuITe Alien Mutual IntelAIgents Service, 42 Lead Singularly Human Ignorance and its Arrogants, who would presently Play the World for a Fool just to Server their Pathetic Needs and Egotistical Greeds.

J'accuse ...... and the Fools on the Hill all know, who exactly they are, no matter what Mount or Mythical Figure they may Follow.

And if you want Delusional Arrogance in Spades, here is a Tale full of its Spin .... http://news.bbc.co.uk/2/hi/uk_news/politics/7284494.stm. ...... a Mole working for a Foreign State hoovering up Secrets for Sale?

Yeah .....Probably?

http://comments.theregister.co.uk/2008/03/07/xerox_vandebroek_parc/

Mmm an SOA story

You do realise that everyone outside the SOA/Enterprise Architecture community thinks your talking complete and utter bullshit?

Code reuse

Wow, almost sounds like you're describing UNIX, talking about having a bunch of little bits of code which can be chained together into a complete application.

All sounds so depressingly familiar

seen so many times hugely complex code where they have tried making it "reusable" by thinking of everything - and the complexity is why it never gets reused in other projects, trouble is they then repeat the mistakes in the new project

ReUse

At last, the bl**dy obvious is said.

The number of times i have looked at a site "standard" function and noted that only a demented 60 year old Algol programmer would write such an abomination....

/* noted that site standards are rare /*

At every site I have worked, each project wound up with its own "standards". These all worked well as does the project team as a concept and often in practice.

Any attempt to re-use functions, scripts, objects, whatever created more work than a fresh implementation, which is always what happened, ... eventually.

If agility ( substitute current buzzword to suit) is required, re-use is mostly a hindrance, unless you are working at the OS or GUI driver level.

IT because marketing droids and PHBs have too much coding clout.

ERROR

Buffer_overflow error in the module buzzword_detect. Core dumped. Please recompile writer.bin with the --debuzz flag to fix the problem.

Reuse just happens. But you have to do it the right way.

Let's say you write some code. Then, you (or worse, somebody in same team) need to do something similar.

In my experience, the first temptation is not to make the existing code more reusable, by breaking it in components, and using only the required component, or by making it more abstract and parameterized.

The first temptation is to copy-paste a huge chunk of code, and then to modify it in a few places to make it compatible with the new requirements. Most often than not, this is what happens, especially with inexperienced programmers, that barely grasp the concepts of OOP.

And, for a short period, this strategy seems to work, and many young members of the team start to think that copy-paste is a good thing: you can do it fast, you don't affect the original piece of code, so the initial developer won't get mad for ruining his work, and you don't risk breaking other things.

But this will come back to haunt you when you need to fix a bug, only to find out that you need to fix it not only in one place, but in the 100 other places where it was copy-pasted.

Or when you need to do a major redesign of the application, for example to change the theme on a web site, only to find out that there are tenths of similar looking, but different CSS, JavaScript, and template files to modify. That is if you are lucky enough to find any templates at all, because who needs templates when you can copy-paste an existing page and customize it every time you create a new web page.

So, yes you have to think every time you write a piece of code, how likely is that later on someone will need to write something similar. And if you find it likely to happen more than 3 or 4 times in the next 3 years, then you might as well plan for that.

Make the code reusable in the first place. Break it in many small classes or templates. Break the methods / functions in many small methods or functions, instead of a god method, 2000 lines long. Document it, comment it, and make clear its purpose, and that you feel that it should be reused, and in what way.

Someone, possibly you, will thank you later for your foresight.

However if you feel that a piece of code will most likely never be reused, you should document that as well. Then you can allow yourself the luxury of not caring about code reuse, and write the code faster.

You should still not create 2000 line code monsters, because you will have to debug or modify that code at some point, and it will be hell. Furthermore, in my experience, breaking the code into many small pieces and giving each a name, will make the code self documenting, to the extent that you will seldom need to comment the code.

And later on, if you are proved wrong and that code will need to be reused, it will be easier to reorganize the small pieces for reuse purposes.

And for god's sake, don't copy-paste. Or if you really have to, because the deadline is yesterday, document the copy-paste in both the source and the destination, and plan to refactor both code sections to something reusable as soon as possible.

Oh well, this comment is already to long. I should probably break it into multiple smaller, reusable comments :)

Excellent article and comments

This holy grail isn't the one you're looking for. Another 'll be along in a minute.

The laudable objectives of code reuse versus the constraints of real life: you can never see the *whole* picture; you will never have enough time to get it right; you won't always have the right people who understand what they're supposed to do. But that won't stop the drive in that direction with the aim of being able to replace inhouse/custom development with off-the-shelf components from a mythical services supermarket.

@Frank Gerlach

Bravo, bravo!

As a Structured Programming and design follower, I've seen code reuse tossed around for 30 years. It rarely happens in the corp. world, but open source and languages like Perl and Python with their app. libraries make it happen a lot more.

As a previous poster alluded to, short single purpose functions, with limited number of arguments, no globals, single entrance and exit, well documented args and returns and descriptions of what it is supposed to do, placed somewhere it can be found is the only hope for reuse. OOP is just too scary, as the high priests think the code is supposed to be secret magic.