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