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

A little more context...

[Lord Grey]

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.

Re:its in the glue or its in the code

[kin_korn_karn]

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]

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:Scope creep?

[frank_adrian314159]

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?

Scope can be reflected in requirements. If the number of requirements goes up 1% per month, you are getting a 1% scope creep. Note that this measure does not take into account differences in complexity between individual requirements - for a more accurate measure one might use function points, number of classes and/or methods needed to implement the functionality, etc. You need a fairly mature process to be able to measure these at all, let alone accurately, but they are available to those who work hard at the process game (now whether or not that actually gets you anywhere is open to debate, but...).

However, the quote of a 1% per month scope creep as a cut off point seems a bit low, especially if taken literally on a month-to-month basis. Across the life of a project, 1% per month may be high, but cutting a project off because its scope has risen 7% in three months of the late analysis or design phases seems a bit excessive, especially if by doing so you have 0% increase during implementation, test, or deployment.