That is a patently false statement and total BS. It sure does crawl up your spine though doesn’t it? Why then do we need to do this?
I read an article, “How DevOps is Killing the Developer,” and, frankly, was a little put off by this:
Good developers are smart people. I know I’m going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?
Because each role can do the job of all roles below it if necessary.
Nice to know I’m almost as good as a developer. Now, I could go off on a “bash the developers” rant, but I think that would be seriously silly and counter-productive, not to mention completely against my beliefs. I really do like, admire, respect, developers. I also respect system administrators and SAN admins and QA people, hell, project managers. You can go find a web site or a blog specializing in any of these IT disciplines and locate the “DBAs are better than developers” article or the “QA people save the universe” article or “Thank the gods project managers keep all you poo flinging monkeys in line” article. They’re out there. And every single one of them is wrong.
My actual job title these days is Product Evangelist, but I’ve spend the last 15 years as a DBA, database developer and data architect. I feel like I have a handle on that job. I’ve specialized around the Microsoft stack, not because of any sort of religious beliefs, but because it pays the bills. Before that I worked as an application developer. Before that I was in tech support. And you know what, at no point in my career was any of the jobs I did literally more important than the others. You know why? They’re all in support of the same thing: the company succeeds.
Now, fine, developers are smart people. No question, no argument. Developers are capable of learning other jobs (I’m living proof). But you know what, so are people in all those other positions. How do I know this? Because I’ve worked with the QA person turned developer. She was a GREAT QA person. She was so great because she learned the full stack. She developed an understanding of databases and systems and code in support of doing a better and better job at QA. Then, she finally decided she wanted to fix the code a little earlier and switched over to development full time. I’ve also met the QA person turned sysadmin. I’ve met the developer turned SAN admin. The system admin turned DBA, the DBA turned developer, a million and one support desk people turned developer/dba/admin. Every one of these people followed similar trajectories. They started learning the full stack and found areas where they could specialize while using their knowledge of the full stack to make each position they were in better.
But all these jobs and all these people are all, or all should be, focused on one thing, helping the business to do what the business does, for most businesses, support the customer. Regardless, the focus needs to be on the goals of the organization, not on the purity of a job, a process, a software stack, or a system. Purity and perfection are dangerous concepts within IT. We need to keep our focus where it belongs, not on MY code or on MY database or on MY servers, but on OUR BUSINESS.
And DevOps (I wish the term didn’t have such bad connotations), is about breaking down communication barriers, not just putting all the work on one person/team. Again, focus back on the business and what the business does.
So no, I am absolutely not better than you (the title is just click-bait). I’m not. But, you’re not better than me either. If my saying that makes you angry, maybe you need to reexamine your assumptions.
You forgot to add the sales people to the list. Without them nothing is sold and therefore no money. Chicken/egg stuff.
True. I didn’t get into the whole business hierarchy, especially because there are different hierarchies depending on the business. I think this… superior? … attitude actually arrives when the focus on the business is lost. Developers aren’t the only ones that can lose it either. I’ve seen WAY too many DBAs focused on stuff other than the business too.
Outstanding article! To say that there is a “hierarchy of technology roles” is arrogant, and it also arises from a kind of willful ignorance. If someone believes that he (or she) can be an outstanding developer and an outstanding sysadmin and an outstanding DBA and an outstanding project manager (etc., etc., ad nauseum) then they don’t have a genuine, deep understanding of any of those roles – and they probably aren’t as good at application development as they think they are. As many studies show, we humans consistently overestimate our competence in areas that we don’t understand well.
But, I didn’t post this comment to bash the original poster, either. I’ve been running around my company for months saying that we need to get three groups of people together in the same room at the same time to work out solutions to our problems: Business people (business analysts, mainly), Data people (modelers & DBAs) and Developers. Business people are at the center: they know the processes that drive everything else. The data storage and retrieval systems need to model those processes as closely as possible. Finally, developers create the applications that provide the functionality that end users need in order to access the data and move the business processes forward.
But this functionality, which is the primary concern of developers, is only half of what we need to properly implement business processes. The other half is the data, and from the data flows most of the long-term business value of software. Application functionality is like the presentation layer for the business processes and data. It is vitally necessary (how else can users access anything?), but it is not the only thing you need by any means.
My vision is to implement for enterprise software development something like the “Quality Circles” that the Japanese have used with such great success in manufacturing. These are cross-functional teams that come together to solve the organization’s quality problems, and data quality is a big problem for most organizations.
Again, fantastic article! Let the discussion flow! 🙂
Great post, thank you! All people in an organization are doing specialized jobs, and the only thing I didn’t see in here was the interdependencies. Just sticking with sysadmin, developer, DBA… I couldn’t even get a cluster set up on my own, let alone debug issues with it. It’s not my specialty, so I depend on the sysadmins to make it work. It takes me a week to write C# code worth using. It’s not my specialty, so I depend on the developers to make that happen. However, I can make a database perform like no sysadmin or developer I’ve ever seen, it’s my specialty. I couldn’t do anything without the sysadmins or developers, and they’d limp along without me. We all depend on each others specialties to make the business work.
David,
You’ve nailed it for me. I’m pushing hard on this concept of lean/devops/assembly line/pipeline/whatever that says, we have a single goal and we need to figure out how to deliver it in a timely, efficient, safe fashion. And that means getting everyone in the room and talking to each other. Absolutely.
Steve,
Total agreement. Just didn’t want to keep going (tons more to say on this topic). The interdependencies are vital to the system or it just won’t work. I get it that in a start-up you’re going to have people where 2,3,60, hats, but that only really works when you can’t care about all competencies and can only focus on the core competency, whatever that might be.
I’m not sure where people get the misconception that DevOps is a melding of two teams and suddenly developers need to do ops work. It couldn’t be further from the truth. Capitalism is based on the division of labor because it WORKS. Why break that down? However, done correctly, DevOps is a wonderful thing. If I had a nickel for every developer who rolled out some “new feature” like Service Broker or FileStream and didn’t bother to ask a DBA and the result was a support nightmare…I’d be rich. Likewise, we had lots of DBAs who built customer systems without using version controlled scripts. DevOps is about one team helping the other in a “best of breed” scenario. I think “DevOps” the word freaks people out needlessly.
Dave,
Developers won’t do Ops work, but they do need to understand the problems the Ops people face, because they might have good solutions for some of them!
Likewise, the Ops people need to understand the issues that the Developers are facing (and how they can better support the Developers).
And everyone, absolutely everyone, needs to understand the business processes and the challenges facing the business.
Every business faces complex challenges that will require a broad array of expertise to solve. We are stronger when we work together as a team (and not isolated in our Ivory Silos). 🙂
@D. Moutray,
This is correct. Devs need to understand the amount of work caused by what they release in to the wild. This is especially true if the business is a software company. Not caring about the complexities of distributing things simply because it isn’t your (devs) problem is a guaranteed way to have botched installs and/or updates. These create business problems that move up stream. Ever heard of a client who stops complaining past the support desk front line? No, because it doesn’t work that way.
Excellent discussion guys. I think you’re all basically on the money. The core concept is to break down the barriers that hurt everyone. The walls we placed around production (and staging and qa and dev) slowed down the developers. Their lack of knowledge, or interest, in ensuring code deployed well hurt production. The fact that we couldn’t (can’t?) talk to each other made it all worse… You guys are nailing it. Now, let’s get the word out.
Grant,
I’m better than you are… at swimming, surfing and tidley winks. Although it’s been awhile since I’ve played tidley winks. I’ve been a professional DBA now for ~15 years and in development for 25+ years. I still think of myself as a beginner… in something. Right now I’m a beginner at MongoDB administration, but eventually I’ll have that learning curve behind me. I agree that team members should think of the enterprise whenever they consider changes to a system. I try to take whatever constraints are put on me and turn them into a learning opportunity. Hence I’m learning MongoDB administration, which comes out of a ludicrous “Plan B” foisted on us by our operations people. Instead of being incredulous and confrontational (at least in front of them) we listened to their concerns, considered the best interests of the business and came up with a simple prototype featuring a MongoDB database and HTML interface. I love my job… And yes the first line was to hook you into reading my rant.
Cheers!
Ha! I absolutely admire the first line. And I’ve never even tried surfing, so I could be better than you… I just choose not to. Ha! Kidding.
Yeah, I’m constantly learning too, even in SQL Server where I’ve spent 20 years.
Actually, you probably are _way_ better than me. So, I was wondering whether you might help me to improve and, while you’re at it, give me a hand with ….
(bwaah ha ha 8)
Sure, not a problem. I’ll send my consulting rate right over.
Ha!
[…] was going to write this a as a comment on Grant’s blog post, but it ended up being way too […]
Great things can happen when companies embrace “full stack” developers. But it also can leave employees in an odd position of not really specializing and having a very odd assortment of skills. (And apparently a painfully inflated ego in one case, but such is the internet.) When it’s good it’s great, when it’s bad it’s horrid.
As you point out, the statement logically fails because many of us *were* developers. I started as a developer. Now I bounce between being a DBA and being a security/infrastructure architect. If that statement was true, then as soon as we give up the developer monicker, usually for the good of the organization, we somehow become less valuable/smart/useful/important. Hah! I’d like to see someone try to defend that.
[…] I Am Better Than You - Grant Fritchey (Blog|Twitter) […]
Thanks for the contribution Kendra. No argument.
Great point Brian. Would the conversation go like this:
“We think you’re a great developer, but we’ve decided that we need you to specialize in the database sphere, so we’re going to cut your pay and demote you… What do you mean you quit?”
Great post! I’ve worked at those places where that “I’m better than you” and “without me you can’t do anything” mentality is alive and well. It was frightening how much work didn’t get done because of it. Thanks for your thoughts.
Grant,
This is a great topic to discuss and thanks for bringing to people’s attention. I also read the original article from Jeff Knupp. The company I work for has DevOps team and their major role is to support the Developers, QA and sysadmin by acting as a central hub of communication and automation during product releases. I am a DBA and I salute their expertise and helpfulness. But I have not seen any developer in out company having issue with devops. They are actually very much sought after for advice. So only based on my knowledge, I cannot say everywhere devops team is as effective. But I can make a general comment that no single person or no single team can survive without the help and expertise of people from other teams. And therefore, nobody is superior to other. If someone is very resourceful and specializes in more than one area, it is good for them. But that does not give them right to look down at other people.
Thanks for stopping by Ameena and that was extremely well put.