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.'"
Man, Gartner must hate Perl.
I've re-written the same applications dozens of times, sometimes because my code is unreadable, sometimes just for fun to find a new way to do it, and occasionally because it's so easy that it's actually faster than spending 2 minutes finding the previous version. Gotta keep my mind fresh, I'm over 30 you know.
Though.. I suppose if I could call my Perl application portfolio manager and ask them where that 10 line text parser is that I wrote yesterday, and they could provide it right away, it would save me 2 minutes of searching my own hard disk. Of course, since the portfolio manager can't understand what the app does unless I spend 15 minutes writing documentation and explaining it to them, I get a net loss of productivity anyway.
# Erik
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.
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.
More crap time is spent doing this stupid stuff, rather than getting the ball rolling and actually putting something together. I've seen projects waste their time and money on this.....and run out of both, to never get the project off the ground.
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.
"It is the process that is the most important thing..." Thank the Lord I've not had a gun each time I've hear that one.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
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).
Heh heh... Funny thing is, I don't feel threatened. This is the same crap that has been around since I got my first industry job (~'92). Back then it was "software factories". Hell for all I know, they still call them "software factories". And I admit to not reading TFA. Why bother?
I'll just sit and let those companies who think mixing and matching "components" is going to work, loudly go out of business. If I happen to be one of the casualties in that fallout, so much the better. It's not what I signed up for.
We used to have a word for systems composed with off the self "components". It's called a "Stovepipe system". It ain't gunna work. And it's no fun to be in a company that thinks it is (been there, done that). So worse comes to worst, I'll end up writing free software and working as a waiter with RMS (although how he's going to get a job as a waiter, I'd like to know...)
Life's too short to work for morons...
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.
That is all.
While your snarky tone is unmistakeable, you definately missed the GP's point.
The audi is a lease
The hi-def TV is on the credit line you opened at Best Buy
And a $250 a month bill, is afterall a liability, not an assest.
Read the damn book, he's right.