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

Comments

Gartner tells my boss whatever anyone pays em 2

[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

Re:Gartner tells my boss whatever anyone pays em 2

[lucabrasi999]

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.

More gardner crap

[infinite9]

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

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

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.

Version Lock

[tsotha]

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.