DevOps and Agile, useless marketing speak or is there something there?

MWS

Hi everyone,

I am on the job hunt in a pandemic and have been seeing a lot of listings talking about DevOps and Agile development? Perhaps I'm old school but as best I can tell, it seems like these are terms for management types to justify making one person do multiple jobs. One shop I am somewhat familiar with was fond of saying they were "Agile" but they produced buggy code that I was constantly having to fix.

Am I just being a curmudgeon or is there something actually useful in all this? It's basically impossible to search online since marketing and HR drones have blanketed the web with their useless verbiage.

20-100

MWS Agile condenses the lessons learned through decades of IT project management, so it is a good thing in itself. DevOps tries and implement agility from development to production to make continuous deployment possible.

These are indeed very good things, but how they are used in companies is another story. Which is easy to understand: agility sheds a crude light on the pointlessness of middle management, whose role boils down to forwarding orders downwards and sending spreadsheets with green lights everywhere upwards. Don't expect them to promote agility; instead, expect them to do all they can to make it fail.

It's a bit different in small companies though, particularly those created with the owner's money and not venture capital funds'.

Nowadays, every developer must know about agile and devops to pass the job interview, but they should carefully assess their new work environment before effectively behaving according to these principles.

Sam

MWS MWS

Perhaps I'm old school but as best I can tell, it seems like these are terms for management types to justify making one person do multiple jobs.

DevOps is not a job, despite many companies still don't understand what this term means. And NO, DevOps does not mean "All rounded IT+Dev person". There is no one in the world who could do both of these things together. IT is too complex nowadays.
DevOps is a practice for reducing barriers between the development world and the operation world, in order to let the business get the features they need as soon as possible.
To get them you have to:

Reduce useless bureaucracy;
Automate code integration and UNIT testing (Continuous Integration);
Automate application delivery in the test environments (Continuous Delivery);
Reduce the volume of changes in order to get small yet continuous improvements;
Reorganize the teams in order in smaller yet complete squads with all the people you need for your projects (devs, sysadmins, testers etc.)

...and so on...

As you can see no one of the above points is a job description. DevOps is a set of rules.
And YES, it can improve how fast and how better the features your business needs are delivered.

One shop I am somewhat familiar with was fond of saying they were "Agile" but they produced buggy code that I was constantly having to fix.

This is wrong at many levels.

The are producing buggy code, so I think they are not using extensively a UNIT testing framework to find bugs BEFORE the code is going to be delivered.
Implying that you are a sysadmin, YOU don't have to fix anything. Systems shall be automated and as immutable as possible. So if there is a bug in the application, there should be an ISSUE on the developers VCS portal, then a PR with the fix. After that, the entire automated process starts again. Fixing things by hands is a BAD practice, especially since we're moving towards containers that are considered ephemeral objects.

Am I just being a curmudgeon or is there something actually useful in all this?

Every of us who are working in the IT have to understand a simple concept: what it is really matter is the business, not the IT itself.
IT exists to allow the business to make moneys, and we were hired for that purpose.

Waterfall model and the entire ITIL concept, aka the "old school style", are the reasons of why IT sucks so bad.
By using the old-style waterfall model, you don't get less buggy code. By letting 50 people approve a change because they are "THE MANAGERS", despite they're not even able to understand such change because it is not their job or because they have other priorities in their agendas, is not going to help you to release better code.
In fact you're getting code with too much CRs and PIs (and therefore too many bugs introduced), and often with also less automation. And all of that code is delivered in huge maintenance windows called RELEASE which will be followed by war rooms.