DevOps Zone is brought to you in partnership with:

Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

Developers Must Feel the Pain of Operations

  • submit to reddit

I firmly believe that software developers not being responsible for their software in production is as damaging, bad and stupid as bankers not being responsible for their losses. To further the analogy by paraphrasing a commonly used derogatory term about banking, developers not being responsible for the daily running of their software encourages “casino software development”.

Developers become enticed to take shortcuts, since they know they will probably be on a different project altogether once the software actually goes into production - it won’t be their problem anymore.

The disconnect between “software developer”, “tester”, “support engineer” and “systems administrator” that is so common today is one of the most destructive practices we have in software engineering. In many contemporary organizations, software developers rarely have to live with the pain of the shortcomings of their software, except for what turns up in testing. What is forgotten in that equation is that testing is often limited, it does not deal with the pain of evolving, improving and maintaining software in an ongoing operation.

There is one simple rule to human behaviour as it pertains to business and the workplace: most of us are not too concerned with pain/issues caused by our actions if it doesn’t fall on ourselves and it is highly unlikely that anyone will be able to pin it on you. It is an unfortunate order of things, but you only have to see the maintenance and operations issues in just about any software product where the developers move on after getting “sign off”.

In simple terms, I think the traditional way of doing software development is wrong. We should not be having “software developers”, “testers”, “system administrators” and “support engineers” as separate roles. They should all be a single roll rolled into one. Yes, we may have people with slightly different expertise, spending slightly different proportions of their time on the different concerns, but on the whole, the pain of both creating and running software should be one, shared by the whole of the team.

If everyone knows they have to live with the pain of any shortcuts they take today, they are much less likely to take them in the first place, and if they do take them, much more likely to do so as a carefully weighed conscious decision and much more likely to address them at the first opportunity when they encounter the pain. 

I omitted the role of “analyst” from this post originally, mostly because I think it more than anything shouldn’t exist. Everyone should be an analyst, ready to challenge and firm up requirements based on what the ultimate goal is.

Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike Haller replied on Fri, 2011/09/30 - 11:48pm

I was thinking the same. But it's not the right way either. If developers should feel the pain of ops, then the original guy who specified what the software should do and who paid the devs should feel the pain of the developers too: - maintaining legacy code written by other devs, under pressure (time/budget) - stakeholders changing their mind on what the software should be - stakeholders who just want to have new features without ever thinking about stuff to be removed - giving support to ops guys who never saw a JVM and dont care about the right tools to monitor it - understanding overly complicated code which in the end turns out to be completely useless - etc

Pierluigi Vernetto replied on Sat, 2011/10/01 - 1:32am

indeed, many tragic things still happen in this industry:


- developers are still allowed to write something like


try {

    subscribeCustomer('bla', 'mumble')


catch (Exception e) {





that is omit to trace context information in the logs


b) Operations are supposed to support software in production without having access to source code


c) Operation Support and Development are divided by Segregation Wall



Tom Wheeler replied on Sat, 2011/10/01 - 5:32pm

The title of this article really caught my eye.  I didn't need to read the actual article, though, because as a Developer I can assure you that we frequently Feel the Pain of Operations. 

Just last month,  Operations inflicted pain upon me when I discovered that the company-approved Linux installation lacked a graphical diff tool.  I felt even more pain when I learned that I could not install the binary from the intranet because it required a newer version of glibc than I was allowed to have, and I could not build one from source because the officially sanctioned (i.e. ancient) version of yacc installed on the machine has a bug which was fixed on the trunk four years ago. 

Just last week,  Operations caused me great pain (best described as a sharp pain in my chest that extended down my arm) when they pushed patches to my Windows machine that required me to immediately stop what I was doing and reboot, just as I was 23 minutes into a performance test which lasts about 25 minutes.


Andy Till replied on Sun, 2011/10/02 - 9:57am

Is it possible for devs to feel more pain? 


I think the issue is that the devs and probably ops too are having to make decisions which they do not have all the information to make.  This should be taken care of by the group/architect/tech lead etc so that the change is public and there are no suprises.

Nafees Sharif replied on Mon, 2011/10/03 - 5:42am

I sort of see your point but have to disagree partly. If developers are allowed to act as operations, then all project management practices (delivery dates, estimates and tracking progress, contingency) goes down the drain. I do principally agree with devops movement, but not on cost of loosing visibility into my projects. Yes, the developers and operations (and testers) should not be in silos, but hey, do one job at a time but do it well. For us, it helps us keep resources focused and they deliver faster (and most importantly) better products. It also eliminates the chances of resource hijacking or over-monopolization. To prevent silos, we sort of communicate openly and freely. More often than not, the operations' guy seeks help from development guy to solve/debug issues. So we sort of have the loop going but still keeping the responsibilities apart.

Mark Unknown replied on Mon, 2011/10/03 - 8:31am in response to: Tom Wheeler

+1 And the pain of Project Managers and Business Analysts and Report Writers and QA and Systems Analysis and Auditors and Management.

Walter Bogaardt replied on Wed, 2011/10/05 - 1:40pm

This is over broad, and the real disconnect is not in developers or operations, but in general project lifecycle and release management. Performance testing in a staging environment that closely emulates production abiet a scaled down version is often overlooked. This is typically in the domain of operations. Operations has data(user traffic load data, full production database) that supports production usage. There should be build kits that are handed off to operations that explains installation but it won't cover areas of loadbalancing and performance in a clustered environement, which is a gray area between developers and operational support. This is because staging servers are your last line to production, and normally you won't allow developers to connect to these servers to "debug" because they are testing load. This stage of the release process your running memory/cpu/disk profilers, and your logs are probably set to info level and not debug.

George Kalfopoulos replied on Wed, 2011/10/05 - 3:33pm

If you split the software maintenance from the software development process, you get exactly what is described in the article. A tendency to cut corners and a mentality like "ship the damn thing already". For me the article describes in some way the difference between product-oriented companies and services-oriented companies, or at least the ones I have worked for. If anyone cares more details are available on this blog post

Emma Watson replied on Fri, 2012/03/30 - 2:16am

Now a days in software engineering, this has been felt from so long that developers are not paying any attention to the operations of their softwares. Once they deliver them, they consider themselves not to be responsible for any further duty. Shortcuts taken by the developers bring the disasters in long run so high managment shall make certain rules and assessments shall be done to rule out the bad decisions taken by the developers.

What else could be done to make them feel the pain of operations? 

java program

James Walker replied on Sat, 2012/10/06 - 3:03am

Developers become enticed to take shortcuts, since they know they will probably be on a different project altogether once the software actually goes into production - it won’t be their problem anymore click here

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.