Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

What Gartner Is Telling Your Boss 284

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.'"
This discussion has been archived. No new comments can be posted.

What Gartner Is Telling Your Boss

Comments Filter:
  • by Anonymous Coward on Wednesday September 27, 2006 @05:13PM (#16221541)
    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: (Score:3, Informative)

      by cayenne8 ( 626475 )
      Geez....I see more time and money spent WASTED on meetings to put together paperwork to bet processes documented, and procedures set, most of which is done by people who have NO clue as to how to code or put together a database, or gui or webpage.

      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

      • I blame Star Trek. (Score:3, Insightful)

        by khasim ( 1285 )

        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.

        You get everyone in a room.
        You all agree that there is a problem.
        You tell someone to X the Y to emit Z which will collapse the problem.
        5 minutes later, the Y has been X'd and is Z'ing the problem.

        The magic words made the problem go away. Quickly

      • by Original Replica ( 908688 ) on Wednesday September 27, 2006 @06:01PM (#16222035) Journal
        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.
      • by lucabrasi999 ( 585141 ) on Wednesday September 27, 2006 @06:28PM (#16222289) Journal
        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.

        • I've just turned my notice in after working in such a place for about six months. It's kind of like driving your car everywhere in first gear - you might be able to get away with it for a little while, but it's horribly inefficient and eventually the engine *will* blow up if you try it on the highway (i.e. in a real production environment).
        • I've worked in both extremes; a consulting project that was rated at CMM Level 3 solely so the company could check a box on a marketing sheet, and my current job, which is a lot like what you describe. While I was working for the consulting firm, I was about as apprehensive to process as the grandparent. Now I fight for more processes, and better documented ones. The key is to have the appropriate level of red tape for your organization.
        • Re: (Score:3, Interesting)

          by Doctor Memory ( 6336 )

          Presently, I am consulting at a place that doesn't really HAVE a process

          Is this a "Web 2.0" shop? Because it sounds a lot like the places I heard about trying to crank out web apps back in the late 90s.

          I've worked with processes and without, and the best is...just having good competent developers and a manager who can both crack the whip to get things done and shield his team from the political BS. It's only happened a couple of times, but it was nice while it lasted.

          Interestingly, my last gig was with a

      • by PopeRatzo ( 965947 ) on Wednesday September 27, 2006 @07:34PM (#16222965) Journal
        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.
    • Business is hard work and people are always looking for shortcuts. It isn't much different to the whole slimming/diet industry for fat folks. As long as there are people who want shortcuts there will be all kinds of management/software/business fads selling black belts, software components, agile development etc.
  • by Lord Grey ( 463613 ) * on Wednesday September 27, 2006 @05:15PM (#16221549)
    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.
  • Gawds... (Score:2, Insightful)

    by ackthpt ( 218170 ) *

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

    Whatever they're smoking, it's worse than paraquat.

    While about 1/3 apps I program are sort of cookie-cutter, a routine from here, a routine from there and a little glue, most are completely from scratch and have never been done before. The nature of things is change and change dictates wri

    • Re: (Score:3, Informative)

      by erikdotla ( 609033 )
      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 r
      • Re: (Score:2, Insightful)

        by ackthpt ( 218170 ) *

        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.

        Typically when I've re-written an app it is because it has been modified so much from its origninal form it is unable to accomodate a new option and/or has become fragile. There are chunks of code

      • Re:Gawds... (Score:4, Insightful)

        by gutnor ( 872759 ) on Wednesday September 27, 2006 @07:08PM (#16222693)
        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.
  • by fenodyree ( 802102 ) on Wednesday September 27, 2006 @05:17PM (#16221575)
    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.
    • Re:Bits & pieces (Score:3, Insightful)

      by ackthpt ( 218170 ) *

      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.

      You have to keep in mind, there's an industry which keeps inself employed by selling seminars and books. If everyone got all the right answers the first time, what would these people do?

      Going out of business sale, nostrums 50% off!

    • by hayden ( 9724 ) on Wednesday September 27, 2006 @05:54PM (#16221975)
      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."
  • . . . 'cuz Gartner gets paid by the "component" / middleware / toolkit / etc. vendors to say that.
  • by mollog ( 841386 ) on Wednesday September 27, 2006 @05:19PM (#16221597)
    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.
    • by griffjon ( 14945 )
      They have to sound completely certain, that's their business. Luckily, there's not yet a providor of Analyst-analysis. Man, I'd love to see Gartner's hit-rate from say 99-01 in market predictions ;)
    • Companies that think like this (and there are a lot of them) are doomed in the long term. Nothing innovative or truly successful can be produced in this kind of environment and soon their competitors will be doing the same thing for less. What will they fall back on then?
    • It's not like Gartner is the only company in the industry telling companies to explore sourcing (offshore and otherwise). Pretty much every venture capital firm out there today has a policy in place that requires the companies they invest in to have an offshoring/sourcing strategy. There are many reasons why offshoring, when applied correctly, makes great business sense. So to suggest that it's big, bad Gartner whispering in the ears of corporate America that's causing the outsourcing trend is overreacting
  • by Frans Faase ( 648933 ) on Wednesday September 27, 2006 @05:22PM (#16221645) Homepage
    Just like AI has been promissing us real AI for many decades, the idea of producing information systems by combining building blocks still has not become a reality yet. The whole SOA hype is just one of the many "build systems from components" hypes. My experience with building information systems by combining separate applications (and that is how most informations systems are build in practice) is that these systems often crumble to pieces due to mismatching data models. I sometimes get the idea that data modeling is one of least used methods for building information systems. I wonder why.
    • Probably because it takes a lot of time, takes the right people to do it, usually requires numerous meetings to make sure that the data model is correct, someone in charge with the authority to keep the model lean, yet correct, and the money to see it all happen. And on top of that you've got to keep the sales/marketing guys from adding features before the basic model is done.
    • by PeeAitchPee ( 712652 ) on Wednesday September 27, 2006 @05:30PM (#16221757)

      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.

      • Much more time needs to be devoted in school to the fundamentals of data modeling and the why behind data modeling best practices.

        You can say that again. People wonder why I get all twitchy when I have to review code that makes the data model an echo of the object model (because it's trivial to annotate your base class so the tables get created automatically at deployment time). And why I won't help them when they have performance issues ("But I thought you knew about database performance!" "I do, and thi

      • To be honest I'm working on a project where the data model is rather messy, and I designed it. But there is no _obvious_ right way to model it which fits with the ways we need to be able to access the data (there are real-time and distributed and offline aspects which mean we can't just use an RDB and standard normalisations).

        Figuring out a good way forward would involve a couple of months break in visible features... and right now (as of a while), it's the features that are in constant demand. We're eff
        • Re: (Score:3, Interesting)

          by kpharmer ( 452893 )
          > I suspect it's a common scenario.

          Yep - data modeling is now out of vogue, and so it is mostly done by programmers.

          Unfortunately, programmers are seldom good data modelers (if only because they seldom take the time to really learn the discipline). You can take a look at some of the very good books on data modeling patterns (I recommend the one by David Hays).

          But there's no substitute for experience when you get into a tight spot - knowing when to break the old rules and use something like:
    • We've been doing it for decades.

      What's needed is a decent standardised easy to code to data bus and yes, a standard data format. Like Unix stdio but network wide. There are too many proprietary competing systems at the moment.

      Cue xmlBlaster or other Message Oriented Middleware and Rosettanet/other data definition standards et al. Why hasn't it been happening? NIH, ignorance, laziness, narrow focus.

       
      • by cheezit ( 133765 )
        Don't get me started. Just because you can put a short name on "it"---MOM or messaging or whatever---doesn't make the "product" solutions any good, and certainly not the no-brainer why-doesn't-everyone-do-this-they-must-be-stupid panacea you suggest.

        Local stdio is not the same as distributed systems programming. Managers might want it to be so, but it is not. If they want to pretend that it is, they go find some toolkit or framework that will allow them to keep pretending. And then the resulting app suc
  • And so it goes ... (Score:2, Insightful)

    by Greymoon ( 834879 )
    Those who can, do. Those who can't, analyze.
  • 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.'

    Excellent. I hope some PHB at a Software company takes this advice and runs with it. The resulting fiasco should be great for Gartner's reputation.
  • by Anonymous Coward on Wednesday September 27, 2006 @05:28PM (#16221737)
    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.
    • by aussersterne ( 212916 ) on Wednesday September 27, 2006 @06:47PM (#16222499) Homepage
      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: (Score:3, Insightful)

        by danpat ( 119101 )
        Green with envy?

        Complain as much as you'd like, but if your measure of success is place in the hierarchy and size of paycheck, then these guys are better at the game than you. You may not like it, but life's like that. It's kind of like complaining when you lose at a game of poker because your style of play calls for putting your cards face-up on the table.

        While it'd be nice if promotion and salary were neatly tied to ability and achievements, that ain't the case. Sticking your head in the sand and prete
        • by aussersterne ( 212916 ) on Wednesday September 27, 2006 @07:27PM (#16222897) Homepage
          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.
          • by danpat ( 119101 )
            Now you're in denial. Unfortunately, we're all stuck in the same universe together, we can't just up and leave when we don't like the way things work. In the real world, there are two ways to get rewarded: 1 - do something worth being rewarded for; or 2 - convince others that you should be rewarded (without actually doing anything). They're both valid ways to get rewards. Because doing things worth being rewarded for is actually difficult, you can often get better rewards and more often, simply by talk
            • Or, I can post to Slashdot in the meantime as a way of venting frustration in agreement with an earlier poster

              -and-

              work to change the system. You're wrong about the universe, by the way, this is merely the way capitalism works.
  • by quiberon2 ( 986274 ) on Wednesday September 27, 2006 @05:29PM (#16221743)

    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.

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

      Just curious: What are the proposed alternatives that simplify synchronization?
      • I would imagine Erlang [wikipedia.org] would be a contender.
      • Re: (Score:3, Insightful)

        by ljw1004 ( 764174 )
        What are the proposed alternatives that simplify synchronization?

        (1) Software Transactional Memory, STMs. You write "int STM x=5;" and then one thread can do "atomic {x+=1;}" and another does "atomic {...;x-=1;...}" and the runtime+compiler magically make the atomic blocks execute atomically. This is different from Java synchronization blocks because these can be executed optimistically in parallel and because they never result in deadlock. People therefore say that STMs are "compositional" in a way that lo
        • You write "int STM x=5;" and then one thread can do "atomic {x+=1;}" and another does "atomic {...;x-=1;...}" and the runtime+compiler magically make the atomic blocks execute atomically. This is different from Java synchronization blocks because these can be executed optimistically in parallel and because they never result in deadlock.

          Why would you want to use two threads for something trivial like that?
          • Re: (Score:2, Informative)

            by ljw1004 ( 764174 )
            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 log
        • What's old is new (Score:3, Interesting)

          by DaveAtFraud ( 460127 )

          (2) Message-passing. Academically it's embodied in the "pi calculus". In web terms it's embodied in the W3C "choreography" working draft. In practical terms it's embodied in Microsoft's Biztalk and in Ericcson's Erlang language and in Microsoft's new Robotics SDK. It's also a little reminiscent of "tuple-space" operating systems. The idea is that threads communicate by sending messages to each other. It's still possible to deadlock (e.g. if one thread waits for a message that will never come) but these err

    • [Gartner analyst] Veccio stated "Why would you ever code an app from scratch again? Why would you need to?"

      How about because what's needed doesn't exist? This bozo sounds like the head of the patent office in 19th century who recommended that the office be closed because, "...everything that can be invented, has been invented." What an idiot.

      As the cost of computing drops, there will always be new problems that could not be economically attacked until the cost of the computation became cheap enough.

    • And Intel are coming up with these 80-Core chips.

      The 80x86?
  • Degradation (Score:2, Insightful)

    by apeeira ( 978496 )
    Degrading the art and science of programing will have an adverse effect on the developer community,for after all if all i have to do in order to make an app is do a little copy, cut and paste ms word style..... Of course if this idea came from the management field, we could do the opposite....like this: "see we have developed a new algorithm for managerial decisions which will cut prices and increase profits for the company, their hardware requirements are not high and can work 7/24 without a corporate VI
  • this is old news (Score:2, Insightful)

    by jt418-93 ( 450715 )
    i remember when turbo pascal and all the nice little objects were going to end having to write the basics, or when windows and common dialogs was going to save it.

    same bs, different cow's ass producing it.

    software always comes down to borrowing as much existing stuff as you can and building the rest. ime, very little from project a is actually appropriate for projcet b.

    bah, back to coding asm in notepad.
  • More gardner crap (Score:5, Insightful)

    by infinite9 ( 319274 ) on Wednesday September 27, 2006 @05:40PM (#16221847)
    "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.
  • Most projects do have scope creep -- 1% per month is typical -- but three or more adjustments due to changing requirements means that the project is already out of control

    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?

    What a load of creep, err, crap.

    • Re: (Score:2, Funny)

      by kfg ( 145172 ) *
      What is the unit of scope

      Fathoms.

      KFG
    • by tsotha ( 720379 )
      Yeah. But not only that - I've always considered scope creep to be a management failure. It's caused by a boss that's afraid to tell his customers "The feature list for the first release is closed. We'll put that in a later version." If the scope is creeping too much it's time to cancel the manager, not the project.
    • Re:Scope creep? (Score:4, Informative)

      by frank_adrian314159 ( 469671 ) on Wednesday September 27, 2006 @09:13PM (#16223743) Homepage
      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.

  • I'll never work for someone who is dumb enough to listen to crap like that.

    So, let all the big companys buy into the bullsh*t. I'll continue to work for small startups, and we'll continue to out-develop and out maneuver the big dumb lumbering brutes.

    Once a company get over 100 people, it's time to leave.

    If you have a question about how the app you are writing is supposed to work, and you can't just walk over and ask 1 person, and have them make a decision, then it's time to leave.

    Once developers are not al
  • by Doctor Memory ( 6336 ) on Wednesday September 27, 2006 @05:53PM (#16221967)
    "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!"
    • by Shados ( 741919 )
      Hahaha, too funny, because I went through that hell last week and almost quit my job because of it. Finally convinced my boss to stop thinking that way (saving 2 days by reusing "MegaMess" to lose 3 weeks later is just rediculous... Sometimes managers just want to reuse stuff for the sake of reusing stuff.).

      However, I'll say... a well architected system will have a lot of very small, highly reusable components and structures...so reusing those usualy won't turn into a "megamess"
  • by MadLep ( 61542 ) on Wednesday September 27, 2006 @05:54PM (#16221973) Homepage
    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.
  • The analyst is captures the essence of American big-business, "Don't do anything new." Just remix something already on the shelf. It's better."

    This is low-cost producer corporateThink. America cannot be the low-cost producer. So the obligation is to innovate.

    But the wealthiest 2% can't stand innovation because it is a direct threat to their wealth. They go to Washington and legislate innovation away.

    I left the environment that this analyst describes because it rotten. It rots the brain!

    Now I work in a
    • But the wealthiest 2% can't stand innovation because it is a direct threat to their wealth. They go to Washington and legislate innovation away.


      First of all, most of them are pretty secure in their wealth.

      Taking something extant and making it better is certainly innovation, and it's the kind that really produces great things. Think of a good technology product. OS X/Desktop Linux/iPod/IBM-PC/etc. None of these were the first of their kind.
  • ...that they themselves are a brand. They sell their methods, scope and delivery as of the highest quality and strongest reliability. They have an established market, cater their style towards the "executive" woodgrain model, and compete with an ever-stronger ear to the ground: the 'net and specifically the tech blogosphere.

    They opine on techniques that have resulted in both success and failure, quote objective data, and compile their own trends and predictions. This isn't necessarily bad, but taken alo
  • by aschoeff ( 864154 ) on Wednesday September 27, 2006 @06:06PM (#16222069)
    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
  • Ya done it (Score:3, Funny)

    by Quiet_Desperation ( 858215 ) on Wednesday September 27, 2006 @06:08PM (#16222081)

    ...that they themselves are a brand. They sell their methods, scope and delivery as of the highest quality and strongest reliability. They have an established market, cater their style towards the "executive" woodgrain model, and compete with an ever-stronger ear to the ground: the 'net and specifically the tech blogosphere.

    You just blew out my buzzword detector. Expect a repair bill soon, Jackson!

  • NIH. (Score:4, Insightful)

    by Kaenneth ( 82978 ) on Wednesday September 27, 2006 @06:18PM (#16222173) Homepage Journal
    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.
  • This an old model (Score:3, Insightful)

    by Anonymous Coward on Wednesday September 27, 2006 @06:19PM (#16222187)
    I've worked with this model for ten years already and there are advantages and disadvantages. Unfortunately, it's rare that you can find either a management team or a software development organziation that understands either.

    The component model works reasonably well for the Generic Core Business Functions (i.e accounting, human resources, sales, etc.), however only to the exent that you can use Off The Shelf Functionality. If your requirements are unique (or you think they are) you end up with a full blown development project on your hands anyway (with associated headaches and expense).

    If, on the other hand, the requirements you are trying to address are part of the Value-Added Function that your organization provides to it's customers, you had better be willing to invest in creating some real value for the customer. If you spend a couple of months integrating off the shelf components that can provide the same value, you're not likely to be in business long.

    Killing projects early for the Right Reasons is simply good management but the need to do this is usually an indication that there is something wrong in the organization itself. If you are part of an organization that does this frequently, the governance process or the development process is broken or both. Flee with all due speed.

  • The "components" snake oil has been around ever since Eli Whitney duped Congress with a faked demo in 1808. "No one realized it then, but Whitney was faking it. He'd carefully hand-crafted each part so they'd fit together. Whitney sold the government a huge contract for four thousand muskets. He took eight years to deliver them and then the parts weren't interchangeable after all." [uh.edu]

    But, you will say, they eventually did get it to work. True. But "software components" have been advertised as the cure for what
  • by divisionbyzero ( 300681 ) on Wednesday September 27, 2006 @06:25PM (#16222259)
    I'll grant that much of this article is horse crap, but it's always disappointing to so see how vehement people become in their reactions when their livelihood is threatened. It's a shame because they are so busy defending themseles they can't take the time to find out if there is anything worthwhile being said. I bet 85% of the people responding haven't even read the article. Of course that's typical Slashdot...
    • Re: (Score:3, Informative)

      by wrook ( 134116 )
      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 sig
    • yes... (Score:2, Insightful)

      by Hap76 ( 995519 )
      Because the reason lots of people's jobs are threatened/are leaving is because people with no stake in and little knowledge of the processes that go into doing any variety of things are taken as gurus by people who also don't know better, and who care about nothing other than that they want to make money now and don't intend to be around when the crap hits the fan.

      These people enable the moronic management that has felled many a company. As long as there is money to be made in prolonging a problem, they wil
  • Ok, im game, in concept. But if you kill off all your developers, who is going to code those resuable components?
  • by CharonX ( 522492 ) on Wednesday September 27, 2006 @06:33PM (#16222345) Journal
    Re-use when possible, re-code when sensible - that should be the baseline for both managers and programmers.
    For programmers its simple to put into words - if you have programmed a function to resample colour images and now you need a function to resample black and white images, just use the colour image function.
    As for managers - if you discover you have three projects to manage the time shedule of section A, section B and section C - tell one of the teams to make the software generic enough to manage all kinds of time shedules (including those of sections A, B, C) and reassign the other two teams.

    But if, in the above image resampling example your function needs about twenty times as much time as a function specialized for B&W imaged would need and is used constantly, you should code a specialized function, if performance would take a too large hit.
  • I think the the basic idea of using tried-and-true-and-robust components is a good one.
    It's why I prefer coding my projects in Perl. The components available from CPAN make
    practically any task quick to develop and robust.
  • I have to agree with this. Well most of it in the terms of proper process engineering and planning and using existing code.

    My comment is going to sound windows centric but its common in the bussiness world. The reason Java is so popular is not because its a great language that is cross platform but because the java api's in javadocs are huge. There is a method for about anything you can think of. MS also advertises dont code it, include it with teh saying we develop the code so you dont have too.

    VB is a ver
  • Wow, I smell a new Dilbert strip in the making (although it's probably already been done).

    Next time I dine out, I won't ask for chicken or fish or a salad, but, instead, a "big serving of excellence".
  • Version Lock (Score:5, Insightful)

    by tsotha ( 720379 ) on Wednesday September 27, 2006 @06:40PM (#16222425)
    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.

  • Paul Graham has an excellent view of management at his site
    http://www.paulgraham.com/ [paulgraham.com] in his essay Great Hackers
    http://www.paulgraham.com/gh.html [paulgraham.com] :

    Hackers like to work for people with high standards. But it's not enough just to be exacting. You have to insist on the right things. Which usually means that you have to be a hacker yourself. I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about

  • by TopShelf ( 92521 ) on Wednesday September 27, 2006 @07:41PM (#16223017) Homepage Journal
    Here we go, 500 comments about how management doesn't know anything.
  • So while you're managing your application portfolio your user base will be writing applications with Access and Excel like they used to. All this does is push development off IT and on to the users. So instead of having all your apps with a common front end (web browser) and a common back end, like SQL Server, you'll be back to the linked spreadsheet house of cards and an application portfolio of who knows how many different vendors.

    Total insanity. But Gartner packages in terms managers like to hear.

  • Very old story... (Score:4, Insightful)

    by Gorimek ( 61128 ) on Wednesday September 27, 2006 @10:50PM (#16224397) Homepage
    I've heard for over 20 years that "soon" there won't be a need for programmers, since you will just be able to make applications by putting components together.

    This appeals to managers, since having programmers around is a pain. They're expensive, unreliable and act weird.

    It will of course never work in reality. Anything interesting enough to be worth doing will be hard enough to get right that you need an actual programmer for it. And programmers have been putting components together almost since the dawn of programming, it's just that some people don't know that.
  • Producing Reports (Score:3, Insightful)

    by Doc Ruby ( 173196 ) on Wednesday September 27, 2006 @11:04PM (#16224501) Homepage Journal
    '"not about programmer productivity," said [Gartner analyst] Hoyle during the keynote presentation, "but in assembling functionality from components"'

    That's the kind of stupid "surprisingly clever" gibberish Gartner sells to bosses around the world. Assembling functionality from components, or "code reuse" is programmer productivity. "Buy instead of build" is another 1980s "breakthru insight" that practically every programmer uses, whether their boss realizes it or not.

    Even C programming, which practically always calls an API, is assembling functionality from components. Unless you're programming in assembly without an OS, you're not "programming from scratch".

    The continuing thriving of Gartner and the survival of businesses that consume their drivel is more testimony to the irrationality of economics. Any rational system would have increased boss productivity long ago by dumping any who wasted any time learning to be clever from Gartner.
  • Here we go again. (Score:4, Insightful)

    by ThePhilips ( 752041 ) on Thursday September 28, 2006 @03:50AM (#16225893) Homepage Journal
    "Why would you ever code an app from scratch again? Why would you need to?"

    Buhahahahhahahhahhahhahaahahahah!!!!! HERE THEY GO AGAIN!!!!!

    I'm writing software for 15 years. And I already lost count of how many times I was told that crap and that "tomorrow" I would be among unemployed, since even idiots would be able to create software using tomorrow's modular platforms. That tomorrow is yet to realize.

    I was working with asm/pascal 15 years ago - and were basically rewriting applications from scratch: for new platforms and for new performance requirements.

    I now work with C/C++ - and basically rewrite applications from scratch: for new platforms and for new performance requirements.

    What'd changed? NOTHING.

    Would the idiots ever learn? As computer industry develops and grows - so do requirements for computers. 15 years ago nobody expected to have affordable real-time 3D graphics or on-line simulation algorithms or real-time video encoding. Now we take that for granted. As old fart, of course, I cannot even imagine what would be capable computers in next 15 years - but all that would be possible because of abundance of cheap HW performance and I hope more intelligent software. Not because we would have such performance - but because I'm sure there is and would be ever growing demand for it.

    e.g. some AI guys might tomorrow implement autonomous OS which would be voice/etc controlled. So you would be able to plug your photo camera into computer, say "Grab all new photos" and (miracle!) it would do that. Then say "If there are more than N gigs of new photos burn me them on disk as photo album.". Etc. Voice recognition + intelligent interpretation of commands + AI personalization - are tasks not yet possible for computers both hardware-wise and software-wise. NOW. How well fit modern algorithms and applications for tasks in such environment? They are completely unfit. So when development would come to that point - we software developers would have to rewrite all the components and blocks to fit well into new platform/OS/etc to get most out of it. IOW, do not put your GCC aside just yet.

  • by scottsk ( 781208 ) on Thursday September 28, 2006 @07:57AM (#16227559) Homepage
    There are two lines of thought to answer "Why would you ever code an app from scratch again?" - one is simply that if you're doing something worthwhile and innovative, there IS NO OFF THE SHELF solution. If you can buy the solution, is your app doing anything that isn't already being done? The other is tying yourself to a vendor. I know anything from Gartner is designed to promote this, but in the real world, do you want your killer app at the mercy of a vendor who can drop support, go out of business, change the license model, etc - it's not a good business case to put your product at the mercy of third parties, especially now. (Especially with the quality of code in some instances. It takes less time to do it right yourself than buy-rather-than-build in some cases. Not all.)

Statistics are no substitute for judgement. -- Henry Clay

Working...