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

Gartner tells my boss whatever anyone pays em 2

[by Anonymous Coward]

My boss hears things like Linux's a legal risk, SCO might win, etc.

Basically they're just another rent-a-quote firm for people who buy their services

... tells my boss whatever ...

[Original Replica (908688)]

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.

Re:Gartner tells my boss whatever anyone pays em 2

[lucabrasi999 (585141)]

Sure, I know you need to do some of this stuff, but, really...often these days, all you have are mgmt types that know nothing besides these buzzwords, meetings and paperwork....the actual work to be done and deliverables to be produced are merely a nagging side item.

While I admit that sometimes the process does get in the way, the fact is there is a good reason for 'process'. Presently, I am consulting at a place that doesn't really HAVE a process. They don't have meetings to complete paperwork or to discuss plans. They are very much into cutting edge technology. Every critical application is on the very latest OS and Hardware combination possible. They purchase the latest version of everything the very week it is released. And, their developers are busy coding away, instead of worrying about submitting documents or creating change requests.

While that may SOUND like a great place to work, the fact is, the place is a disaster. They are almost entirely in reaction mode. They never use project plans, so no one has any idea how long it will take to complete a task. That is a bad thing, if YOUR project is dependent upon someone else complete that task and you don't know how long it will take them.

They are always rushing to place a hardware order, or to configure the hardware to get it in place, because they want to have the latest and greatest of everything. Unfortunately, because most of their application vendors haven't even agreed to support the latest technology, they are either installing the latest technology without support (a very dangerous thing) or they are always on the phone to various developers, trying to get support.

Because they don't plan their system changes (using formal change procedures), I know of at least one example where payroll production crashed and burned because of an unrequested change (that is completely unacceptable when you have thousands of employees waiting for their pay stubs).

Oh, the developers? They are putting in 60 hour weeks, always juggling tasks, trying to complete EVERYTHING, because EVERYTHING is last-minute rush.

I could go on for pages, but I think you get the point.

Not to scare you

[RingDev (879105)]

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

Consultants like Gartner can eat me

[PopeRatzo (965947)]

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.

A little more context...

[Lord Grey (463613)]

From the original post:

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

From TFA:

Another management function that Hoyle suggested is to kill development projects early, "and often," he said, "if your failure rate is high." You can improve productivity by 20%, Hoyle advised, "by killing projects when you should: which is early in the lifecycle." For example, a project that has had three baseline adjustments because of scope creep is already in trouble.

Let's hope that the managers who "belong to the Silver Bullet of the Month Club" read the entire article rather than just the /. headlines.

I think you got that quote wrong...

[by Anonymous Coward]

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

Perfect PHB Logic.

[twitter (104583)]

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.

Bits & pieces

[fenodyree (802102)]

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.

While we're talking about random quotes

[hayden (9724)]

Here's one I got from an article a while back:

So there it is: IT analysts are basically corporate technology therapists. But there are other ways of looking at it, one of which was put succinctly some years ago by Charles Wang, the billionaire chairman of software giant Computer Associates. He was asked to assess the quality of Gartner's researchers. "I want to choose my words carefully here, so I'm not misunderstood," he said. "They're a bunch of fucking idiots."

I worry about what gartner is telling my boss

[mollog (841386)]

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.

Your boss is just an object

[by Anonymous Coward]

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.

Re:Your boss is just an object

[aussersterne (212916)]

Trouble is, the CEOs who promote this crap can jump from ship to ship-- not all of us can do that.

Seriously. Over the years I've worked in software, networks, and publishing, and I've never had the pleasure of working under any person for longer than about a year. Invariably when I've been hired, I've had the feeling that my new boss wasn't quite on top of things.

But on top of things or not, sure enough, within a couple of months of my being hired there's always an announcement that congratulations are in order because boss will be leaving us for much bigger and better things, or has been promoted to a new and more ridiculous level of abstraction within the organization. Then there's a party and some cake and silly goodbyes.

Then, the new guy comes in. He's always groomed, young-middle-age-ish, clearly an MBA or someone who's read a few too many business books and has been wearing a tie since he was four. He wrings his hands a lot and speaks in a worried-measured-reassuring tone and holds "orientation interviews" (or some variation thereon) with everyone during which he asks a lot of dumb, general, or both questions and says that he'll appreciate help in getting up to speed and he's really excited to have the opportunity to work with everyone.

Within the first two-three months, he'll fuck everything up, miss a pile of obligations or responsibilities, implement a whole slew of unworkable programs, misrepresent nearly everything we're doing in meetings with upper management, and then after a few months, just as everyone gets the feeling that he might finally be having to face the realities of the business, pull his head out of his ass, learn and scale back a little, and roll back some of the stupid changes he made, there will be an announcement... and a goodbye party...

And in will come a new guy, pick up all the old guy's stuff that wasn't quite working anyway, and soon there will be the meetings again... and the initiatives and changes again...

Wash, rinse, repeat as these jackasses earn six figures and get promoted up, up, and away in their beautiful balloons while the people at the bottom do the real work *in spite of* their idiotic tie-speak, with nary a reward year over year.

Re:Your boss is just an object

[aussersterne (212916)]

You're assuming that I want to get paid more. Not true. I think they should be paid less. The game is what's broken; people shouldn't be rewarded for doing harm. And nobody should earn a salary more than 150k or so, no matter what.

I do 'middleware', and I also do 'supercomputers'

[quiberon2 (986274)]

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.

More gardner crap

[infinite9 (319274)]

"Why would you ever code an app from scratch again? Why would you need to?"

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

And the catch is always...

[Doctor Memory (6336)]

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

The problem with the component approach

[MadLep (61542)]

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.

Modularity has downsides

[aschoeff (864154)]

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

NIH.

[Kaenneth (82978)]

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.

Version Lock

[tsotha (720379)]

This component crap has been an absolute disaster everywhere I've seen it tried, especially when you go with more than one vendor. Most applications are tied to an operating system version, language version, and database version(which is, in itself, tied to an OS and version).

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.

Re:Of course that's what Gartner is saying . . .

[Angostura (703910)]

Of course, the savvy OSS officiando will explain to management that this is exactly what they are striving for: "WE only write new code where strictly necessary ... most of this project is utilizing reusable components generated by the open source community..." etc.

Re:its in the glue or its in the code

[kin_korn_karn (466864)]

It's an outsourcing thing. You can usually get away with offshoring glue code, but not major component work.

Gartner is just trying to justify offshoring and make $$ by telling MBAs what they already believe.

Re:Old ideas and old promises

[PeeAitchPee (712652)]

I sometimes get the idea that data modeling is one of least used methods for building information systems. I wonder why.

I absolutely agree. Data modeling is one of the most fundamental skills out there, but time and again I encounter apps with just an absolutely atrocious data model. Much more time needs to be devoted in school to the fundamentals of data modeling and the why behind data modeling best practices. Think about it -- in a "classic" MVC stack, the controller and GUI are often interchangeable, but if you're stuck with a poor way to persist data, the rest of the app *will* be quite limited no matter what you're using for business logic and / or presentation. Furthermore, none of these "component" vendors will help you . . . you'll just end up with a turd wrapped in Company X's duct tape.

Re:Gawds...

[gutnor (872759)]

If it takes you 2 min to develop the application, I guess that's not the same kind of application Gartner has in mind. The smallest application I worked on was about 120 Man-Days development (not including QA, Analysis and "corporate crap overhead"). Even if you can code 10 times faster than me, that's still 2 week worth of work and that's not something you just want to throw out the window. ( and even if you have time to kill, you would not want to go through QA, TAT, UAT, xxT, xxT2, ... without a good reason )

What gartner has in mind is telling the manager what they already believe. Several year ago it was so fashion to rewrite an application from scratch. As a manager, saying that you were reusing something made you look so old school, not a true dot-com mentality. Nowadays you must sacrifice a chicken to get some hope of having the budget to look at the code.
Look at the buzzword friendly tech in the development world, like SOA and Co, this is all about flow management, gluing application together, ...

I don't know what gartner is for. Basically whatever is the tendency of the day, they just acknowledge that the right way to go.