In IT, Beware of Fad Versus Functional

Lemeowski writes: Cloud, big data, and agile were three of the technology terms that were brandished the most by IT leaders in 2014. Yet, there could be a real danger in buying into the hype without understanding the implications of the technologies, writes Pearson CTO Sven Gerjets. In this essay, Gerjets warns that many IT executives drop the ball when it comes to "defining how a new technology approach will add value" to their organization. He says: "Yes, you can dive into an IT fad without thinking about it, but I can promise you'll look back and be horrified someday. The only time you can fully adopt some of these new methods is when you are starting from scratch. Most of us don't have that luxury because we are working with legacy architectures and technical debt so you have to play hand you've been dealt, communicate well, set clear and measurable outcomes, and use these fads to thoughtfully supplement the environment you are working in to benefit the ecosystem."

Comments

In IT, remember to wash your hands

[mi]

Beware of Fad Versus Functional

What's so IT-specific about this maxim, that it warrants being on Slashdot? A slow news day?

Re:In IT, remember to wash your hands

[gstoddart]

Because technology changes much more quickly than real world analogs, and sometimes everyone suddenly decides "OMG, if we don't have teh new stuff we're gonna die".

I've seen a lot of money thrown at fads which took resources away from things which actually add business value or generated revenue.

A brick and mortar business doesn't have the huge shifts which happen in tech, where all of a sudden completely unproven stuff becomes perceived as completely mandatory.

I've seen entire development teams pulled off core products which generated money in order to implement some crap buzzword technology which, in the end, nobody ever actually wanted and which didn't add business value. And by the time anybody realized that, the core technology which generated money had been left to rot for a period of time.

And, of course, unlike other industries .. management in tech frequently have no clue about tech, and therefore have no way of understanding the consequences of their stupid choices. They just think it's all interchangeable and subject to whatever idiotic whims they come up with.

Back when companies used to have roadmaps (do they still have those?), it was not uncommon for a bunch of tech people to be rolling their eyes saying "yeah, right, like we'll be making those in a year" as management told them about the wonderful (and completely meaningless) future of the company, only to be told something completely different in six months.

The people in the concrete business? They don't suddenly get told they'll be making stuffed talking animals in a few months.

I consider it a sad fact of reality that most tech execs are completely delusional, and truly believe that just because they say something based on whatever crap Gartner is selling, that in six months time it will be reality. And they're often too short sighted to realize that the crap we abandoned from six months ago isn't any more true than the stuff we'll abandon six months from now.

Because tech execs consider themselves visionaries, and visionaries aren't constrained by pesky things like reality.

Me, I'm betting anybody who has worked in tech long enough has a whole litany of stories about how the "exciting new future" turned out to be "yet another dud championed by idiots".

Re:In IT, remember to wash your hands

[mi]

Because technology changes much more quickly than real world analogs

And yet, the functionality is still more important than a fad in (almost) all walks of life — with the exception of clothing styles, perhaps — not just in Information Technology...

Re:In IT, remember to wash your hands

[TWX]

There's a hell of a lot more fad in life than most people want to admit. For our cars, if we wanted function we'd all be driving minivans with stow-n-go seats.

Re: In IT, remember to wash your hands

[Anonymous Coward]

This is really a "no shit sherlock" post if I've ever seen one before.

Re:In IT, remember to wash your hands

[TWX]

Me, I'm betting anybody who has worked in tech long enough has a whole litany of stories about how the "exciting new future" turned out to be "yet another dud championed by idiots".

I worked at one place that bought the hype during the NT3.5 years that NT was headed in the embedded systems direction, where the GUI was not going to be important or even necessary for the system. That company bet the farm on that, and by the time NT4.0 and Windows 2000 came along it was clear that this was very much in error, and the product suffered greatly as the backend things that had been promised were never developed for the NT product line. It's only in the last few years that this idea has made a resurgence. That company is long gone because of their choices.

Re:In IT, remember to wash your hands

[Livius]

But the fads change faster still, and this has been obvious to informed people in IT for decades.

Everything web-based since the original HTML has been more about hype than technological substance.

Re:In IT, remember to wash your hands

[mi]

For our cars, if we wanted function we'd all be driving minivans

Not at all. Minivans — and even most SUVs — drive like crap. And I don't mean engine — the suspension is nowhere near where it needs to be, to make driving enjoyable. None of them come with a manual transmission either — the command-line of driving — so, no...

There are people, who might choose a different model, because it comes in a particular color, but that falls into the "clothes style" category, which I already mentioned, anyway.

with stow-n-go seats.

This is an important consideration — and people do consider it. For example, I always preferred Volkswagens (and now that I've grown up — Audis) because their rear seats can be laid flat. A standard feature, whereas in BMW and Mercedes you have to pay extra for it (if it is available in the first place).

Re:In IT, remember to wash your hands

[Khyber]

"None of them come with a manual transmission either"

Excuse me, my Suburban 4x4 most certainly came with manual transission.

Re:In IT, remember to wash your hands

[TWX]

My point is, minivans are perfectly adequate for getting several people, some people plus cargo, or a fairly large amount of cargo from one place to another, reasonably efficiently on fuel, with only a single vehicle to do all of it. For cargo a minivan has the lowest floor of a wagon-type vehicle short of a sedan-based station wagon, has a high roof making large things fit easily, and has three large doors making accessing cargo or seating space fairly easy.

A minivan is not a sports-car. A minivan is not a 4x4. A minivan, however, is probably more efficient than either in the primary use for a vehicle, which is typically on the road. It has a lower load-height than a pickup truck, and can hold a 4x8 sheet of plywood while most pickup trucks can't without leaving the tailgate down.

I don't own a minivan either, but right now I don't need one, as I have a beater truck in addition to my other vehicles. I, like most people, have chosen style in my vehicles over raw utility.

Re:In IT, remember to wash your hands

[Qzukk]

While this particular bug is endemic to IT, let's be honest: over the centuries, how many non-IT companies have decided that DIVERSIFICATION was the latest fad and abandoned doing their one thing well and crashed and burned doing lots of things not-so-great?

Re:In IT, remember to wash your hands

[Anonymous Coward]

And I don't mean engine — the suspension is nowhere near where it needs to be, to make driving enjoyable.

Please explain how "enjoyable" is a dimension of functional?

None of them come with a manual transmission either — the command-line of driving — so, no...

No matter how much it makes you feel like speed racer, I can guarantee that you do not get more "function" out of your manual transmission - the computer calculates far better performance ratios for you far faster than you ever could.

You're underscoring the original point that most things in life are very fad-driven. Thanks for playing.

Re:In IT, remember to wash your hands

[Anonymous Coward]

It's an angle to shoe-horn in a different concept: Managing technical debt. "IT" has heaps of that. Tons. Tonnes. Short ones, long ones, metric ones. We all know this. But... it's sooooo much easier to just run around and heap more technical debt on the existing pile one fad at a time. Ah, what am I saying, can't you(r minions) multitask? Besides, "working with the latest technologies" is something to bandy around and attract bright young engineers with, and you know we never can have enough of those.

Re:In IT, remember to wash your hands

[ShanghaiBill]

I've seen a lot of money thrown at fads which took resources away from things which actually add business value or generated revenue.

This is not unique to tech. Ask any public school teacher about the educational methodology fads they have to deal with.

Re:In IT, remember to wash your hands

[Archangel Michael]

I consider it a sad fact of reality that most tech execs are completely delusional

Any sufficient level of incompetence is indistinguishable from malice.

Are you sure they are incompetent? My guess, is that they don't care about what functions, just as long as they get their toys.

Re:In IT, remember to wash your hands

[Shoten]

Beware of Fad Versus Functional

What's so IT-specific about this maxim, that it warrants being on Slashdot? A slow news day?

Probably the fact that tons of us have tried to tell people this in our jobs in the past, but few have been able to put it as clearly and as succinctly as this, while still stating all the factors that play into it.

Re:In IT, remember to wash your hands

[RandomAdam]

Not true; auto-transmission cannot yet know that there is a hill coming up and "pre-load" the gear ratio. I have driven some really good autos and mostly really bad autos. I currently have a Toyota 86, the auto box in that is amazing...the only time it has been it the "wrong" gear was either on the track going round a long sweeping corner where I wanted to stay in 3rd but it changed down to 2nd and when changing from being on the flat then up a steep hill.

Where as when I drive my manual Subaru Outback; I am always in the "correct" gear.

Yes the computer can calculate faster then I can; but it cannot (yet) perceive the upcoming road.

Re:In IT, remember to wash your hands

[mi]

A minivan is not a sports-car. A minivan is not a 4x4. A minivan, however, is probably more efficient

And my point was, that people, who do choose a sports(ier)-car and/or a 4x4, do so for reasons other than mere fad.

Re:In IT, remember to wash your hands

[mi]

Please explain how "enjoyable" is a dimension of functional?

Whenever "bringing joy" is among the functions, more enjoyable means more functional.

computer calculates far better performance ratios for you far faster than you ever could

Only if the objectives programmed in its algorithm(s) match mine. I'm yet to encounter a car, that is so programmed...

Re:In IT, remember to wash your hands

[mi]

Probably the fact that tons of us have tried to tell people this in our jobs in the past, but few have been able to put it as clearly and as succinctly as this, while still stating all the factors that play into it.

And this, in your opinion, is a problem unique to IT? Seriously?

Re:In IT, remember to wash your hands

[Dragonslicer]

There's a hell of a lot more fad in life than most people want to admit. For our cars, if we wanted function we'd all be driving minivans with stow-n-go seats.

Those of us who consider fuel efficiency or handling to be part of the functionality wouldn't be driving minivans.

Re:In IT, remember to wash your hands

[TehZorroness]

This reminds me of my mechanic's old Snap-On MODIS II OBD2 diagnostics machine. The thing is literally a handheld computer (heavy and bulky) except instead of a keyboard and mouse it has 6 buttons. When you plug it in, it takes 5-10 minutes to boot up Windows 98, then eventually the front end software starts up. It's a terrible hack of a machine.

Re:In IT, remember to wash your hands

[Anonymous Coward]

Oh, you think it's bad in corporate-land, try academia! Where every new person put in charge of an IT area wants to implement the latest and greatest "technology enhancement" to teaching that everyone is talking about, or are arrogantly presumptuous enough to think that they will set a new trend and standard for technology enhanced education. These folks get three letters after their name and think they're God's gift to the suffering masses not using fad tech in their classrooms when there's absolutely nothing wrong with how things are taught using traditional methods. It's amazing how these folks with zero experience get put in charge of facilities, personnel and budgets only to pander to a small number of faculty that they feel they are helping because they believe the same fad tech is going to change the world. Blind leading the blind. Meanwhile, computer requirements are being mucked with so one administrator can use non-research funds to fund their own research into a technology, costing students millions for years to prove that nothing was gained by the fad tech and the small cadre of faculty supporters (less than 20% of faculty) get some journal papers.

Re:In IT, remember to wash your hands

[Jane Q. Public]

Because technology changes much more quickly than real world analogs, and sometimes everyone suddenly decides "OMG, if we don't have teh new stuff we're gonna die".

Yes, but.

Agile, for example, is hardly a "fad". It is a proven methodology that had its roots back in the 1950s or earlier. That means many of the primary elements of agile development have been around for over 50 years. Some "fad".

I don't have a problem with the general point of OP, but I strongly question OP's judgement of what constitutes a fad.

Re:In IT, remember to wash your hands

[TWX]

That's unfortunately not the exception.

I have an OTDR from EXFO that's effectively a Windows 2000 machine with some special controllers, drivers, and software. Most of the CNC machines that I've supported run Windows 95 or 98, and it's becoming a problem, getting project files on to them to have machined.

It's a lot easier when one doesn't have the write the OS, but unfortunately using a general-purpose OS means that the equipment becomes unsupportable before the job the machine was purchased to do is no longer necessary and before everything wears out.

Re:In IT, remember to wash your hands

[sjames]

Perhaps it isn't specific to IT but for whatever reason, fads run rampant in IT.

Re:In IT, remember to wash your hands

[drinkypoo]

Minivans are dying. They have turned out to be a fad. They are being replaced by CUVs. It turns out almost nobody actually wanted to carry cargo and a lot of passengers, and a minivan is half-assed at both. The only exception went out of production because buyers decided it was too old — the Chevy Astro. Only one engine but since 2000 it was awesome, and available in short or long versions and AWD or RWD. RWD with 3.23s gets up to 26 mpg on the freeway at speed, I wouldn't lie to you. We would have got rid of it already otherwise. This is on an engine rebuild and a trans rebuild and an axle rebuild and a brake rebuild, though, I'm not claiming it's great in all ways. But have you seen the kind of mileage minivans get? Mostly it's no better than that, and they don't behave like a truck when you want them to. The only one I ever wanted to drive was the mid-engined Previa S/C, and it gets like 22 on the freeway.

Re:In IT, remember to wash your hands

[moogied]

Not if its linux.

Re:In IT, remember to wash your hands

[TWX]

That's a load of crap. If a CNC is too old, it's very likely that the CNC-specific software will have problems running on newer distributions because the libraries don't behave the way the old application needs anymore. Dependencies will fail and the program will crash, or even if the application's source is available it will fail to compile and be a huge pain in the ass to fix, if it's possible for the average user of a CNC mill at all.

It's also likely that it won't be updated, and if on the network will pose a security vulnerability.

Re:In IT, remember to wash your hands

[Blaskowicz]

Then you'd be stuck on some linux 2.0.x shit with veryimportantlibraryfoo at version 1.x whereas the current one is at 4.x?

Re:In IT, remember to wash your hands

[sjames]

And nobody would willingly buy a vehicle new unless/until they dropped the price enough to not lose a quarter to nearly half of their value the moment they drive off the lot.

Re:In IT, remember to wash your hands

[plover]

Beware of Fad Versus Functional

What's so IT-specific about this maxim, that it warrants being on Slashdot? A slow news day?

Not a damn thing. As a matter of fact, the original HBR story referenced in the TFA is not about IT at all. And TFA could have been written by Captain Obvious, except it's not nearly as clear.

Re:In IT, remember to wash your hands

[Anonymous Coward]

I work as a developer for a large company that manufactures a number of consumer products.
The higher-ups are pushing for agile development, but I've noticed that agile doesn't work well with large, archaic and industry specific code bases for embedded development.
Has anyone else noticed that arcane code bases relying on corporate memory fails when agile is implemented?

Re:In IT, remember to wash your hands

[toddestan]

On the upside, you won't have to deal with licensing issues for the operating system. I'm running into this with XP - Microsoft will not license new copies of XP and you can't downgrade a current version of Windows either. This makes replacing hardware difficult - even if the new hardware would work, if you can't get XP on it and the control software requires XP, you're kind of stuck.

Re:In IT, remember to wash your hands

[serviscope_minor]

Minivans are dying. They have turned out to be a fad. They are being replaced by CUVs. It turns out almost nobody actually wanted to carry cargo and a lot of passengers, and a minivan is half-assed at both.

huh? minivans are excellent at both. The only things better at hauling cargo are vans, and perhaps trucks and both suck at hauling people.

I'd say CUVs are a fad. They're for people who need a minivan but feel emasculated by not owning some ludicrous SUV.

I drove a minivan (Nissan Serena) for a few years when I was a kid. Was an excellent vehicle. I enjoued driving it (nice high driving position, huge mirrors), held 6 adults in comfort or could carry a crapload of stuff.

And fitted into the same size parking space as a mid size saloon car.

What's not to like?

Re:In IT, remember to wash your hands

[kenshin33]

no "command line", honestly that;s the only thing stopping me from getting one. Now I have a Mazda 5, not as big -6 adults but no cargo space, or crap load of cargo space no passengers, and yeah manual transmission :-).

Re:In IT, remember to wash your hands

[Noah Haders]

Because technology changes much more quickly than real world analogs

lovely digital/analog pun, but i think you meant analogues.

Re:In IT, remember to wash your hands

[Anonymous Coward]

I'm in the middle of it.. a few has turned our product into a play ground of you technologies.
The problem is that management is in on it, and I even heard that "the time when we develop own stuff is over".

Our company has always developed own stuff, that is what has sold many copies on the market and made us market leaders, aka: bleeding edge.

No need to say, that I'm about to jump to greener fields.
Moral of the story, watch out to follow tech visionaries.

Re:In IT, remember to wash your hands

[Anonymous Coward]

I'm in the middle of it.. a few has turned our product into a play ground of new technologies.
The problem is that management is in on it, and I even heard that "the time when we develop own stuff is over".

Our company has always developed own stuff, that is what has sold many copies on the market and made us market leaders, aka: bleeding edge.

No need to say, that I'm about to jump to greener fields.
Moral of the story, watch out to follow tech visionaries.

Re:In IT, remember to wash your hands

[Anonymous Coward]

Manual transmission is the default in Spain, where I live. I'm guessing most of Europe is the same. There's a slim chance of finding a car with automatic transmission at the dealer (though it seems to be becoming more common), and sometimes you have to special-order it from wherever the main distribution hub is.

As an anecdote, I moved to Spain 6 years ago and wanted to buy an automatic car, mostly out of habit coming from America, and also my wife never learned to drive a manual. The car had to be special ordered from the distribution center outside Madrid, so I had no choice in color or any other feature... or I could have had one shipped over from Mexico if I wanted to have a choice in features/options.

Re:In IT, remember to wash your hands

[drinkypoo]

I'd say CUVs are a fad. They're for people who need a minivan but feel emasculated by not owning some ludicrous SUV.

Minivans are what happens when you take a car and stretch it into another vehicle. CUVs are what happens when you purpose-build a vehicle to do a job.

What's not to like?

Minivans get crap mileage and have crap handling.

Re:In IT, remember to wash your hands

[pnutjam]

Depends on the minivan. Mileage is not worse then CUV's, it's better in most cases. The ones I've been i are much roomier internally and way easier to get in and out of when you have multiple people. CUV's seem like getting a bunch of people in and out is an afterthought, not purpose designed...

I have one that handles like a car and one that handles more like a small truck, with an incredibly tight turn radius.

Re:In IT, remember to wash your hands

[TWX]

Chrysler's minivans have been purpose-designed from the wheels-up, even when they shared drivetrain engineering with the K-cars. Having worked on, restored, and junked-out cars, I can state, definitively, that Chrysler's minivans share very little, outside of the drivetrain, with any of their other vehicles.

The Town and Country we last rented got around 27 miles per gallon. It handled just fine.

CUVs are often based on the mid or full-sized sedan from the company, with a mostly-same floor pan with height extended suspension to boost it up a bit.

Re:In IT, remember to wash your hands

[Graydyn Young]

I can't believe I'm about to defend the development of a fad product, but here goes:

Sometimes there are benefits to a fad that we don't really see as developers. In my industry we call them "press release features". They may feel useless or even degrading to be developing, but they can have actual monetary value. For example a bank in the US just made a big splash by announcing that they will "support iBeacons". How will they be supporting iBeacons? I have no idea. I'm not sure that even they know. It's not important. What's important is that they got a lot of media attention, and give themselves a veneer of progressiveness.

Re:In IT, remember to wash your hands

[david_thornley]

My wife drives a minivan, partly for function. It's versatile and reasonably economical.

I, on the other hand, drive something cheaper with better gas mileage, which is functionally better than having two minivans in the family.

Re:In IT, remember to wash your hands

[david_thornley]

A friend of mine had a job with a company dealing with student loans, running COBOL on some sort of IBM mainframe, and everything was working fine. Then the new CIO decided he wanted to convert to Java on workstations (my friend thought it was likely resume-padding). The conversion of course took longer and was much more expensive than expected, and it turned out that the workstations couldn't handle the workload. (IBM mainframes are superb at reliably running large numbers of simple transactions, like the stuff you might write in COBOL.) I never heard about what happened later, since my friend was laid off about that time.

Re:In IT, remember to wash your hands

[cwsumner]

Beware of Fad Versus Functional

What's so IT-specific about this maxim, that it warrants being on Slashdot? A slow news day?

I think the news is that it is being told to the IT Managers, which is news all by it's self!

The problem seems to be worse in IT, since the managers often know less about the work than in other fields.

Re:In IT, remember to wash your hands

[Anonymous Coward]

Most of the CNC machines that I've supported run Windows 95 or 98[...]

That's funny. I'm actually a CNC lathe toolsetter/programmer. I don't think I would want to stand in the same room as one of those things while they're running. These things really should only be running on embedded systems or realtime OSes.

Re:In IT, remember to wash your hands

[serviscope_minor]

Minivans are what happens when you take a car and stretch it into another vehicle.

Nope. The Nissan Serena was about the same size as a saloon car on the ground. It was nothing at all like a stretched car. In fact it looked more like a van adapted to partial passenger use.

Minivans get crap mileage

I looked at a few CUVs online. They get similar mileage to minivans at the penalty of being able to hold fewer passengers in confort and haul less cargo.

and have crap handling.

Neither of them are race cars. My experience driving minivans is that they provide more than adequate handling for safe operation on normal roads when driven at an appropriate speed for the conditions.

Sure if you try to hammer round a tight curve well above the speed limit, you'll look like a fool at a much lower speed for a minivan than for a Bugatti.

If you like handling then nothing apart from a dedicated sports car will be adequate.

So true

[Anonymous Coward]

Sniffing Ruby in powder? You should try to bang Java again, maybe...

Duh?

[grasshoppa]

So bad executive behavior, which has been immortalized in dilbert for *decades*, is now worthy of an essay?

There's a certain sense of irony here.

Re:Duh?

[BarbaraHudson]

Remember all those "ask slashdot" posts that go something like "I was laid off at my job/have a crappy degree in $WHATEVER and I'm thinking about getting into software/mobile/web development.?"

We should at least give the poor sods a hint as to what lies ahead in their work environment.

Re:Duh?

[Anonymous Coward]

Remember all those "ask slashdot" posts that go something like "I was laid off at my job/have a crappy degree in $WHATEVER and I'm thinking about getting into software/mobile/web development.?"

You don't have to remember, see the next accepted submission.

I'm guessing that a lot of enterprise technologies

[spads]

... get chosen based on buzzword appeal by non-technical executives. And even if they seek technical advise chances are it will be from those who have been made fully buzzword compliant by past employment, education, and the media.

Implementation not the technology.

[jellomizer]

Agile Project management methodology has a lot of good features.
Cloud based processing can help the organization.
You can get a lot of useful information from Big Data (Previously Business Intelligence, Previously Decision Support System)

And they are still hanging on to Enterprise Class software.

But they jump headfirst without realizing what their main plan or problems they will use it to solve.

But what normally happens they just replace their existing technology and try to rig the new one to do what they did before and hope magically they will get a benefit from it.

These types of technology require you to change your full organization culture, and workflow to gain the advantage of the new technology. Just saying you got a big data project by joining all your DB tables in some big views and giving you a few reports isn't really big data.
Hosting your email on gmail isn't going to the cloud. Or even just remotely hosting you stuff on cloud systems, isn't embracing the cloud it is just offshoring your data.

Re:Implementation not the technology.

[Anonymous Coward]

Did you get that information from a common core school book? Stay away from that garbage (on all subjects).

Cloud - A new buzzword applied to the old idea of storing your data on other people's servers, all under their control.

If you work in an organization that has your own servers and your own Internet connection, then you have everything you need to establish your own "cloud". You can access your data from anywhere in the world, and it remains under your control.

Now "IT Leadership" and "Cloud" are two things that should NEVER go together. But, because "IT Leadership" is usually some papper pusher that has a background in finance or sales, and no real tangable IT knowledge, they often see the latest buzzword and just buy into the idea, no matter how bad it really is.

Re:Implementation not the technology.

[lgw]

Agile Project management methodology has a lot of good features.
Cloud based processing can help the organization.
You can get a lot of useful information from Big Data (Previously Business Intelligence, Previously Decision Support System)

Heck, none of these are very new, other than perhaps the scale of Bug Data. Agile was new around 2000. "Cloud" was all the hype around 2007. These are proven ideas now, though as you say you have to understand them, you can't just move your systems and hope fore the best.

Hosting your email on gmail isn't going to the cloud. Or even just remotely hosting you stuff on cloud systems, isn't embracing the cloud it is just offshoring your data.

A lot of people don't get this yet, though moving all your back-end systems to be cloud-hosted is as good as you can often get with legacy systems. Though the DB servers are often the sticking point (even if you can get cloud-hosted servers that work with your software, which is wonderful when you can, you still need to get the data there, and otherwise you have to be very careful what cloud servers you try to run your own DB servers on - sometimes there's no way).

Obviously, that's a lot of work, to think through security, availability, supportability, and so on, because the solutions to each are different in the cloud. They may be easier once you're done, but it can be quite difficult indeed for admins to abandon their tried-and-true bag of tricks for an environment where they need a new bag!

Re:Implementation not the technology.

[Anonymous Coward]

Cloud - A new buzzword applied to the old idea of storing your data on other people's servers, all under their control.

Well, there's your problem - you don't understand the term, or why the concept is so powerful. Cloud is a lot more than "store my shit on someone else's server."

"Cloud" encompasses horizontal scale-out, application redundancy (for HA and disaster recovery events), load-balancing optimization, operational flexibility (often using Software Defined servers, storage, networks, etc.), and I'm sure I'm missing plenty. If you think standing up an FTP server and having people push files to your FTP server means you've implemented a "cloud", you're a fucking dolt, and are 99% of the problem with "cloud."

Re:Implementation not the technology.

[Anonymous Coward]

They are ideas so they are nothing without application.Most of people doing 'agile' never read manifesto and if they did they understood 'no documentation'. As for cloud we still struggle with what it is, what it is to deliver and why we need it in the first place besides being a great idea.
You are like all the gurus I met so far - no substance, lots of BS.

Re:Implementation not the technology.

[NotBornYesterday]

I'm going to assume that "Bug Data" was intentional. I'm using that one.

Re:Implementation not the technology.

[cogeek]

Tell that to the Azure clients who suffered a 3 day loss of access to their data because some "dolt" forgot to account for leap-year in their programming. http://www.forbes.com/sites/ci...

Re:Implementation not the technology.

[Anonymous Coward]

Tell that to the Azure clients who suffered a 3 day loss of access to their data because some "dolt" forgot to account for leap-year in their programming.

Yeah, that never happens except in "the cloud." Developers never make errors when they're deploying to systems owned by the company they work for! It's absolutely unheard of for a business to experience a few days of downtime caused by developer error!

Again: I see your problem. "Cloud" doesn't promise that you'll never have an outage, or you'll never have to plan to eliminate single points of failure in your application and business data.

If you can't afford to have your data unavailable, then you build your application with appropriate redundancy and DR plans - regardless of whether you're hosting it yourself, or hosting it in someone else's cloud.

So what would I tell the Azure clients who lost a whopping 3 days? "Fire the developers who told you that "Cloud" would make you immune to outages, and designed a system where the "Cloud" is a single point of failure."

Re: Implementation not the technology.

[Anonymous Coward]

Blah blah blah. If you don't do things the way I think they should be done, then you are a fucking dolt and you are everything wrong. Blah blah blah.

Re:Implementation not the technology.

[MachineShedFred]

Why the hell would I want to tell an organization that is more focused on their actual business that they need to spend hundreds of thousands of dollars to build up a datacenter over weeks / months worth of time when I can literally do it myself using Chef / Puppet and Amazon EC2 in a few days, and we're not on the hook for any hardware maintenance or replacement in the future?

The business gets to keep focus on the business without the overhead of running a whole datacenter including power, cooling, wiring, real estate, countless admins, service contracts for hardware and network gear, construction costs, built-in costs for future hardware replacement and scaling, etc. etc.

There's a reason why lots of people are following Amazon into this space. It's possible to do things right, and to do it cheaper. And you are far more agile in needs should you be successful by pairing their load balancing services with something like Chef or Puppet. Oh, and just do your offsite backup out of "the cloud" to a box at your office, and an off-site at a regional or whatever.

Yes, there's some risk associated with the "Amazon / Microsoft / RackSpace / Whoever fucked up", but it's far more likely they'll figure it out and get it back up and running far faster than if the same fuckup occurs within your private datacenter, because datacenter is their business while the company I'm working for cannot say the same.

Re: Implementation not the technology.

[Anonymous Coward]

Blah blah blah. I don't understand things, get called out for being ignorant, and then have no substantial response to any of the arguments put forth that handily counter my assertions. blah blah blah.

I never said "Cloud" was the right fit for every purpose - I said "Cloud" is a lot more than just "store some shit on somebody else's server over a network." If you can't fundamentally grasp that, then you are, truly, a fucking dolt.

Re:Implementation not the technology.

[nine-times]

I would say that it's not just the implementation, but choosing which thing to implement in the first place. A lot of these fads, whether it's "big data" or "cloud computing" or "agile development", have become popular because they're extremely useful in some cases. The mistake, sometimes, is in thinking that you've found a single solution to solve all problems, and applying it everywhere will fix everything.

Someone else here used the example of the language "Ruby" as a fad that was useless because Ruby is "awful". That doesn't seem right to me. In my experience, which is admittedly a bit limited (I'm not actually a programmer), it seems like different programming languages have their own strengths and weaknesses, so you may want to choose a specific language for a specific goal. However, realistically, in the projects that I've managed, it always made the more sense to take into account (a) the language any current code is written in; and (b) the languages my team is most comfortable working with. If you have a bunch of PHP programmers who only know PHP well, working to revise a web application written in PHP, then Ruby is probably a terrible choice. But then, Perl and C++ would also be terrible choices. Those aren't bad languages. They're just not the best choice for that particular project.

I don't want to start a shit-storm by talking about languages, since as I said, I'm not a programmer, but I think that example is simple enough. Similarly, "cloud storage" like Dropbox can be great for small teams working from different locations on small office documents. On the other hand, if you're a big company with tons of people working in a central office, editing video files that are multiple gigabytes each, then you're going to want some kind of internal storage. The issue isn't about implementing your Dropbox well, but making an appropriate choice for your needs.

Re: Implementation not the technology.

[Anonymous Coward]

Sorry you got called out for being ignorant. I think I can see why there might be some confusion. Blah blah!

Re:Implementation not the technology.

[Anonymous Coward]

If you have the talent to not make simple mistakes, then the cloud is not for you, do your own hosting. For many other non fortune 500 companies, access to good talent for an affordable price is hard to get. You're better of getting a the occasional 3 day leap-year outage the the every-other-month random other problem outage because you can't afford decent talent..

Re:Implementation not the technology.

[plover]

When will it be learned that choosing the right methodology for a given project is the best way to go.

It comes to understanding the methodologies. What makes each effective? What are their weaknesses? Do you have enough good people who can execute them?

Waterfall is often appropriate, especially when it comes to physical world engineering, or for software products that cannot and will not be changed. Agile is great when you are committed to fully automated testing, have a committed stakeholder who is an active participant, and can deploy on demand for low cost.

But many clients now expect instant updates like they experience with their iPhone apps, and it's very difficult to deliver like that with waterfall. Agile is the answer, but for legacy projects that lack adequate testing, it's a big challenge to migrate to agile, and requires the business be put on hold while the developers clean up their technical debt. Most businesses can't afford such a shift.

Re: Implementation not the technology.

[Anonymous Coward]

You do realize that all those things you just said can be done totally well on one's own hardware, right? Or that most actual "cloud" implementations don't need or use horizontal scale out? You might be confused because the hyped and publicized ones do though.

The defining characteristic of "cloud" is "on someone else's stuff that you get a monthly bill for", sold to management as a way to be rid of those pesky IT types who insist on actually taking more than a minute and a half to do something complicated.

Hey, but you're fully buzzword compliant so you must be a good consultant.

Re:Implementation not the technology.

[Anonymous Coward]

Yes to all that and more, But the shit breaks and it's all about the wet, slippery, plunging, and sucking feeling when I send my cloud buddy a fat wet one.

Re: Implementation not the technology.

[Culture20]

The defining characteristic of "cloud" is "on someone else's stuff that you get a monthly bill for", sold to management as a way to be rid of those pesky IT types who insist on actually taking more than a minute and a half to do something complicated.

Well, we've removed a cost center for the company and only increased our risk by an unknowable percent. It's working so well that we're planning on outsourcing our middle management to cloud intelligent systems from the same company. Since our whole company relies on the success of this cloud provider, maybe we'll by it to reduce our risk then do the same thing with their IT cost center. We'll double the savings!

Re:Implementation not the technology.

[david_thornley]

Applying one methodology rigidly to every single project is also not Agile. The Agile manifesto says "Individuals and interactions over processes and tools".

Re:Implementation not the technology.

[david_thornley]

One of the ideas of the Cloud is that you don't need your own servers and big Internet connection. There's lots of things that can go wrong with those, and the cloud provider has competent people running them. They're not perfect, and obviously no cloud provider is going to be as interested in keeping your business up and running than you are, but it's a way of avoiding a whole class of mistakes. Whether this (and horizontal scaling etc.) is worth it is a decision that is best made by the individual enterprise, balancing the good with the bad.

Re:Implementation not the technology.

[cwsumner]

I'm going to assume that "Bug Data" was intentional. I'm using that one.

Ha! ... Me, too! 8-)

well obviously.

[nimbius]

I'll have you know im very well versed in that which is fad, and that which is function, you insensitive clod. I attend my scrum stand-ups daily to make sure I get updates about our Cloud. once thats taken care of, I write the most functional devops scripts in nothing less than the latest ruby code to ensure our SAAS, PAAS, DAAS, and GAAS are all ITSG A OK. Now if you'll excuse me, I believe my Zune is finished charging.

Hahaa....ha...ha

[Anonymous Coward]

Those making the decisions will be gone with their golden parachutes long before any shit hits the fan about their "value" added decisions

Some practical examples

[Dimwit]

So over my nearly 20 years in IT/CS, I've seen a few:

I worked for a large retailer. We migrated from an old frame-relay leased-line network to a much more capable multihomed IP-over-VPN configuration to connect all of our retail locations around the country back to HQ. This new system worked well. Our CIO retired, and a new one was brought in. CIO Magazine a year or so later had an article about "Satellite Internet, The Future?" Our CIO then "spontaneously" started lobbying to get us to scrap our efficient, inexpensive, high-bandwidth network for a satellite system.

I can't tell you how many projects I saw rewritten in Ruby on Rails just because that was the new hotness, only to be abandoned later when everyone realized that Ruby is awful.

I myself wrote a bunch of stuff in Erlang not because it was the best language but because that was the new hotness.

Two unchanging things I've noticed are:

A lot of time, the new hotness makes common problems go away or common tasks easier, but ends up making more complex things harder. This isn't necessarily a bad thing, but people tend to get stuck in the model of thinking that the new technology has to be used for everything, and they end up shoehorning their complex projects into frameworks that aren't the best choice.

No matter what the new technology is, and no matter how fantastic it is, it's not going to replace C/C++ for systems-level work, and Python and Perl aren't going anywhere. Truly successful technologies have long tails.

Re:Some practical examples

[Anonymous Coward]

LOL, so Ruby is awful by Python an Perl are truly successful technologies? They're similar languages with similar strengths and weaknesses.

Re:Some practical examples

[Anonymous Coward]

Your history sounds much like my own. Get job with company with rock-solid infrastructure that just plain works. Smart leaders leave for more money. People that replace them are not so smart, they feel the need to have their names on the decisions and infrastructure, so everything is scrapped and done anew -- much to the chagrin of the very capable people who put the old systems together. We went from Solaris to Windows in one year. In other words, we went from heaven to hell in one year. Malware hit the servers, the workstations, you name it. I was moved from being a BSD admin running the Web backend stuff to working with Windows. I was miserable and to this day, despise working with Windows in any regard. It's just not a very stable OS compared to FreeBSD and what was Solaris.

Now? I work for a non-profit that is slow to make decisions, and some of them are made poorly by people who think too much about the cloud and listen to the vendors who have swooned them with lunches and free support for a year.

If I ever run IT in its entirety, I would standardize on some form of UNIX-like OS, likely FreeBSD in the server room and Linux or Macs on the workstation front. Anything else has shown me to be unreliable. The scripting and devops stuff is easier in *NIX and always will be. Nothing wrong with old school. It works. It always will. Simple is always better.

Re:Some practical examples

[Anonymous Coward]

No matter what the new technology is, and no matter how fantastic it is, it's not going to replace C/C++ for systems-level work, and Python and Perl aren't going anywhere. Truly successful technologies have long tails.

Why not mention Fortran and Cobol why'll you're at it? Python and Perl were the newest hotness decades after Fortran and Cobol were no longer newsworthy.

Re:Some practical examples

[Calavar]

everyone realized that Ruby is awful

I'm tired of hearing this. Ruby is not awful. It's a wonderful language, and Rails is a wonderful framework. The problem is that Rails is designed for a very particular niche (small, fairly CRUD-oriented web applications), and people keep trying to stupidly shoehorn it into places where it doesn't work well (large, enterprise applications that need to do lots of heavy number crunching or querying of enormous databases in the background). Predictably, such projects end in a trainwreck and then people blame Rails, but Rails wasn't the problem.

Re:Some practical examples

[Trailer Trash]

Yep. I've used nothing but Ruby/Rails for 8 years now and it has increased my productivity to a level that wouldn't have been possible 15 years ago. But I just spent a weekend writing a C program, my first in 10+ years. Why?

Because I need to be able to analyze wav/aif files and create a fancy "waveform" like soundcloud. I have a great little Ruby gem for doing it and it takes 3-4 minutes to generate a PNG of the wave form for each audio file. My C program takes .05 seconds to do the same. Yes, I got a speed up of about 3000-4000 times by using my own hand-written C that takes into account everything that I know about optimizing code. I started out doing assembly and machine code (I'm serious) 25+ years ago so I know what makes a modern CPU fast. Ruby ain't it :)

But that's one little piece. Most of my applications are pulling data from databases and putting it on the internet - speed like that would be of little value and it would take me 5 times as long to write the code in order to get a minimal speedup.

Use each tool where it's appropriate. But don't claim that "_____ sucks" just because it doesn't fit your needs.

Re:Some practical examples

[Anonymous Coward]

If I was given carte blanche to do what I wanted with an unlimited budget, I'd be tuning things for the company.

It is nice to think about a MS-free enterprise, but that is like trying to run an enterprise without RAM chips or CPU dies. Exchange is the standard (and unless a company is IBM or Google), it is expected (and in a lot of ways, is the law, especially when audit time comes around.)

There are a lot of other factors. Is the company in just one campus, or decentralized? Are there stores to worry about? What is the company culture like?

Then there are the company departments. R&D would get a lot more autonomy than finance or HR. Finance would be completely separated from the Internet with a VDI and terminal servers handling stuff. This way, a user can browse the web to their heart's content, but a compromised browser won't hand the ledgers out because the browser is on a separate machine.

Even though IT is hit by a lot of worthless fluff, there are things that are useful:

1: VDI. This provides another layer of security past the usual core/edge/segment firewalling.

2: IDS/IPS. If Sony, Target, and Home Depot had one that was properly configured, they would not have been breached.

3: Diskless machines. Nothing wrong with booting from the SAN, especially because it has dual paths, and more redundancy than two internal drives.

4: Cloud backups that are encrypted. Key management is an issue, but if one treats cloud storage as a medium with specific pros and cons, it can be useful for archiving stuff as a last resort, so if the on-side copy and the copy stashed offsite are bad, the business still can keep going.

5: On the opposite end of storage are humble tape silos. They are not fancy, but simple, secure, and archival grade. NetBackup is expensive, but once set up, it can just be forgotten about (especially if one uses disk for the main backups, copies/moves stuff to tape for offsite/archival storage.)

Nothing fancy, but something as simple as booting from the FC HBA means a lot less running around chasing failed HDDs in the rack.

Re:Some practical examples

[Anonymous Coward]

everyone realized that Ruby is awful

I'm tired of hearing this. Ruby is not awful. It's a wonderful language, and Rails is a wonderful framework. The problem is that Rails is designed for a very particular niche (small, fairly CRUD-oriented web applications), and people keep trying to stupidly shoehorn it into places where it doesn't work well (large, enterprise applications that need to do lots of heavy number crunching or querying of enormous databases in the background). Predictably, such projects end in a trainwreck and then people blame Rails, but Rails wasn't the problem.

Pretty much any "instant gratification" framework suffers from the same problem. To get a gee-whiz demo app up and running these tools are marvellous. 5 minutes and you're done!

The problem, is, once people see the basic app, they want all sorts of bells and whistles added, and the IG frameworks get their productivity by basically pre-writing a simple boilerplate app and using it over and over. Extending it requires a lot more expertise and frequently a lot more pain as well.

And that's even BEFORE you consider Enterprise needs such as security and performance.

The "get rid of the programmers because now monkeys can do it all" products have been around since mainframes ruled the Earth and no one ever learns.

Re:Some practical examples

[MoonlessNights]

This is very true. While new ideas can be useful (or even great - everything was new at one point), the hype of the fad leads to tunnel vision where we only talk about how they will revolutionize everything.

The problem I have seen with the power of the fads is that they often become vague and redefined by everyone to fit what they are doing. "Cloud" is a great example: is it a common execution dialect, a remote storage system, or a flexible infrastructure virtualization system? "Agile" had the same problem a few years ago when everyone was doing it, even though their implementations were about as diverse as they were without it.

The "trendy" programming languages are frustrating since they are justified as being "great" because of their abilities to solve small problems with concise (or even terse) expressions. Since few people actually deal with large systems, they don't realize that most of these languages are really only good for prototyping or other small problems and big things are still written in C, C++, or Java for very good reasons.

It is why "legacy" has come to mean "actually works".

Re:Some practical examples

[Anonymous Coward]

The problem is that RESTful web services and the Javascript frameworks that use them heavily are designed for a very particular niche (small, fairly CRUD-oriented web applications), and people keep trying to stupidly shoehorn it into places where it doesn't work well (large, enterprise applications that need to do lots of heavy number crunching or querying of enormous databases in the background). Predictably, such projects end in a trainwreck and then people blame REST and Javascript, but REST and Javascript weren't the problem.

FTF-2-years-from-now.

Just within the last few weeks, I've had to explain why Ember.js (specifically Ember Data) and the expectation of a REST-ful web service weren't appropriate for an action-based service back-end. This caused many headaches for our resident Javascript-hipster developer. The action-based service can take a series of small snapshots of data (300 bytes each) in a single connection from a mobile device and perform a massive series of data operations, then return a pass/fail for each operation. A REST-ful one would require many back-and-forth connections with multiple operations being coordinated by the client.

Using an action-based service with a small, simple data transfer entity keeps transfer time down and speed up, which is very important on a connection that sometimes is a spotty, low-quality EDGE connection with 20 miles of dead zone between towers. (Yes, believe it or not, mobile "apps" aren't just used in huge cities with good cellular coverage.) Operating in these environments requires batching of transactions, and batched operations have to be fast, accurate, and fault-tolerant. Each transaction needs to be under 1 second round-trip, nothing gets lost in transfer, and a repeated transaction has to be caught and handled appropriately (no duplicate data).

And Ember.js is by no means the only so-called framework with these problems. The whole "convention over configuration" movement (as in, turd) is the cause of the latest incarnation of this same problem. Let me speak directly to the designers of these "frameworks": Your conventions don't work for anything but the one case you thought of so stop calling what you make a "framework". A framework is something that is generally usable by many different designs. Your "framework" is garbage that is unconfigurable for anyone else's design. [end rant]

Re:Some practical examples

[rwa2]

Ugh. Never played with Rails, but I've had to convert a lot of bash / python cluster management work into Chef / Ruby and it's been awful. I easily spend 10x longer doing trivial tasks, and in the end, I have to write a bash ssh job to verify that chef did the right thing anyway.

To be fair, there's a lot in the framework that I do like... the somewhat built-in unit and integration testing (which, for some reason, is surprisingly absent in production where you'd most want it). I sort of like the RuboCop coding convention watchdog, mostly due to the irony of it making ruby even more sensitive to whitespace formatting than python ever was. But for the most part, all this stuff just adds more pieces that randomly breaks things every 3 months, and most people trying to get actual work done end up disabling and ignoring all of it, which is a shame because doing things in The Chef Way(TM) also balloons every little 10-line bash/sed script into a monstrosity spanning multiple overlapping files, attributes, templates, and data bags. It's also dog slow and wasteful to nuke-n-pave for every little change, and/or inconsistent about deploying rolling updates and giving you no mechanism to roll back (OK, so it does provide some backup of some configuration files it touches, whooop-dee-doo).

I left my old job largely because the new tech manager wanted to introduce Chef as the silver bullet that would launch them into the next phase of their career, and forced hundreds of prod machines to start using it while they were still figuring out all of its vagaries. Of course the final straw was that we weren't allowed to in any way blame Chef on any outages or project delays, since the execs were already breathing down his neck for the ham-fisted migration.

Got another job still doing Chef-based work, but at least now I have support from management to take as much time as it needs to maintain things properly. Still spend way more time maintaining the tool instead of plying our trade, but whatever, it pays the bills. OpsCode has really got a little cottage industry going in maintaining DevOps job security, and I get a lot of coffee breaks while "waiting for my ruby scripts to converge in test-kitchen".

Re:Some practical examples

[phantomfive]

A lot of time, the new hotness makes common problems go away or common tasks easier, but ends up making more complex things harder.

Well said.

Re:Some practical examples

[Anonymous Coward]

Yep. I've used nothing but Ruby/Rails for 8 years now and it has increased my productivity to a level that wouldn't have been possible 15 years ago. But I just spent a weekend writing a C program, my first in 10+ years. Why?

Because I need to be able to analyze wav/aif files and create a fancy "waveform" like soundcloud. I have a great little Ruby gem for doing it and it takes 3-4 minutes to generate a PNG of the wave form for each audio file. My C program takes .05 seconds to do the same. Yes, I got a speed up of about 3000-4000 times by using my own hand-written C that takes into account everything that I know about optimizing code. I started out doing assembly and machine code (I'm serious) 25+ years ago so I know what makes a modern CPU fast. Ruby ain't it :)

But that's one little piece. Most of my applications are pulling data from databases and putting it on the internet - speed like that would be of little value and it would take me 5 times as long to write the code in order to get a minimal speedup.

Use each tool where it's appropriate. But don't claim that "_____ sucks" just because it doesn't fit your needs.

Re:Some practical examples

[Anonymous Coward]

which is a shame because doing things in The Chef Way(TM) also balloons every little 10-line bash/sed script into a monstrosity spanning multiple overlapping files, attributes, templates, and data bags. It's also dog slow and wasteful to nuke-n-pave for every little change, and/or inconsistent about deploying rolling updates and giving you no mechanism to roll back (OK, so it does provide some backup of some configuration files it touches, whooop-dee-doo).

I am a glutton for punishment maybe...but it sounds like Chef chose the "abstract above the OS" method. Sitting at the ruby level, avoids platform-specific issues.

The reality is: nope, just adds another layer to the mess. This stuff should be standard at the (virtual) filesystem/OS (perhaps POSIX) level...if not there, that is where it belongs.

That is a nightmare too.....but at a certain level, at some threshold of "lots of code" has been passed, starting from scratch + making a filesystem with all those features + porting it everywhere, ends up saving time.

Just my 2c. I am a glutton for punishment, but package management / configuration changes / rollback should be standard part of a modern multi-user, networked OS + filesystem...not some third-party application "on top" of the OS.

Yes, lots more work. Yes, more "dangerous" and more serious problems. Yes, take more time to do right and more money. In the long run, you can only throw so much baggage on top of a poor foundation.

Stating the obvious maybe. I just have never understand Chef + Puppet and similar. Why does the OS not make these stock? Even then, does any OS use these as part of the base system, well-tested and well-supported because they are the standard way to update software/patches/etc. ?

The approach has always been wrong, IMO. On the other hand, reality is, you will never get all OS vendors to agree on a standard (maybe POSIX, most were presumably kicking + screaming the whole way), so perhaps I demand too much.

Re:Some practical examples

[Anonymous Coward]

COBOL still makes the world go 'round.

Re:Some practical examples

[Anonymous Coward]

How the general programmer thinks:
-> It doesn't mather how fast my program is, what mathers is how fast I can develop it.

How the user thinks:
-> I want to run 100 programs on the same computer.

I happen to be both a programmer and a user, and for me it mathers that my programs aren't bloated.

Re:Some practical examples

[Anonymous Coward]

+1

Sadly, "Ruby on Rails" sounds like it's better than just plain old "Ruby", or "Sinatra" or "Passenger" or whatever. As such, it "ticks the boxes" higher up the chain where reality doesn't come into play.

Re:Some practical examples

[Anonymous Coward]

And the grand daddy of all the "get rid of programmers" systems was COBOL. It was actually intended for business users to write their own code in. The 'get rid of the programmers' trope has been around for nearly 60 years.

Re:Some practical examples

[cwsumner]

No matter what the new technology is, and no matter how fantastic it is, it's not going to replace C/C++ for systems-level work, and Python and Perl aren't going anywhere. Truly successful technologies have long tails.

Why not mention Fortran and Cobol why'll you're at it? Python and Perl were the newest hotness decades after Fortran and Cobol were no longer newsworthy.

I think that "newsworthy" is the key word here. The news media and the internet forums seem to live by shouting "new" at everyone.

Besides, there are still "fanboys" for Fortran and Cobol around! And I heard a rumor that someone has an Object capable Fortran, but I don't know if it's true... 8-)

Useful != Add Value

[Anonymous Coward]

If Sven Gerjets is such a critic of buzzwords, perhaps it would have been pertinent to speak about useful/meaningful/appropriate outcome; qualitative measures to ensure so.

Rather than "add value", itself such a buzz-word.

Cloud.

[Anonymous Coward]

Cloud.

Re:Cloud.

[BarbaraHudson]

Cloud.

Fog

It's like the could, but at ground level, so you can actually SEE it.

Imagine being surrounded in a fog of data.

(okay, it's just servers in a closet somewhere on the premises, but now that so many have moved to the cloud, it's a way to sell them back their old servers at a premium price, BOfH-style)

Nonsense...

[Anonymous Coward]

Nonsense... high level IT people (IT directors, CTO, etc) aren't worried about whether it really 'adds value' for the company or not, they probably won't be around (at least in my last few jobs) to have to deal with the consequences - the only consideration for them is that it 'adds value' to their resume/CV, so they can move on to that next job with "Successfully transitioned company 'Z' to a cloud based architecture cutting datacenter and hardware costs to virtually nothing" (ignoring, of course, the fact that it's all falling apart slowly after them).

Not meaning to put down "the cloud" there, there are instances where it can be a benefit, but in general the decisions aren't made on that kind of 'case by case' basis, they come down from "on-high" by executives who have no real idea about the technology beyond what they've read in "CIO magazine", and are 'mandated' on an all-or-nothing basis. Rarely does said executive actually wind up sticking around to deal with the outcome of their 'sweeping change'. And, of course, by then the next exec comes in with some brand new thing being touted ("now we'll focus on 'big data', and 'flattening out the organization') and even as the last thing is maybe just barely starting to become stable it's time to move in some new direction.

What the fad is perceived to deliver is good.

[digsbo]

A lot of times, what it comes down to is that a fad is simply a popularization of a particular approach to a problem "x". Solving "x" has value to the company. If you can reasonably get buy in to solving "x" (i.e. scalability, richness of user experience, flexibility of deployment), then you can use misplaced faith in the fad (respectively: cloud, Web 2.0, virtualization) to get the executive buy-in to solve that problem, whether the implementation makes use of the fad or not.

Agile.

[Anonymous Coward]

I predict Agile will completely subsume Cloud in the next five years.

Re:Agile.

[Anonymous Coward]

Agile is a useless piece of shit. Especially the stand-up meetings. I guess it is necessary to keep some otherwise irrelevant managers employed.

yeah don't just jump into that modern technology

[s1d3track3D]

I'd love to comment but I have to finish up my hadoop task on AWS before the end of this sprint.

Re:I'm guessing that a lot of enterprise technolog

[Rob Y.]

A developer in my group was asked to provide code from our system to another group for inclusion in their system. The code implements a complex algorithm that nobody quite understands (a PHD student at the time was trying to be impressive, and wrote up a 20+ page tech document to describe it). In any case, the code works, and they want to copy it.

So my boss comes back and says "the developer wants to know why this was written in C and not C#". Okay, I guess they're going for an all Microsoft solution, and I won't comment on whether or not that's a good, bad or indifferent choice (though you folks can...). My point is that the code in question was written before C# even existed, and while the offshore kid in the other group might not have known that, my boss certainly should have. So maybe what's left of .NET is a viable toolset to use to build "apps in the cloud" (did I mention that the other project is a complete rewrite of an existing system to be in the cloud - which i don't think is a particularly bad idea, btw). But maybe it's not. And obviously, the people deciding to use it probably have no idea even what .NET is (partially due to the Microsoft PR machine's history of not knowing what .NET was...).

NodeJS, cloud

[Anonymous Coward]

That is all.

Re: NodeJS, cloud

[Anonymous Coward]

oooo looks fun, my turn. Ruby, cloud. that is all ;)

Really?

[Anonymous Coward]

What is with all the cloud hate?

AWS and Google Apps have been awesome for me- for SMB's its really the best option. For some troll food, I am typing this on a chromebook.

Cloud is just a BS marketing term for hosted- I am paying google and amazon to do something at an economy of scale I could never match with colo back in the day. Used properly there is no reason to fear what is new, you dont want to be one of those enterprises that IS STILL running windows XP.

Its a balance, you cant stand still.... and you dont want to run off the cliff.

Re: Really?

[Anonymous Coward]

and I bet your the one making all the decisions that are "best"
for you and not what's best for the company. selfish prick.

Re:I'm guessing that a lot of enterprise technolog

[gbjbaanb]

doubt it, a lot of it is chosen by developers buying into the hype of the coolest new technology or language or framework... which invariably turn out to be a pile of shit.

For example, a few years back all the talk was of Biztalk and some people developed their "this time it'll be great" tech products using it, and now some poor sods are lumbered with a steaming piece of legacy poo that they have to maintain and that costs them a fortune. Before that there was so much talk of functional languages (which are ok in themselves) that would be a silver bullet that solved all problems, and Ruby after that, and .NET before that, and ... well I could go on but its depressing.

I think sharepoint is the main technology chosen by non-techies but the techies are way worse for jumping on the du jour bandwagon.

Our industry embraces technology churn far too easily. Change might be good, but only in evolutionary steps, making things better. I think a lot of it is driven by people who either don't have the experience or simply can't handle the current tech and so see anything different as a chance to avoid being found out.

We had "cloud computing" back in the 70s

[naris]

It was called "Time sharing".

Re:We had "cloud computing" back in the 70s

[dave420]

And when you reached capacity on your mainframe you did what? Magically create a new mainframe in seconds? No, of course you didn't. That's the difference between mainframes and the cloud - "the cloud" gives you all the mainframes you could ever use. You either don't know about what using cloud services can provide, or are being intellectually dishonest. Neither is very becoming.

Re:We had "cloud computing" back in the 70s

[cwsumner]

It was called "Time sharing".

And when you reached capacity on your mainframe you did what? Magically create a new mainframe in seconds? ...

He -is- talking about the "Cloud", it just wasn't connected to the clients by a TCP/IP network. The Mainframes (plural) were -not- under the control of the user, they were "out there somewhere", just like today. And with the security and failure risks just like today.

It's true, most of what newcomers think is new is actually very old. Or at least you better hope so, because those are the ones that work.
But a new idea "here and there" can help a lot, fast networks are really nice. 8-)

systemd

[Anonymous Coward]

Oops, pardon me for saying that. Of course systemd is the greatest thing ever in the Linux software ecosystem.

The fad here is attempting to use anything but systemd, or saying bad things about it.

Many IT execs do not even know what ball to drop..

[Registered Coward v2]

In this essay, Gerjets warns that many IT executives drop the ball when it comes to "defining how a new technology approach will add value" to their organization.

In my experience, many IT execs are not involved in developing or do not understand their company's strategy and thus have no idea what the technology needs to accomplish. they respond to requests, or develop technology solutions without input from the actual users and thus deliver solutions that don't really do what is needed. Even worse, some are promoted techies who are enamored with technology and want what is cool without regard to weather or not it is actually useful.

Not About Functional Programming?

[Anonymous Coward]

I thought this was going to be an article about functional programming languages, and fads related to them.

In Other Words ...

[kjhambrick]

Beware of Toys vs Tools

-- kjh

Re:In Other Words ...

[suutar]

definitely true, but also beware of buying a hammer and starting to see glass stuff as nails

Mod parent up.

[khasim]

And he makes a FUNDAMENTAL mistake by focusing on "defining how a new technology approach will add value".

At the CxO level that is easy to do. It will allow the company to synergize your core with blah blah buzzword blah buzzword.

But the reality is that it is about adding more achievements and buzzwords to someone's resume so that they can move on before their choices bite them.

Re:Mod parent up.

[Anonymous Coward]

To supplement the parent poster: The RIGHT question would be:
How can we increase value while decreasing cost and risk?

Following Best Practice (ie. ITIL), you would start questioning at the organizational and process-level, before even beginning to consider technology.

These decisions must come from clear thinking and obvious gains, ie. the lowest hanging fruits.
Unfortunately, when people get caught in buzzwords and hype, they forget the fundamentals, and are easily misled by external counceling, which always favour some sort of unnecessary change for change's sake (hype), which in turn will require more counceling in the future.

What are the most immediate needs of the organization? It's not rocket science or glitzy. Often it's boring and dull, not very sexy, but it can affect the bottom-line dramatically, visible or not.

Re:Mod parent up.

[plover]

Following Best Practice (ie. ITIL), you would start questioning at the organizational and process-level, before even beginning to consider technology.

That way is also not a guarantee of success. If management is implementing their imagined-perfect new organization structure, they are often blind to the problems they are creating, believing the problem lies with the underlings who "aren't trying hard enough", or "don't believe in the vision."

Re:Mod parent up.

[mvdwege]

It is you that is making a fundamental mistake. Adding value is wat technology is for, technology is not an end in it self.

We, meaning IT, are here to automate processes. By automating business processes, we make more efficient business possible, thus adding value.

Simple...

[Mysticalfruit]

These are the questions I end up asking when someone runs into the I.T. department shouting that we need to upload all of our code to the cloud and power down our data center.

1. Does this technology put our companies assets at risk?
2. Does this technology significantly improve the performance/security/reliability without violating rule #1?
3. Does this technology put us in a situation where a single vendor/point of failure/attacker can road block us?
4. What are the long term costs of this technology compared to our existing infrastructure?
5. How disruptive is this technology and do it's benefits outweigh the disruption?

In many cases once we get into the conversation and the person has a better understanding of what's going on behind the scenes, suddenly "cheapass-hosting-services.com" stops looking like such a great deal.

Re:Simple...

[Anonymous Coward]

Or, just what the fuck is the driving business need that makes you think "going to the cloud" whatever is meant by that, is a good idea? Crickets usually.

Re:Simple...

[Anonymous Coward]

These are the questions I end up asking when someone runs into the I.T. department shouting that we need to upload all of our code to the cloud and power down our data center

Is that you Dilbert?

You can't ask those sort of questions their brains or something that looks like a brain may fry :-)

Re:Simple...

[Mysticalfruit]

It seems it's centered around some perceived benefit (usually financial). Well meaning bean counters who don't see the whole picture and get befuddled by glossy brochures. Though in my experience once all the numbers are on the table and we really start talking turkey, suddenly they realize the math makes no sense.

If you're a start up and you have zero infrastructure, the cloud makes perfect sense, until you get to a certain size and then it suddenly stops making sense.

Re:Simple...

[PaisteUser]

suddenly "cheapass-hosting-services.com" stops looking like such a great deal.

Move the first hyphen one word to the left.

http://xkcd.com/37/

Yes...

[redwraith94]

Beware the IT fad words like 'ecosystem'...

Re:I'm guessing that a lot of enterprise technolog

[gbjbaanb]

na, it'll be because they just aren't good enough to understand the C code. Tell the developer to grow a pair and start using the right tools rather than the only thing he understands. (and frankly, I doubt he'd be able to understand the complex algorithm anyway).

Agile hasn't been "new" for a long time.

[unimacs]

And the cloud / cloud services aren't going away anytime soon. I have a hard time thinking of those as "Fads" though they might be supplanted or the terminology might change in a few years.

"Big Data" for me is still a buzzword that I'm not sure I understand the value of for most IT shops.

Re:Agile hasn't been "new" for a long time.

[Anonymous Coward]

Believe it or not, but "agile" is still in its infancy implementation-wise. Very few IT departments / groups have REALLY cracked the code. Hint: You can't really call it "agile" when you've not even defined the "customer".. Stand-ups may be great for small tasks, but simple to-do lists would work just as well! Thing is, people tend to do exactly the same things as before, just calling it by different names and changing the rituals a bit. That's not "agile" or even change. "Agile" should mean you're shifting focus to what's MOST important and do LESS of what's less important, but who's really doing that, I mean REALLY?

Same with "lean". People start to do stand-ups, and think they're "lean" just because they're standing for 45 minutes arguing about every little detail, completely missing the entire scope and methodology that is "Lean"! You shouldn't even think you're doing anything "lean" if you've not defined your processes and then at least ONCE recorded the REAL processes and their associated tasks, costs and realistical increase in complexity.

"Cloud"? Don't get me started on the "cloud" please. What is it? If you cannot define it, just stop using that word, please. Hint: NIST

"Big Data" is actually useful for everyone that needs to reevaluate what they're currently doing and planning for the future. That should mean EVERYONE. Learning directly from your customer data should be invaluable information to most governments, institutions, businesses and organizations. The point of Big Data is that you should be free to ask anything, in order to learn even new ways to ask! Otherwise, it'd just be old school BI. If you don't see value in Big Data, it's either because you don't care about your business, or you don't understand the concept and implications of Big Data.

Fads?

[doom]

Fads in IT? Unheard of.

PowerBuilder

[Anonymous Coward]

I'd love to comment, but I have some SSL work to do in PocketBuilder, while I support my longer term upgrade path for my 'legacy' PowerBuilder apps (Not a hack against PowerBuilder, it has a very long, successful tail for us).

Meanwhile, I'm currently watching a 5-year project (which has been going for 7 years now and still has nothing in Prod) to convert these apps into web apps (even though all the users are internal users on our network) get delayed yet another year because they forgot to add time for testing, and did I mention that the 'new' technology will be an entirely Swing based COTS system (with no test harness) that we are outsourcing from a vendor in Europe whose main language is not english? Can you say LOTS of customization at great expense via contractors anyone? I knew you could.

Ya, great successes await my team, I am sure. And they will likely instead come from transitioning our existing business logic into a RESTful web-services layer in DropWizard while the Swing based COTS system slowly fails and costs us literally 10's of millions in wasted capital project budget.

Good times.

In IT, Beware of Fad Versus Functional

[koan]

This is why I still use DOS.

Re:In IT, Beware of Fad Versus Functional

[cwsumner]

This is why I still use DOS.

Some places do, particularly for machine controls.
And strangely enough, they never get Viruses or Trojans!

Implementation not the technology.

[Anonymous Coward]

What a travesty Agile Project Management is!

That's not to say Agile doesn't have its good parts, but blindly applying any one methodology to every single project MAKES NO SENSE! The methodology dujour has changed a few times in the last 20 years, and its the same mistake every time. When will it be learned that choosing the right methodology for a given project is the best way to go.

Anyone remember the Visual Basic fad?

[GoodNewsJimDotCom]

Sure, we had Java at the time, but for some reason Visual Basic caught on big time in the late 90s. After going to school for software engineering, I had to completely remember how to program in subs. Subs are just like functions, except you need to remember to never use the same loop variable you used in the parent subs :P

Re:Anyone remember the Visual Basic fad?

[Anonymous Coward]

So, like a cheap ass macro ?

I've always been too "disgusted" at what little VB code I've seen and what people who use VB say to even try to learn it.
Don't think I missed anything.

Fad: low contrast web pages

[QuietLagoon]

There's a fad trend in website design the past couple of years. Low contrast text, i.e., light grey text on an off-white background.

.
Readability appears to be taking a back seat.

Failure to Capitalize on Previous Tech

[Anonymous Coward]

I've been in the business for a long time now, about 25 years. My theory is that a lot of fads are driven by the failure to properly exploit previous technology waves. There is an element of "technology X was disappointing, but shiny technology Y promises to deliver all our hopes and dreams!"

Truly, I can count on the fingers of one hand the number of times I've seen tech that basically works, but the implementation sucks. It's a basic, not very impressive deployment. Instead of spending time optimizing that tech, the leadership starts chasing the latest buzzword.

A post-deployment, optimizing step is what is so often missing from our lives. Or an effort at pre-deployment intelligent exploitation of same. Hey, I can dream...

Re:Failure to Capitalize on Previous Tech

[Blaskowicz]

Your passage between quotes is exactly the same as the television ads for diapers I remember. Diapers Y was a lot better than Diapers X, but a couple years later Diapers Y now makes the baby cry and wet itself. Diapers Z is now required to make baby and mom happy and laugh in saturated colors.
One brand of laundry detergent even had a "Vista" in their upgrade cycle. It was so good at eating the stains that it was leaving holes in the clothes too.

How about Experience?

[bussdriver]

Doesn't everybody learn from experience about jumping into fads at some point?

Is this just a problem for new IT being given power too soon or am I wrong and we have a lot of IT people who never learn?

Re:How about Experience?

[Mysticalfruit]

Oh yeah! I was migrating all my machines from 10Mbit Ethernet to 155Mbit ATM only to see it completely eclipsed by 1Gbit ethernet before I was even done with the project. Got burned on that one!

No, Thank You

[Anonymous Coward]

I'll stick with my FreeBSD servers and my Linux workstations, thank you. All this talk of cloud, agile, scrum...

I've been running IT infrastructures for almost 20 years using FreeBSD, Linux, and some csh, Python, and BASH scripts. I keep everything simple and relevant. No cruft. Nothing runs on the machines that is not needed exactly. I've ran VOIP systems, Web servers by the hundreds, written provisioning scripts that do about everything, all in house, no outside help. A relative newbie that understands UNIX could look at my scripts and feel at home. They take me a little longer to write because I document everything and make sure everyone understands what is what.

Short of a HW failure, I've never had a FreeBSD server fail that was in production. Plenty of trial and error in the test lab and at home, but I refuse to go live with something that I don't trust. I trust no other server OS but FreeBSD and OpenBSD for pf (firewall). I run a VOIP system now, a firewall, a mail server, and a series of POS systems across three campuses. Simple, easy work because we keep it simple. We are a no fad shop. The youngest of us is 38. Our oldest just left and he was a hair under 70. Everyone here likes simple, easy and predictable. BSD gives you this. Everytime.

Author doesn't understand agile

[Tony Isaac]

Nor do many people who profess to use it.

In 25 years, I have yet to see a type of project that couldn't benefit from an agile approach...done correctly, of course. At its core, Agile is about breaking down a big project into manageable pieces. This process can be done logically, and it can be done nonsensically.

Solving simple problems in a difficult way

[Casandro]

In IT there rarely are any hard problems. Few people operate Google scale data centres, few people do automatic voice recognition or video codecs.

This somehow seems to cause a desire for solving simple problems in difficult ways. You suddenly have complex frameworks to do more or less trivial things because you are trying to abuse something that's never meant to be used in a certain way. More and more non essential features get crammed into projects.

If you want to stay ahead in IT, avoid complexity. Simple ideas seem to persist in the long run. A typical example is the Unix philosophy. It's an attempt to make everything as simple as possible, so simple that a single person can write a cut down implementation in just a few months. Another example is the Internet. IP is a wonderful simple protocol. You just throw in a packet and it may or may not arrive on the other end. Compare that to ATM or ISDN and you will see how much simpler it is.

As a rule of thumb, if someone tells you about a new technology or trend, ask them to explain it to you in 1-2 sentences, no more than 20 words. Either they will fail, in this case you'll know that it's either just a buzzword or far to complex, or they will actually say what it is.

Oh No!

[soccerisgod]

A blinding flash of the obvious!

"technical debt"

[TechNeilogy]

In my experience, a huge fraction of the marketing surrounding any IT fad is the promise that it will magically erase or prevent technical debt. This is attractive because in many ways technical debt is THE great unsolved problem of software engineering. TL;DR there is no magic bullet; the only solutions are craftsmanship and paying the technical debt up front. Unless management understands this, no IT fad will ever solve the problem.

Re:"technical debt"

[david_thornley]

Technical debt is not THE great unsolved problem of software engineering, because people who know software engineering know things they can do about it. It's mostly a management issue, compounded by what is perhaps the largest problem, getting management to take the techies seriously when they're talking about what they know.

Re:I'm guessing that a lot of enterprise technolog

[cwsumner]

... I think a lot of it is driven by people who either don't have the experience or simply can't handle the current tech and so see anything different as a chance to avoid being found out.

Actually, that's probably a lot of the reason for problems, in techs -or- management.

People entering a situation where they know little have a tendency to do things to invalidate the existing knowledge, so that they are on the same level as everyone else. This can be particularly bad with new managers and can destroy companies. Beware, you might not even be aware that you are doing this! 8-P

Also, an appalling number of people only know one thing, and have no idea that they could learn other things. In the software field, I am talking about the programmers that are "fanboys" for one language and don't know any other. Often this is a "new" language taught by a vendor, that is not useful for all (any?) jobs.

Real programmers know more than one language and more than one computer system. If you don't, it might be a good thing to "study up" on. Even if it is only one of the single-board "toys" you can get for around $35. 8-)