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
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 writing new apps which handed data differently and produces information in a different light each time.
These people are analysts and don't know this???
A feeling of having made the same mistake before: Deja Foobar
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.
Best regards.
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!
A feeling of having made the same mistake before: Deja Foobar
Of course, the savvy OSS officiando will explain to management that this is exactly what they are striving for: "WE only write new code where strictly necessary ... most of this project is utilizing reusable components generated by the open source community..." etc.
Those who can, do. Those who can't, analyze.
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 VISA..." and let's see them after that...
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.
-.no
"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.
But the biggest problem with code re-use is the human resources element, they caution. Hoyle pointed out that programmers are likely to say, "I can write you some of that. Reuse is for sissies. I'm a better programmer than they are."
WTF. Every programmer I know thinks writing stuff for reuse is much more difficult than not. The problem with reuse is that the writer of that component need all kinds of experience of the different ways the component could be used before they are able to make a decent reusable component.
Hey managers, if you have a programmer that said "Reuse us for sissies", you've got yourself a stupid programmer.
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. These problems will not have a canned solution and someone will have to go off and build the application from scratch. As long as computing continues to get cheaper, there will always be new problems to be solved.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
You Linux people kill me. I could go on and on about the problems with all the differnt Distros of Linux. For every gripe you got about Microsoft I got one for you about Linux. Here are a few. Updates for some of the different flavors of Linux are an absolute pain in the ars. Then when you want to install say Nagios, it takes hours because you have to try and find all the packages and then you might not be able to install the one package because it is depent on another package and to find that other package you have to score around for hours. I can see using Linux or Unix in certain cases, but in no way is it ready for mainstream. I mean can you image your typical end user trying to run a Linux box! hahahahahahahaha that is funny!
"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.
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. So you just have to find the right magic words to say and technology will solve your business problems!
Hasn't this been covered in many, many Dilbert strips?
Spewing buzzwords seems to be an acceptable replacement for thought and knowledge in certain companies.
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.
We are all just people.
"I vividly remember the epic battles that took place when managers returned from TQM (Total Quality Management) training. The all had these purposeful looks of the new acolyte and a Franklin Planner under their arm. They cooked up Vision and Mission statements and tried to get everyone on the bandwagon. It was a trying time because most of the way we already did things were obviously the most efficient. Work under the gun a lot and you tend to find the shortcuts yourself. If anything we became less efficient until the whole clamour died away and most of us returned to getting it done the proper way."
And yet a lot of code isn't quality, and computers crash and people die. Maybe we need fewer "shortcuts", and more "quality".
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
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 locks are not. The key is that the compiler/runtime know how to roll back an atomic block. This kind of atomic block interfaces very gracefully with SQL transactions.
(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 errors seem more rare in practice. Also it's easier to analyse for this kind of problem at compile-time than it is with synchronization.
(3) Write the code in a functional way, so the compiler infers parallelism automatically and you don't need to. Or, take existing C code and have the compiler infer dataflow in it, then proceed as above. e.g. WaveScaler at UW, I think. Many people think this is the best hope for the coming world of multi-core chips.
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.
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.
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-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.
+++ MELON MELON MELON +++ Out of Cheese Error +++ redo from start +++
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.
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 pretending the rules are something they're not is just going to make you bitter and twi....oh wait, you already are.
You either need start playing by their rules in order to compete with them, or stop thinking of yourself as "the bottom doing real work". Pretend you're at the top, and they're all moving sideways under you. Does that make you feel better?
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 will be there to help and to bill. The fact that there may be diamonds in the steaming piles of crap they continue to release does not justify their existence, nor any regard for their opinion.
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.
STOP . AMERICA . NOW
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.
You are welcome on my lawn.
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.
'"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.
--
make install -not war
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.
All hope abandon ye who enter here.
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.)
Gartner has zero credibility (or less: they're a Microsoft publicity outlet with a sideline in clueless pronouncements that get taken seriously by clueless "analysts" and executives.)
Building applications from components sounded good back when VB was getting started, before even management figured out that VB crapware built from 3rd party controls was big, slow, buggy/unfixable, and couldn't (by definition) do anything that hadn't been done before. With one exception (a function required by marketing but used by no one, so it didn't have to work perfectly) our every attempt to "leverage" 3rd party ActiveX controls has been a disaster that wound up consuming more time and effort than doing it right to begin with. The one bright side to my management's current infatuation with the preposterous U3 platform is that I've been able to formally ban ActiveX and most other code requiring registration.
Don't get me wrong, I love the idea of reusable components: the state of the art just doesn't make them practical for most uses beyond standard library level. Now that Gartner has spoken, I'm just waiting for some overpaid pinhead to substitute his judgement for mine again and create another fiasco I'll have to fix to save his bonus. I'm still recovering from the latest attempt at outsourcing, where we wound up discarding and rewriting most of an application in much less time than our contractors needed to hose it in the first place.