DevOps isn't just about the new: It's about cleaning up the old, too

As one of my coworkers used to say when confronted with The Latest Development Improvement Methodology: “Why don’t you come down here and chum this stuff?” – except he used the language of a sailor. In trying to implement the latest breakfast cereal agenda, DevOps, one of the primary chumming tasks is dealing with all your “ …

[Anonymous Coward]

DevOps isn't just about the new: It's about cleaning up the old, too

"Because you're obviously not buying the wonderful, new fantastic way to do things that is better, cooler, hotter, sexier and will make you feel as a IT Deity (after paying for seminars and courses and For Dummies books) so we need to point out that whatever you've been doing so far is wrong and stupid and ugly and will cause a plague o' locusts o'er the land and need to be fixed before you're fired".

Are you absolutely sure DevOps isn't the brainchild of Marketing types?

[Dale Vile, Freeform Dynamics]

Re: DevOps isn't just about the new: It's about cleaning up the old, too

Yes, very sure. The DevOps movement was started quite a few years ago by IT practitioners. It was largely driven as a community thing (with strong links into the open source world) until quite recently (last couple of years) when the marketing guys jumped in. Having said this, I personally think there is a bit too much elitism and religion in the whole DevOps space, which together with the escalating marketing hype from the commercial side, makes it all sound a little idealistic. If applied well, though, DevOps principles (and the continuous delivery approach) can deliver some pretty solid benefits.

[techietubby]

Re: DevOps isn't just about the new: It's about cleaning up the old, too

I think that the idea of IT specialists becoming DevOps engineers is good in prinicple just like when analysts and programmers became analyst-programmers as you can eliminate a lot of staff and do more for less.

I have worked for a lot of large organisations and many have too many departments, and the suffer from compartmentalisation and duplication that cripples their efficency. When you add Agile Scrum into the mix you replace quality with quantity or throughput and this results in more problems than it solves. Imagine if your heart-surgeon broke down your operation into simple tasks and aneathatised one day, start to cut holes in you and then decided to wait until the next sprint before completing the job?

I agree that starting with the low-hanging fruit and quick-wins is a great idea, but it does NOT mean you should just ignore those things that are too difficult.

[yoganmahew]

Smack my forehead...

"Judiciously, you start replacing capabilities in the legacy system with new code that’s more aligned with your new approach to software development, using some mild routing intelligence behind the facade to figure out when to call the legacy code versus the new code."

If only I'd realised it was so easy! Why, the way you say it makes it sound like thinking it is enough... Granma, fire up the webby front end, granpa, let's turn the code rot handle and judiciously, ya, hear me be judicious now, replace that intergrated message service application with a XML app.

Now, where did I leave my underpants...

[SecretSonOfHG]

You realize that there are no "low value" applications, right?

In a mature enough business context everything that remains is there for a reason. After a few rounds of business re-engineering If some application was a barrier for productivity, it has already been removed. This is because either the application has value, or not, but there are no "low value" applications.

[Anonymous Coward]

My manager heard about devops yesterday

As far as I can tell it is mainly about automating systems administration. Well, the last I heard, any decent systems administrator is always looking to automate as much as possible. Doesn't it fit into the seven virtues of a sysadmin - laziness etc.

Puppet is a useful automation tool for systems administrators but I don't need it being turned into some bullshit bingo term like devops. </rant>

When looking at specifics of legacy systems. We are stuck with them so we have to work around them. Things like virtualization will make this easier but if they are really business critical, they will not go away and no amount of funky new terminology will make them go away.

[John 104]

"Judiciously, you start replacing capabilities in the legacy system with new code that’s more aligned with your new approach to software development, using some mild routing intelligence behind the facade to figure out when to call the legacy code versus the new code."

That has to be one of the most naive statements I've seen in a while.

If it was that easy, we wouldn't need the magic bullet of DevOps to accomplish this, would we?

[jmith]

New Shiny Phenomenon

There's a huge problem in the software industry. I call it the "New Shiny Phenomenon". Developers that are absolutely brainwashed that software needs a continuous life cycle. The reality is if software is functional and the users aren't complaining you should leave it alone and devote your time to something else. Just because it's old does not mean it's bad.

A good example of this is systemd. For decades systemv init worked perfectly fine and all of a sudden it was decided that this underpinning of Linux was legacy and needed to be replaced. A huge amount of wasted effort was put into place to replace a system that worked fine before. Effort that could have been spent making something else.

This really comes from developers that lack ideas and vision. Instead of setting their sights on new uncharted territory they play the power trip game and rewrite perfectly good software and attempt to grab political power in the process.

These developers are destructive and self serving and contribute nothing to the end user. Exactly what ground breaking problem did Lennart Poettering solve by reinventing the wheel?