Slashdot Mirror
What Gartner Is Telling Your Boss
Littlewink writes, "Esther Schindler's latest analysis reveals what Gartner is telling your boss at their annual conference. Excerpts: '"The future of application development is not about programmer productivity," said [Gartner analyst] Hoyle during the keynote presentation, "but in assembling functionality from components." [Gartner analyst] Veccio stated "Why would you ever code an app from scratch again? Why would you need to?"' According to Schindler (who does not 'drink the Kool-Aid'), Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often.'"
Basically they're just another rent-a-quote firm for people who buy their services
Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often.'"
Whatever they're smoking, it's worse than paraquat.
While about 1/3 apps I program are sort of cookie-cutter, a routine from here, a routine from there and a little glue, most are completely from scratch and have never been done before. The nature of things is change and change dictates writing new apps which handed data differently and produces information in a different light each time.
These people are analysts and don't know this???
A feeling of having made the same mistake before: Deja Foobar
Why would you ever assemble wisdom and business savvy when it's simpler and easier to assemble random quotes & concepts from popular seminars and "Best Seller" managerial books.
So, programmers have a choice between writing glue layers between different general applications, or writing a specialized application from scratch? Writing glue layers is not necessarily easier or less time consuming.
The best solutions to specific problems are going to be custom made, at least for a while.
. . . 'cuz Gartner gets paid by the "component" / middleware / toolkit / etc. vendors to say that.
No, really. I worry about the junk that comes out of Gartner. Like the outsourcing binge. Where I work, they have tried several ways to outsource (overseas) our work. Gartner was flogging this heavily and it seemed to become 'cause celeb'. The word we got from our managers was that it wasn't going to be allowed to fail. I'm pretty sure some people's careers would be damaged if it did, so they're going to continue to push it regardless of the results. This sort of 'tell us what to think' mentality is not going to help corporate amerika.
Please, someone tell Gartner Group to be a little less certain about their predictions. The mass of middle managers are afraid to do think anything that isn't supported by someone like Gartner.
Best regards.
Slashdot has managers?
Just like AI has been promissing us real AI for many decades, the idea of producing information systems by combining building blocks still has not become a reality yet. The whole SOA hype is just one of the many "build systems from components" hypes. My experience with building information systems by combining separate applications (and that is how most informations systems are build in practice) is that these systems often crumble to pieces due to mismatching data models. I sometimes get the idea that data modeling is one of least used methods for building information systems. I wonder why.
Those who can, do. Those who can't, analyze.
Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often.'
Excellent. I hope some PHB at a Software company takes this advice and runs with it. The resulting fiasco should be great for Gartner's reputation.
The theory of relativity doesn't work right in Arkansas.
Remember.. your CEO is just business object--- I set of components and business logic. His job responsibilities are just more components.
Any of these business objects can be swapped out and replaced willy-nilly as you see fit. If the CEO has too much work on his hands, you can simply run a process scanner against his position-- the process scanner will highlight the areas for improvement. Then you hire a new person and assign some of the objects to him.
Heck? Want to replace the boss? Fire him and hire a new object to assume the responsibilities. The transition is seemless.
Don't forget that you paid some consultants $1 million for this study, and these are the conclusions.
---
Look-- looking at things as components is a useful exercise for modelling. It's an easier way to get a "big picture" perspective without getting mirred in the details.
But it will only get you so far, because DEVIL IS IN THE DETAILS. Anbody who believes in such object-oriented drivel is certain to go out of business. Trouble is, the CEOs who promote this crap can jump from ship to ship-- not all of us can do that.
Asking "Why would you ever code an app from scratch again? Why would you need to?" is like asking "Why would you ever want to have a baby".
Sometimes it's the only way to develop what you need; sometimes it just happens by accident; and sometimes someone gives you one to look after for them.
You don't want to have a baby very often, but it's just as well that some people have them sometimes.
We're thinking about throwing Java out. It has the same problems with 'synchronisation' that C has with 'memory allocation'. You can't get it right all the time, it's too hard.
And Intel are coming up with these 80-Core chips.
A real lot of stuff will have to be rebuilt if we do. Hopefully automatically built from modelling tools. But there will have to be people, to resolve the defects, if it is to support the business.
Degrading the art and science of programing will have an adverse effect on the developer community,for after all if all i have to do in order to make an app is do a little copy, cut and paste ms word style..... Of course if this idea came from the management field, we could do the opposite....like this: "see we have developed a new algorithm for managerial decisions which will cut prices and increase profits for the company, their hardware requirements are not high and can work 7/24 without a corporate VISA..." and let's see them after that...
that managers belonging to the "Silver Bullet of the Month Club" will even read that far? I thought that books like this were for sitting on one's bookshelf, to convince your employees that you're working really hard to make everything better, not for actual consumption.
We're thinking about throwing Java out. It has the same problems with 'synchronisation' that C has with 'memory allocation'. You can't get it right all the time, it's too hard.
Just curious: What are the proposed alternatives that simplify synchronization?
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
i remember when turbo pascal and all the nice little objects were going to end having to write the basics, or when windows and common dialogs was going to save it.
same bs, different cow's ass producing it.
software always comes down to borrowing as much existing stuff as you can and building the rest. ime, very little from project a is actually appropriate for projcet b.
bah, back to coding asm in notepad.
-.no
"Why would you ever want to have a baby".
Damn if I know, but it's way to late to try to stuff her back in; I think she can take me.
KFG
"Why would you ever code an app from scratch again? Why would you need to?"
.net, no java), politics and empire building, and any number of other variables all come together to make the business environment so complicated that developers will be reinventing the wheel for years to come. Things like MQSeries or Oracle have gone a long way toward standardizing things. You don't cook up databases in flat files anymore. You don't (usually) write your own messaging systems by opening sockets directly. Things like the .net framework or j2ee mean we're not writing sorting algorithms anymore. But that just frees us up to work on other complex systems. And complexity is growing faster than these sorts of standardized frameworks can be created. We'll continue to use standardized middleware packages and other third party controls or libraries. But the business will always need custom solutions that build on those standards.
Assuming they mean business logic and not things like sorting algorithms, you had better have vast quantities of foresight to make that happen. As most other crud conjured up by these people, it sounds great on paper and when given to executive types in the form of powerpoint presentations, but in practice, it falls apart. Different programmers, different programming styles, changing business rules, mergers, new client requirements, scope creep, abandoned products, legacy code you're unable to get away from, new business standards (like we're a java company, no
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
"The best solutions to specific problems are going to be custom made, at least for a while."
Like frameworks or libraries
A project creeps in scope 1% per month? How do you even begin to make this assertion? What is the unit of scope, and how do you measure its creep?
What a load of creep, err, crap.
*blinking cursor*
But the biggest problem with code re-use is the human resources element, they caution. Hoyle pointed out that programmers are likely to say, "I can write you some of that. Reuse is for sissies. I'm a better programmer than they are."
WTF. Every programmer I know thinks writing stuff for reuse is much more difficult than not. The problem with reuse is that the writer of that component need all kinds of experience of the different ways the component could be used before they are able to make a decent reusable component.
Hey managers, if you have a programmer that said "Reuse us for sissies", you've got yourself a stupid programmer.
Spring? Swing? Struts? Xerces? Xalan? Hibernate? (forgive my Java-centric examples)
Frameworks for developing applications are indeed developing and maturing, and software architects are leveraging these components instead of building these things from scratch. Why would you rewrite Hibernate if it does all you need?
Lower-level code is getting more modular, but user expectations keep increasing. They want their web applications to be as robust and full-featured as desktop apps. The business logic unique to a customer isn't getting any simpler. No matter how many general components are available, there will still be tons of work in the custom realm.
This is the history of software engineering. More and more layers of abstraction are built on top of the basic AND, OR, and NOT operations that every program ultimately is made of.
I don't see how this is going away anytime soon. It's easy enough for someone to get up in front of a crowd and say "modules are the way to go, and programmer productivity doesn't count anymore" but assembling a complex application is a lot more work than putting together a few Lego blocks.
I'll never work for someone who is dumb enough to listen to crap like that.
So, let all the big companys buy into the bullsh*t. I'll continue to work for small startups, and we'll continue to out-develop and out maneuver the big dumb lumbering brutes.
Once a company get over 100 people, it's time to leave.
If you have a question about how the app you are writing is supposed to work, and you can't just walk over and ask 1 person, and have them make a decision, then it's time to leave.
Once developers are not allowed to innovate, it's time to leave.
There will always be startups. The pay may go up and down depending on the VC market at the time, but they will always be there, and they will always be better, more challenging, more fun and more rewarding places to work that some big company where the boss listens to Gartner.
-geekd
As the cost of computing drops, there will always be new problems that could not be economically attacked until the cost of the computation became cheap enough. These problems will not have a canned solution and someone will have to go off and build the application from scratch. As long as computing continues to get cheaper, there will always be new problems to be solved.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
endless tps reports killing development projects too.
I would imagine Erlang would be a contender.
Slashdot is proof that Sturgeon's Law applies to mankind.
You Linux people kill me. I could go on and on about the problems with all the differnt Distros of Linux. For every gripe you got about Microsoft I got one for you about Linux. Here are a few. Updates for some of the different flavors of Linux are an absolute pain in the ars. Then when you want to install say Nagios, it takes hours because you have to try and find all the packages and then you might not be able to install the one package because it is depent on another package and to find that other package you have to score around for hours. I can see using Linux or Unix in certain cases, but in no way is it ready for mainstream. I mean can you image your typical end user trying to run a Linux box! hahahahahahahaha that is funny!
Business is hard work and people are always looking for shortcuts. It isn't much different to the whole slimming/diet industry for fat folks. As long as there are people who want shortcuts there will be all kinds of management/software/business fads selling black belts, software components, agile development etc.
Engineering is the art of compromise.
"We need an inventory module for this project. Use the one from the MegaMess project."
"Yeah, sure, that should work. A little overkill, but it'll do what we need."
"Oh and it has to track the inventory by supplier's parent company and supplier's parent company's SKU."
"Uh....what?"
"Yeah, we get most of our inventory from local suppliers, but they all get it from the OEM. We need to use the OEM part numbers, with an indication of which OEM it is."
"Uh, but the MegaMess project tracked inventory by product group. It doesn't even use SKUs. And we don't need to report on SKUs for what we're doing, why do we need them?"
"Director of marketing wants to see a report broken down by SKU, and rolled up by parent supplier."
"I don't think we're going to be able to use the MegaMess inventory."
"DAMMIT! Just use the components we've already got! We aren't going to write any new code for this!"
Just junk food for thought...
The 80/20 rule messes up the reality of using components (whether it's EJB/SOA/latest cool thing). It takes 20% of the time to do the easy 80% of the work. Then 80% of the time to do the remaining hard 20%. Components give you the easy 80%. Which you could already do pretty quickly anyway, so you're really not gaining much.
Then you're still left with the remaining hard work, which probably got harder and will take longer due to the overhead of your component framework and its mess of configuration.
And that is totally ignoring the fact that it's very hard to find components to reuse anyway.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
You get everyone in a room.
You all agree that there is a problem.
You tell someone to X the Y to emit Z which will collapse the problem.
5 minutes later, the Y has been X'd and is Z'ing the problem.
The magic words made the problem go away. Quickly. So you just have to find the right magic words to say and technology will solve your business problems!
Hasn't this been covered in many, many Dilbert strips?
Spewing buzzwords seems to be an acceptable replacement for thought and knowledge in certain companies.
Gartner's advice is for enterprise companies. Not companies that actually come up with new products. For certain enterprise companies where software development is not a strength nor core part of their business, this makes complete sense. New companies are alwasy funded in silicon valley that write things from scratch. Then those new companies become big companies or are purchased by large companies :)
The analyst is captures the essence of American big-business, "Don't do anything new." Just remix something already on the shelf. It's better."
This is low-cost producer corporateThink. America cannot be the low-cost producer. So the obligation is to innovate.
But the wealthiest 2% can't stand innovation because it is a direct threat to their wealth. They go to Washington and legislate innovation away.
I left the environment that this analyst describes because it rotten. It rots the brain!
Now I work in a company where my superiors have the same disregard for this kind of thinking and we're doing well. The sky is not the limit though. They are small enough no competitors care, but definitely delivering value to our customers.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
The layer of people between the decision makers and the product makers exist in every industry, and in every industry there are far too many of them, so they must justify their jobs and salaries. Isn't that more important than innovation or efficency? To them it is.
We are all just people.
"I vividly remember the epic battles that took place when managers returned from TQM (Total Quality Management) training. The all had these purposeful looks of the new acolyte and a Franklin Planner under their arm. They cooked up Vision and Mission statements and tried to get everyone on the bandwagon. It was a trying time because most of the way we already did things were obviously the most efficient. Work under the gun a lot and you tend to find the shortcuts yourself. If anything we became less efficient until the whole clamour died away and most of us returned to getting it done the proper way."
And yet a lot of code isn't quality, and computers crash and people die. Maybe we need fewer "shortcuts", and more "quality".
They opine on techniques that have resulted in both success and failure, quote objective data, and compile their own trends and predictions. This isn't necessarily bad, but taken alone (and they price and market themselves as the only source necessary) can make for a myopic view of the world.
Their predictions are "poor to fair" in my opinion. Their influences worked badly at shops I've seen, which are more "good ole boy" than "hip entrpreneur". Their style to digest large amounts of trending information and craft a slick prediction does not make a process leader. In fact, it can make an environment seem "behind the times" as well as "constantly changing" since shops that get directed to perform changes based on Gartner papers too often switch gears to trends already fading.
Much of what they say is execu-craft-speak, without stating anything concrete at all. Only the style of the presentation and perceived caliber of the brand have influence. Plenty of other magazines try this too (see the cage litter "Application Development Trends").
Component-model designs, where change is encapsulated in replaceable (and OTS) pieces, has been a goal for some time. Software projects that slide scope cannot simply "be killed." The charge that programmers constantly find better ways to perform the same tasks is at the heart of the technology era: Programming itself is one of the tasks becoming better automated every day, just like the business tasks they code for.
Question: "Why would you ever code an app from scratch again?"
Answer: In order to avoid bloat, stability, performance, and security issues from using modules that are overly-used, overly-general and/or don't exactly meet your spec but are "close enough."
Best Example: Microsoft Office
You just blew out my buzzword detector. Expect a repair bill soon, Jackson!
What are the proposed alternatives that simplify synchronization?
(1) Software Transactional Memory, STMs. You write "int STM x=5;" and then one thread can do "atomic {x+=1;}" and another does "atomic {...;x-=1;...}" and the runtime+compiler magically make the atomic blocks execute atomically. This is different from Java synchronization blocks because these can be executed optimistically in parallel and because they never result in deadlock. People therefore say that STMs are "compositional" in a way that locks are not. The key is that the compiler/runtime know how to roll back an atomic block. This kind of atomic block interfaces very gracefully with SQL transactions.
(2) Message-passing. Academically it's embodied in the "pi calculus". In web terms it's embodied in the W3C "choreography" working draft. In practical terms it's embodied in Microsoft's Biztalk and in Ericcson's Erlang language and in Microsoft's new Robotics SDK. It's also a little reminiscent of "tuple-space" operating systems. The idea is that threads communicate by sending messages to each other. It's still possible to deadlock (e.g. if one thread waits for a message that will never come) but these errors seem more rare in practice. Also it's easier to analyse for this kind of problem at compile-time than it is with synchronization.
(3) Write the code in a functional way, so the compiler infers parallelism automatically and you don't need to. Or, take existing C code and have the compiler infer dataflow in it, then proceed as above. e.g. WaveScaler at UW, I think. Many people think this is the best hope for the coming world of multi-core chips.
In some ways I agree, 'Not Invented Here' is a real problem, where a department wants to come up with it's own tools, instead of using a shared set of tools.
There are some things you shouldn't do yourself, and some things you should.
Janitorial staffing, for example. Should each department in a building owned by the same company hire a seperate company to clean their offices? Obviously not. But should they all be required to use the same text editor, no matter if they are laying out advertisments or writing C++? I think not.
Both of those cases are obvious, but what about the text editor used by programmers in different departments? Unfortunetly, usually the person in a position to make company-wide policy does not know enough about a specific job area to make reasonable blanket requirements, requiring all developers to use a particular editor, no matter if they are developing for Windows or Linux would be like telling all janitors to use the same floor cleaner for office carpets and the parking garage.
In the Janitors case, since they are often outsourced, or at least a seperate department, they have their own structure which tells them what to use where.
In the software developers case, having a seperate structure to set standards can lead to problems when the Project manager's directions conflict with the standard practices; the project manager's desires usually take hold, because they are in direct contact with the developer, while the company standards are less strictly enforced. This leads to the effective death of the 'standards'. After this happens a number of times, everyone loses faith in anything labeled a company standard, and since they expect no support, they don't even really try to adhere to them.
I don't have a solution, as once an organization reaches this level of NIH, any efforts to re-establish a standards process are doomed to fail.
I've worked with this model for ten years already and there are advantages and disadvantages. Unfortunately, it's rare that you can find either a management team or a software development organziation that understands either.
The component model works reasonably well for the Generic Core Business Functions (i.e accounting, human resources, sales, etc.), however only to the exent that you can use Off The Shelf Functionality. If your requirements are unique (or you think they are) you end up with a full blown development project on your hands anyway (with associated headaches and expense).
If, on the other hand, the requirements you are trying to address are part of the Value-Added Function that your organization provides to it's customers, you had better be willing to invest in creating some real value for the customer. If you spend a couple of months integrating off the shelf components that can provide the same value, you're not likely to be in business long.
Killing projects early for the Right Reasons is simply good management but the need to do this is usually an indication that there is something wrong in the organization itself. If you are part of an organization that does this frequently, the governance process or the development process is broken or both. Flee with all due speed.
Yeah! Like dashboards.
And Intel are coming up with these 80-Core chips.
The 80x86?
It's not like Gartner is the only company in the industry telling companies to explore sourcing (offshore and otherwise). Pretty much every venture capital firm out there today has a policy in place that requires the companies they invest in to have an offshoring/sourcing strategy. There are many reasons why offshoring, when applied correctly, makes great business sense. So to suggest that it's big, bad Gartner whispering in the ears of corporate America that's causing the outsourcing trend is overreacting a little bit.
It seems like most of the advice Gartner dishes out, with its "magic quadrants" and what-not, is about which products to buy.
Breakfast served all day!
The "components" snake oil has been around ever since Eli Whitney duped Congress with a faked demo in 1808. "No one realized it then, but Whitney was faking it. He'd carefully hand-crafted each part so they'd fit together. Whitney sold the government a huge contract for four thousand muskets. He took eight years to deliver them and then the parts weren't interchangeable after all."
But, you will say, they eventually did get it to work. True. But "software components" have been advertised as the cure for what ails software development since about 1989, and I haven't seen any evidence of a vigorous market in useful software components.
Is your company's mission-critical software written in VB using ActiveX controls obtained from a dozen different vendors? I don't think so.
Even as basic a component as the standard C library can't be trusted. Circa 1998 we had our product, shipping for four years, suddenly develop a very obscure bug. It turned out that the vendor's C library had a faulty implementation of strcmp. It was optimized in an oh-so-clever way that was intended to insure that as much of the comparison as possible was made four bytes at a time, with bunches of special cases for various string lengths and memory alignments. It had worked properly until some code changes put the strings to be compared at different memory locations than they had formerly been, and then under some particular cases if the non-matching characters happened to be a certain memory locations modulo 4, strcmp would return -1 when it should have been returning +1. I reported it to the vendor, but we had to ship--and so, well, I wrote my own implementation of strcmp. A dead-simple implementation that did the byte-by-byte comparison in the obvous way. And lived happily ever after.
The vendor never did fix strcmp, by the way.
"How to Do Nothing," kids activities, back in print!
We've been doing it for decades.
What's needed is a decent standardised easy to code to data bus and yes, a standard data format. Like Unix stdio but network wide. There are too many proprietary competing systems at the moment.
Cue xmlBlaster or other Message Oriented Middleware and Rosettanet/other data definition standards et al. Why hasn't it been happening? NIH, ignorance, laziness, narrow focus.
Deleted
n/m
I'll grant that much of this article is horse crap, but it's always disappointing to so see how vehement people become in their reactions when their livelihood is threatened. It's a shame because they are so busy defending themseles they can't take the time to find out if there is anything worthwhile being said. I bet 85% of the people responding haven't even read the article. Of course that's typical Slashdot...
Ok, im game, in concept. But if you kill off all your developers, who is going to code those resuable components?
---- Booth was a patriot ----
Software isn't a pile of components, it's just a bunch of *glue!*
Windows Vista?
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Re-use when possible, re-code when sensible - that should be the baseline for both managers and programmers.
For programmers its simple to put into words - if you have programmed a function to resample colour images and now you need a function to resample black and white images, just use the colour image function.
As for managers - if you discover you have three projects to manage the time shedule of section A, section B and section C - tell one of the teams to make the software generic enough to manage all kinds of time shedules (including those of sections A, B, C) and reassign the other two teams.
But if, in the above image resampling example your function needs about twenty times as much time as a function specialized for B&W imaged would need and is used constantly, you should code a specialized function, if performance would take a too large hit.
+++ MELON MELON MELON +++ Out of Cheese Error +++ redo from start +++
I vote for 3.
..... there's 10 years work for a lot of brains right there.
functional programming will one day be the only way.
but, somebody's gotta go write all those compilers
What the quote should have read is...
"'You can improve productivity by 20%', Hoyle advised, 'by killing management consultants when you should: which is early in the lifecycle.'"
You write "int STM x=5;" and then one thread can do "atomic {x+=1;}" and another does "atomic {...;x-=1;...}" and the runtime+compiler magically make the atomic blocks execute atomically. This is different from Java synchronization blocks because these can be executed optimistically in parallel and because they never result in deadlock.
Why would you want to use two threads for something trivial like that?
I think the the basic idea of using tried-and-true-and-robust components is a good one.
It's why I prefer coding my projects in Perl. The components available from CPAN make
practically any task quick to develop and robust.
In a band? Use WheresTheGig for free.
I have to agree with this. Well most of it in the terms of proper process engineering and planning and using existing code.
My comment is going to sound windows centric but its common in the bussiness world. The reason Java is so popular is not because its a great language that is cross platform but because the java api's in javadocs are huge. There is a method for about anything you can think of. MS also advertises dont code it, include it with teh saying we develop the code so you dont have too.
VB is a very rich environment with alot of tools for very rapid rad. Yes the language is not too hot before vb.net took over but it saves alot of money with development time.
Development is expensive and error prone and using code can save development time and offer great integration with the platform your on. Linux is finally catching up in this area and a code rewrite is like a blueprint rewrite for a big housing development firm. Its expensive and slight modifications to an existing blueprint is much cheaper and less error prone since all teh bugs have been worked out.
Also I do disagree with the last paragraph saying you should kill projects. Good planning proper mrp and ROI with process engineering can eliminate such dead weight before they exist. Anything with more than a 3 year timeframe needs to not be developed.
Also for those who hate engineering being lost it is not being lost at all. More likely MVC and process engineering is what is needed and not computer science for 90% of real world problems. Schools need to teach more project management and planning and less calculus for students who want to be professional programmers.
http://saveie6.com/
Wow, I smell a new Dilbert strip in the making (although it's probably already been done).
Next time I dine out, I won't ask for chicken or fish or a salad, but, instead, a "big serving of excellence".
We've been trying to maintain a product developed in-house over the last decade or so. Wouldn't it make sense to buy a GUI toolkit, they thought, so we can concentrate on our core competency? Sure, except we had to stay on Solaris 8 when everybody else was using Solaris 9, and then 10. The company that provided the toolkit got sold a couple of times, and is now part of some consulting outfit you've never heard of. They have two guys in Bombay trying to port it to newer platform versions, but they don't really test it, so we've had to take on that additional burden. Without the source code. Sometimes they're busy working on other stuff, so they don't get to our complaints for weeks. We're terrified they'll go out of business before we're able to do a rewrite.
Of course, Oracle stopped concentrating on the Solaris 8 drivers, so when we called for support all we ever heard was "upgrade to Solaris x and install the newest version". Would that solve the problem? Who knows? We can't do it anyway because of the GUI toolkit.
Now we want to move that product to Linux, but the GUI tool in question doesn't work on Linux at all. They're trying to get it working on RHEL 3, while we've just moved our other tools to RHEL 4.
You wan't to make a brittle tool and take the blame when the enterprise can't upgrade the desktop OS because a key component vendor just went out of business? By all means, knock yourself out. You can commiserate with one of our groups that's still running Java 1.1 because a piece they bought from a now-bankrupt vendor won't run on a later version. The more third party vendors you have, the worse it gets, too. You can get circular dependencies that prevent you from upgrading anything without a total rewrite.
Me? I'm not writing everything myself, but I use OSS whenever I can. After the number of times we've been burned in recent years, if you work for my company you'd better have a damn good reason to bring in third-party vendors. We're pretty much down to Java and Oracle as the only easy sells for new projects.
You can put arbitrarily large blocks of code inside the atomic{...} blocks. I indicated as much with ellipses. You can also nest atomic blocks. Also an atomic block can contain the statement "retry()" which rolls it back.
The STM machinery still needs to be able to roll-back out of an atomic block. This rules out certain code from appearing inside the atomic block, especially side-effecting code.
All STM platforms allow code that manipulates "transactional" heap variables, i.e. ones whose side-effects are logged and rollbackable. In these systems the idea is to use STMs mainly for concurrent data-structures, eg. queues and hash tables and so on.
Some platforms also allow side effects on transacted resources, e.g. a transacted filesystem or webserver or database.
Other platforms also allow side-effects due to file I/O: they log the inputs (so as to resignal them in case of rollback) and buffer the outputs (the ouputs only commit to disk after the atomic block has completed).
Thats so 90s... its the component market place model (later called web services market place). But like every fad its value its higly exagerated
We have a administrative software bussines that estarted with one big client, but have problems finding other big enought bussines so we cut the suite in parts and now we sell it with custom modules oriented to especific industries... one third of the sales are done by third party developers because all our interfaces are documented and designed for public extencion. we have done by request developer clinics for clients that want to integrate and extend themselves the custom sistems
Its this news?
The IT Market can be considered, in gesalt, as being subject to the S-curve with the year 2000-2001 ( the Dot Com Crash ) as its inflection point...
y =evolution_of_the_it_market
http://www.realmeme.com/roller/page/realmeme?entr
What does it mean, really? That coding is a low-value activity and perilous to your economic health over the long run.
OK, that makes more sense. It sounded like very low level concurrency from the way you described it.
http://opie812.blogspot.com/
Because the reason lots of people's jobs are threatened/are leaving is because people with no stake in and little knowledge of the processes that go into doing any variety of things are taken as gurus by people who also don't know better, and who care about nothing other than that they want to make money now and don't intend to be around when the crap hits the fan.
These people enable the moronic management that has felled many a company. As long as there is money to be made in prolonging a problem, they will be there to help and to bill. The fact that there may be diamonds in the steaming piles of crap they continue to release does not justify their existence, nor any regard for their opinion.
Over their lifespan, has the Gartner group been right more often than could be accounted for by chance?
What are some examples of them being right?
We are living a land where managers are rewarded for cutting jobs, then rewarded again for selling off units that are failing because they don't have anybody working for them.
This is another picture of the ugly underside of a capital-driven economy. Management reacts to the behavior of a bunch of coked-up day traders and brokers who are shooting craps with other people's money. Because "The Market" likes it when jobs are cut, managers cut jobs. Any way they can dump a few more workers is good, they think.
But the fact is, somebody's got to do the work. The managers certainly aren't going to do it because in the process of getting their MBA all they learned was that if you bought an 8-ball, and sold some to your friends after stepping on it a few times, you could get high for free. So now they're middle management and they don't know fuck-all about actually making something, or providing a service besides oral favors for their bosses.
I know this is heresy in this day and age, but it really is worth the few hours it takes to read Das Kapital. Not that I want to see a Marxist system here (or anywhere, really), but it's worthwhile to know how capitalism looks when it starts to fall apart. And falling apart it is, make no mistake.
Greed has brought us a bloody war in Iraq. It's brought us a middle class whose debt is increasing as they are told they're better off. But the only ones that are better off are the credit card companies.
Come on, let's have a show of hands: Think back half a decade. Think about where you thought you'd be five-years' hence way back then. Have you made it? Are you better off now than you were? Chances are, that unless you are in the very highest levels of management, you are barely scraping by. Sure, you've got an Audi, and a hi-def TV to watch Dancin' with the Stars, and surely your $250 a month cellphone bill is evidence that you're making progress, right?
This year, Americans now have a NEGATIVE savings rate. When it comes right down to it, that's the surest sign of the direction of an economy. How many of you pay off that credit card bill every month and put a little bit aside? Oh, and your retirement account at work doesn't count because that's going to disappear, Enron-style, long before you're able to use it.
No, you really should take a few hours out of your sodden, beaten-down lives and read Das Kapital. And you there. You, shaking your head with the know-it-all smirk. Read it sober.
You are welcome on my lawn.
http://www.paulgraham.com/ in his essay Great Hackers
http://www.paulgraham.com/gh.html :
Hackers like to work for people with high standards. But it's not enough just to be exacting. You have to insist on the right things. Which usually means that you have to be a hacker yourself. I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you're not. And the second could probably be condensed into two words: give up.,/i>
Graham
Linux - Fast Pane Relief
zero here baby! just buy more windows licenses, sql server is the best of breed, windows 3.1 rocks, treat IT like a stock portfolio
hilarious stuff, and people PAY them for it. gotta give them credit for that.
Here we go, 500 comments about how management doesn't know anything.
Stop by my site where I write about ERP systems & more
"I could go on for pages, but I think you get the point."
Yes "I" understand, but considering how many times I've heard the OP's complaint. I don't think "they do". Everyone wants Paperwork, Politics, and Process to be someone else Problem. Until the Consequences, Crash, around their Craniums.
We're thinking about throwing Java out. It has the same problems with 'synchronisation' that C has with 'memory allocation'. You can't get it right all the time, it's too hard.
Or maybe you're just a moron?
kill development projects early, "and often," he said, "if your failure rate is high." You can improve productivity by 20%
By killing all of my projects, I'll have a failure rate of 100% but I'll do it 20% faster. Awesome!
Thanks, Gatner.
Friends don't help friends install M$ junk.
So while you're managing your application portfolio your user base will be writing applications with Access and Excel like they used to. All this does is push development off IT and on to the users. So instead of having all your apps with a common front end (web browser) and a common back end, like SQL Server, you'll be back to the linked spreadsheet house of cards and an application portfolio of who knows how many different vendors.
Total insanity. But Gartner packages in terms managers like to hear. The higher ups like managing their portfolio, like thinking they're savvy investors. They want to think managing IT is easy. It's just like managing a stock portfolio. No hard decisions, no struggle to understand anything, the Easy Button for IT.
Notice they're not trying to sell the IT department on this bullshit. Because they'd shred them like a shrimp at Bennihana's. That's another unfortunate trend I've seen. Bypassing the IT department and going right for the higher ups with pre-packed PR inspired, advertiser-controlled-media conventional wisdom.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Sounds exactly like one of those EA horror stories a while ago. Game companies develope for 'future mainstream' hardware so they develope on cutting edge tech, problem is they don't put too much effort into potential compatibility issues and focus more on the eye candy. Game companies are also notorious for working under 'creatively chaotic' conditions.
;)
I wonder how games will look like that are written by anal-retentive accountants..
And when you gaze long enough into the code, the code will also gaze into you.
We're thinking about throwing Java out. It has the same problems with 'synchronisation' that C has with 'memory allocation'. You can't get it right all the time, it's too hard.
Is there already something in mind if you do? Some kind of CASE tool with modelling that you mention?
rd
All well and good when it comes to more cores except that most OS's don't let threads from a process wander around and run on other cores. Way to much overhead to get all the necesary process data out of cache layers to to be accessed by other cores.
But this type of IT organization is not limited to games. I work for a very successful business equipment solution company, and it used to be almost exactly as the GP described. I say Used To because the top brass finally realized that IT was blowing money like crazy. Now they have an 80% turn over rate in 2 years on the network side of the house, 30% on the apps side, budget cut backs, staffing cutbacks, and all round low moral. I recently wrapped up a pair of BSs in IT and Technology Management. I've been working hard to implement project management procedures, and get some kind of order in the shop, but my supervisor is content in code & fix mode, and my manager is 3 years from retirement and has no idea what IT Alignment is. And this has hardly been limited to this company, I have worked for enough organizations to know that this is the more common approach to IT, not the exception. And that is why I'm trying to move from Code Monkey (tm) and Project Management.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Gartner is a joke. The only people I know who take them seriously are business weenies who don't know any better. I have been hearing this stuff aobut componetized software for years and it still isn't true.
You know, I think some commenters here are too eager to toss the baby with the bathwater here. Gartner endorses reuse, Gartner sucks, therefore, reuse sucks.
Uh, no.
You would be dumb to not ask what third party components, libraries and frameworks could help with your project. While is it really unlikely that you will just glue a bunch of stuff together, and volia, application, it's just as unlikely that there isn't some library, framework or application that you could reuse to make the application better, or easier to perform a certain task, etc.
Also, reusable development is important; Sometimes, it's worth the effort to put in the work to make a part of system more flexible, more reusable. Sure, it's may not the most agile thing (just refactor, rewrite, and improve until, um...) but sometimes it is a win.
I think it is better for programmers. It requires more training, more skill to do reusable programming than one-off systems. It's not like you can farm out the "glue code" to the cheapest bidder. I didn't read the details of the Gartner report, but reuse doesn't save you labor, allowing you to do that same with less (less skilled programmers, less programmers) it allows you to make the most of out the talent you have. That's why reuse matters.
How much can you invent that never existed before with components that already do...
Some, granted... but nowhere near it all..
What a lot of us as IT professionals who got into this industry because we loved to code forget is that, unless you're working for a company whose product is software, coding is only a means to further the goals and maybe the profits of the business. I work for a big financial firm, where the IT groups exist mostly as a cost center. In this context, reducing new development and maximizing reuse of existing code is a Really Good Idea. Reuse is a difficult idea to turn into reality because of egos, lack of foresight, overextended resources, and numerous other roadblocks, but it is not impossible.
While we have a dedicated reuse department, their output has been of limited utility. What I have found to be the best methodology is to *always* code with reuse in mind. So, when you are presented with problem X, don't just solve problem X, solve for the space which problem X inhabits. Create a contract between modules which allows multiple problem spaces which have inputs from the same universe of data to share that information in a way which is divorced from the business objects which provide that data. When the project is over, migrate those modules which have proven usefule to a separate project. The next project you work on can then use these modules and improve on them. And, of course, provide thorough and easy-to-read documentation for the modules so that others a) are more inclined to use your modules and b) don't sap your time with questions.
I built a supplementary Java web framework using this method which is now the de facto standard for sites within my company. And, just in case anyone is wondering, it does not replace or overlap with Struts, the apache commons libraries, Spring, or any other available framework, and integrates with them nicely. It solves mostly for common business problems, and is extensible (via interfaces) so that hitherto unforseen problems can also be solved.
Another major advantage of reusing code is the benefits it affords in terms of long term supportability of your applications. In a large IT department, support is one of the most time-consuming but critical functions, and the less differentiation there is between applications, the less knowledge there is to acquire and disseminate.
I don't think Gartner is saying "Don't write new stuff! Everything you need can be bought!" They're saying "Be efficient!" which means, sometimes, taking a little bit longer to write one application so that future applications take less time, meaning quicker turnaround for business needs, which is the whole function of software development in most companies.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Perhaps Gartner should do us all a favor and take a collective squat on the cosmic utensel.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Gartner only tends to endorse the products, services, and philosophies of it's own customers.
In general, I think it's a really bad idea to let business analysts dictate development methodologies.
I once worked for a company that hired a Gartner analyst to prepare a report recommending a development methodology and architecture. The company didn't believe that it's own employees knew their own business better than anyone else. As the designated liason for this analyst I quickly reallized how incredibly CLUELESS this analyst was about the technologies he was supposed to be an EXPERT on. I ended up writing the entire report for him. He ended up handing that report, with minimal editting, to the executives, whom in turn handed it back to me as the "official corporate policy". I later found out that the company paid $50,000 to Gartner for the report that I wrote for the clueless Gartner "expert". That was more than half my annual salary at the time.
Gartner is worthless!
Agreed.
More generally, I've recently been doing a lot of reading about the history of the U.S. financial markets in the mid to late-19th century, and there are a lot of parallels with recent history, although the timelines today are significantly compressed versus what they once then.
Over and over again, after a major technological development, there exists a period of -- for lack of a better term (and why not, it's a good term) -- "irrational exuberance;" a bubble. And then the bubble will burst, which depending on the severity of the bubble can mean a selling panic, and then things will even out and start climbing again towards the next bubble. This happened with canals and canal bonds, and then again with railroads. (Actually railroad stocks bubbled and burst several times over; you think people would have learned the first few times.) I'm sure if you look, you can find other parallels after periods of revolutionary technological development.
Computers and the internet, looked at as another form of infrastructure improvement (just as the canals were, and the internet, and to a less dramatic extent highways), followed the same pattern and created the same bubble and burst. Now that it's come and gone, we can start the real work, which is using the new technology to actually do productive work. The gains of the market during the bubble weren't real, but the ones made during the less dramatic climbs between bubbles are.
The reasons for the bubbles are not really financial as much as psychological (if you can separate the two). They're driven, predominantly, by greed and non-rational thinking: people get blinded by the idea of returns and pour their money into something that can't possibly continue forever, and each time when it crashes, they act surprised, as if their situation was somewhat unique.
The Dot-Com crash wasn't unique. Enron wasn't unique. Sure, the absolute values are bigger, because the economy is bigger than any time in the past, but the pain isn't new.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
They fail to appreciate that The Defining Characteristic of software applications is that they interact with each other and other resources (employees,customers,etc) in complicated patterns
Comparatively, stocks are just abstract financial instruments representing fractions of a companies value. They don't interact. They just sit there and keep representing their particular fraction of their particular company. The underlying companies MIGHT interact, but this is generally not the norm and rarely the most significant aspect of a stock.
I've always found that the best people to manage programmers are experienced programmers. They understand the importantce of revision tracking, documentation, etc, etc. They also understand getting actual code out the door. I think the most frustrating thing as a programmer is beaucracy for beaucracy sake. When people don't understand why you want revision tracking. Then you'll end up with revision tracking that probably isn't effective.
If an officer ever threatens to taze you, say you have a pacemaker.
Because management input into process design is so illogical that taking a poor, innocent well working and debugged package of code and exposing it to such idiocy is utterly futile?
According to Schindler (who does not 'drink the Kool-Aid'), Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often.'"
Who buys Gartner reports? Coders, or managers of coders that don't trust, don't like, and can't manage coders and are looking for a way to be "empowered"?
My oh my, how fast a mystery is solved.
That being said, I've not written any code for customer, vendor, employee, or other "people/places" type application master record management for more than five years. I got tired of doing that, and wrote it into a single, logical, flexable and optimal SQL (MySQL, MSSql, Oracle) back end and a PG for the front end. Insert lables, move fields around, activate and deactivate fields as needed, chop out the fat, and it's done.
One of these days I plan to start a source forge project with the code, but I'm too busy fending off Gartner style management to have time.
I've got a manager that so fsck'ing clueless right now... nevermind. I'm going to my happy place for a bit. Note to self: Never agree to work for a place that puts in "managers" for coders and sys admins that never coded and were never sys admins....
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
All these consultants bandying their 'best practices only' approach make a fundamental assumption that processes can be lifted and plonked anywhere. This is an extremely narrow assertion, and not in any means all encompassing. Many unquantifiables such as culture or internal capabilities get in the way. To put it another way: Dell's logistics weren't based on observing and emulating WalMart's processes. They knew what their competitive edge was going to be, started from scratch and decided 'nah... we can do better'.
IMO the modular approach is only good for generic backoffice stuff like accounts and inventory. But I doubt it'll help your company's 'special sauce' - you need radical approach and (suprise! suprise!) intelligence for this - it's useless except as a baseline from which to develop things from scratch. So: if I want to make sure my generic apps fulfill their generic roles, yes - I'd use modular software to try to do it, and get it done faster. BUT if I want to make a real difference in my apps, I'd certainly do it from scratch.
asm ??? notepad ??? I heard the same silly story in the late 70s when I was coding assembly on an IBM 360 mainframe and using punched cards. Some things never change, it might have been Gartner making those predictions too. :-)
I've heard for over 20 years that "soon" there won't be a need for programmers, since you will just be able to make applications by putting components together.
This appeals to managers, since having programmers around is a pain. They're expensive, unreliable and act weird.
It will of course never work in reality. Anything interesting enough to be worth doing will be hard enough to get right that you need an actual programmer for it. And programmers have been putting components together almost since the dawn of programming, it's just that some people don't know that.
'"not about programmer productivity," said [Gartner analyst] Hoyle during the keynote presentation, "but in assembling functionality from components"'
That's the kind of stupid "surprisingly clever" gibberish Gartner sells to bosses around the world. Assembling functionality from components, or "code reuse" is programmer productivity. "Buy instead of build" is another 1980s "breakthru insight" that practically every programmer uses, whether their boss realizes it or not.
Even C programming, which practically always calls an API, is assembling functionality from components. Unless you're programming in assembly without an OS, you're not "programming from scratch".
The continuing thriving of Gartner and the survival of businesses that consume their drivel is more testimony to the irrationality of economics. Any rational system would have increased boss productivity long ago by dumping any who wasted any time learning to be clever from Gartner.
--
make install -not war
Gartner urges managers to consider better process control
Which is why managers are lying rat fuck incompetent hairpieces.
Part of this discipline is 'killing development projects early and often.'
And firing everyone in order to take their paycheck, thereby destroying their career, education and home. Wouldn't have to cancel the project if you didn't approve it in the first place. There's cake in the conference room you lying asscrack molded-ass air-conditioned rancid crotch.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
1) Hire very clued people, only, and equip them appropriately; 2) Treat communications with the same cleverness as exceptionally good code 3) ???... 4) Profit !!!
Do not mock my vision of impractical footwear
Lego-like building blocks, high-level-languages, and reuse have been promised over and over for three decades, perhaps going back to COBOL's birth. It is a vendor trick that keeps on trapping each new generation. It is like a turist stop which sells Aztek calendars, statue of liberty's, and eiffle towers (all "made in China"). Hooks 'em everytime.
Table-ized A.I.
We need an "IT vendor-speak" version of Dilbert's Mission Statement Generator.
Table-ized A.I.
The 8080 actually.
I can throw myself at the ground, and miss.
And any day now, Architecture and Carpentry will become obsolete, replaced by manufactured home/office "assemblers". Such Assemblers will have Lego PhDs and all manufactured units will be made out of legos; and not any of that new Mindstorm crap or anything. Just the most basic collection of: 1x1, 2x1, 2x2, and 2x3 pieces, plus an infinite supply of the big green ground panels.
Buhahahahhahahhahhahhahaahahahah!!!!! HERE THEY GO AGAIN!!!!!
I'm writing software for 15 years. And I already lost count of how many times I was told that crap and that "tomorrow" I would be among unemployed, since even idiots would be able to create software using tomorrow's modular platforms. That tomorrow is yet to realize.
I was working with asm/pascal 15 years ago - and were basically rewriting applications from scratch: for new platforms and for new performance requirements.
I now work with C/C++ - and basically rewrite applications from scratch: for new platforms and for new performance requirements.
What'd changed? NOTHING.
Would the idiots ever learn? As computer industry develops and grows - so do requirements for computers. 15 years ago nobody expected to have affordable real-time 3D graphics or on-line simulation algorithms or real-time video encoding. Now we take that for granted. As old fart, of course, I cannot even imagine what would be capable computers in next 15 years - but all that would be possible because of abundance of cheap HW performance and I hope more intelligent software. Not because we would have such performance - but because I'm sure there is and would be ever growing demand for it.
e.g. some AI guys might tomorrow implement autonomous OS which would be voice/etc controlled. So you would be able to plug your photo camera into computer, say "Grab all new photos" and (miracle!) it would do that. Then say "If there are more than N gigs of new photos burn me them on disk as photo album.". Etc. Voice recognition + intelligent interpretation of commands + AI personalization - are tasks not yet possible for computers both hardware-wise and software-wise. NOW. How well fit modern algorithms and applications for tasks in such environment? They are completely unfit. So when development would come to that point - we software developers would have to rewrite all the components and blocks to fit well into new platform/OS/etc to get most out of it. IOW, do not put your GCC aside just yet.
All hope abandon ye who enter here.
who is this gartner person anyway, and why do you all hate the sombitch??
Trying to avoid side-effects as in functional programming is a good start, for ANY task.
Message passing is also nice, as it decouples components. There's not just pi-calc, but also Hoare's CSP. Both have languages built on top of them, and for message-passing in general there's stuff like Erlang.
Ten of of ten for stating the blindingly obvious, reuse your code. I would have never thought of that until I read it in Gartner. Reminds me of when CASE, OOP, Agile methods, rapid application development (RAD), Component Based Development (CBD) methodology, flavor of the month, methodology were all the rage.
This kind of 'research' appeals to the CEO because it promises software development at no effort and using under trained and underpaid staff. IF the CEO wan't to know about software why don't he just go downstairs and ask his own people. Firms like Gartner remind me of theatre critics. They can describe how to do it, they just can't do it themselves.
I once worked for a multinational 'consultancy' who advised fortune 500 companies on how to improve. Well their entire Intellectual Property consisted of a Win2000 network with all the records kept on PowerPoint documents. A bunch of shared folders and a template for naming the document ppp.ddd.uuu.nnn.ppt. That is project, department, user and docname. Dowstairs they kept the accounts on a vax and a bunch of company reports on scanned pdf files.
What I couldn't figure out is how such ignorant people could advise anyone on anything. But then again I have worked in places where the department head sends his own software people on leave and then hires a 'consultant' to design something so he can present this to his boss and pretend he done it. Excuse me, I have to go upstairs as the CEO want's to read me stuff about 'agile methods' out of a magazine .
davecb5620@gmail.com
...of why present-day (post-)Marxists have mostly dumped the working class schtick and are now focusing on ethno-pimping and pointless language debates in English departments around the US.
After all, "You have nothing to lose but your Audi, hi-def TV and your $250 a month cellphone bill" is not really a winning slogan.
"I bet 85% of the people responding haven't even read the article"
..
.."
I stopped taking notice of Gartner and the like a long time ago
"Linux is still not ready for widescale deployment on the desktop, according to analyst firm Gartner"
"Would their respect for Gartner's advice change if they knew the firm is indirectly owned by dozens of big-money investors who control some of the same companies Gartner evaluates?"
".. the Gartner Group (Framingham, MA) estimates that the total cost of ownership (TCO) for a networked Windows 95 PC is $9784 a year
"Gartner believes that most of the Linux shipments will eventually have illegal copies of Windows installed--a fact that makes Linux's seeming dominance of this market somewhat misleading,"
was Re:Feeling threatened?
davecb5620@gmail.com
There are two lines of thought to answer "Why would you ever code an app from scratch again?" - one is simply that if you're doing something worthwhile and innovative, there IS NO OFF THE SHELF solution. If you can buy the solution, is your app doing anything that isn't already being done? The other is tying yourself to a vendor. I know anything from Gartner is designed to promote this, but in the real world, do you want your killer app at the mercy of a vendor who can drop support, go out of business, change the license model, etc - it's not a good business case to put your product at the mercy of third parties, especially now. (Especially with the quality of code in some instances. It takes less time to do it right yourself than buy-rather-than-build in some cases. Not all.)
When has Gartner's advice actually helped a company (stay in business, or do better, I mean, not fire all their employees and go bankrupt)? How about management consultants in general?
Funny, it seems like you have the wrong monkeys and the wrong tune.
Gartner has zero credibility (or less: they're a Microsoft publicity outlet with a sideline in clueless pronouncements that get taken seriously by clueless "analysts" and executives.)
Building applications from components sounded good back when VB was getting started, before even management figured out that VB crapware built from 3rd party controls was big, slow, buggy/unfixable, and couldn't (by definition) do anything that hadn't been done before. With one exception (a function required by marketing but used by no one, so it didn't have to work perfectly) our every attempt to "leverage" 3rd party ActiveX controls has been a disaster that wound up consuming more time and effort than doing it right to begin with. The one bright side to my management's current infatuation with the preposterous U3 platform is that I've been able to formally ban ActiveX and most other code requiring registration.
Don't get me wrong, I love the idea of reusable components: the state of the art just doesn't make them practical for most uses beyond standard library level. Now that Gartner has spoken, I'm just waiting for some overpaid pinhead to substitute his judgement for mine again and create another fiasco I'll have to fix to save his bonus. I'm still recovering from the latest attempt at outsourcing, where we wound up discarding and rewriting most of an application in much less time than our contractors needed to hose it in the first place.
In 10 years of java (and other) programming I've never seen anything put such a damper on the joy of programming quite like the over-abstraction fad and J2EE.
Anything that bills itself a "solution" without mentioning a _specific_ problem is a horse pucky Himalaya.
this is just the reuse/component argument again. some people will read this as saying that you buy a bunch of third party components and wire them together; with the real problem being programmers with ego issues. now we will be pushed into developing with a lot of commercially licensed components that are making mutually conflicting assumptions, may be weakly documented, require lots of unforeseen glue to wire together, and you can't always fix when you have a problem in the components themselves. license nightmares, and "but i can't do that because thats done in some code i dont have" nightmares.
what these guys don't seem to understand is that most projects ARE doing lots of "reuse" in the form of including open source libraries, and languages with EXTENSIVE runtime libraries (Java,.NET) and frameworks available. Java/.NET developers generally spend little time coding textbook algorithms, container classes, or implementing protocols. At best they are arguing for organizations that make lots of applications need to think about pushing a framework standard, and making domain specific (and well documented/supported) libraries available.
Making that happen is no different from running any other good open source project; the library has to be well documented, promoted, responsive to feedback, decoupled from specific projects (decoupled in reality), and COMPETITIVE with other efforts. They are talking about creating domain specific open source efforts that succeed.
i have yet to hear a single recommendation from gartner that was helpful. they seem to be making quite a killing on companies thinking they have all the answers...either that, or companies don't know how to implement the recommendations correctly. i'd love to see a good competitor to gartner, that spends more time actually fixing problems than developing 800 page PDF files with useless data and recommendations.
The advice that analysts are giving to IT management and business users is based on objective opinion, not paid advertising. Objectivity is the value that clients are buying from Gartner. If you think that a Gartner analyst is wrong, or biased, let them know, better yet, let your Gartner account rep know. The peer review culture at Gartner detects and eliminates bias as if it is a bad bacteria.
We're very open to hear the experiences from users, especially outside the ones that vendors feed us as reference accounts. Our goal is to help organizations make the best decisions possible about technology purchases and use - and to help define architectures that will support the future. Are Gartner analysts always right? I hope not! We are encouraged to be edgy, not afraid to be wrong and not afraid to admit we are wrong. We don't tell your boss what to do. We give him or her an opinion and a framework in which to make a decision. Get on the phone with your boss during a Gartner inquiry call and add your opinion to the mix. The Gartner analyst is there to make sure that your organization isn't breathing too much of its own exhaust.
One of the analysts mentioned in the lead article, Dale Veccio, has deep experience in linking legacy applications to modern ones. The other one mentioned, Matt Hoyle does not exist. The author of the article meant to write about Matt Hotle, another excellent analyst. Give Gartner a try. The worst it can do is to give you a different opinion to consider.
...is you won't have that line of credit without significant income. Which you probably have, if you are an average first-worlder. And thus you enjoy lots of material and non-material amenities that 19:th century working stiffs just didn't have - making Marxism and similar ideologies a much less tempting prospect. (Hence creating incentives for discontented cafe-yabbering types to move their game elsewhere - I.e. race pimping and / or deconstructing Hamlet yet another time.)
As an aside, a credit-based economy might have some of it's roots in imprudence in the general population, and it might bring risks of financial disorder and possible collapse, but it signifies wealth - something the author appears unable to grasp.