This post is a placeholder for some notes I jotted down about a recent .NET Rocks! podcast (episode 1308) where the hosts, Richard Campbell and Carl Franklin spoke with guest Wes Higbee about software practices.
Notes
DevOps is dead on arrival, because we’re just seeing Agile, Lean, and other methodologies rebranded as DevOps.
Back when Agile was just getting started, people were basically doing DevOps anyway, i.e., everybody be responsible for everything. The parts of the organization inevitably do work together; the question is whether they work well.
DevOps is more of a fad, because it doesn’t solve anything that wasn’t already solved by Agile or Lean for people. It’s just a new paradigm with new buzzwords.
We’ve moved these two organizations (development and operation) apart because one is incentivized to deliver features, and the other to keep the systems secure from hackers. This creates a divisive “devs vs. ops” environment. If you don’t target that divisive attitude — why people don’t work well together — no Agile or DevOps process will have any impact.
We also have a division between “software people” vs. “business people.” This is in the Agile Manifesto — business people and developers must work together, as if software people aren’t business people. The next level of divisiveness is “our business” vs. “our customers.” Ultimately what you need is cohesiveness throughout the organization and the groups/companies it works with.
The underlying problem is that people have problems with not having common purposes throughout the organization. Agile is extremely nuanced when you look at practices and what people are preaching, there are so many sacred things about how you should develop software: You have to use version control, you have to write tests, you have to code-cover everything, you have to do pair programming. Very few people talk about the context in which these things are bad ideas. For any practice that exists, there is a context in which that practice would be a bad idea, because how we do things is not where we have the problem. We start without having a common goal of what we’re trying to get to.
Analogy: If you’re driving somewhere and you hit some construction traffic, would you change your destination because of that? The solution is to find a detour that gets you to your destination.
Some companies focus on the practice of automation. If you always do this, you can end up automating things you only do one time per year, which costs money.
More importantly, we’re human beings with very limited attention spans. Pick your battles, because the thing we focus on (e.g., automation) can become a trap, and then that’s all you see on your radar.
Why do we struggle so much with having a common goal? We all inherently have a fundamental belief as technical people: We are so close to logic that we think we are logical. We don’t realize the role that emotion/ignorance plays in most of our life. We assume that we’re reasonable, but in reality new things come up every day that bother us. Things that bother us in the moment steal our attention, so we reach for our “hammer” (because everything is a nail).
Example: If your solution to getting compliance to some process is to make that process faster, you may not realize that the process itself could be a bad fit. We can’t think beyond the tools in front of us.
It’s difficult to find a common problem/goal to put in front of everyone. What matters to us as individuals, does not necessarily matter to other people — we have a tendency to believe that others share our values, especially when we’re making snap decisions on a daily basis. This plays out in user experience testing — the developers are way more familiar with the UI and workflow than a new user.
Recognize that Agile, Lean, software craftsmanship, DevOps, and any of these movements/fads by and large deal with how we work. There’s no place for what we’re doing; it’s an operational concern, not a strategic concern. We have too many methods. We need to develop a skill of finding out what matters to other people.
Why do we focus on process rather than the larger paradigm thinking? It’s a control thing: We can’t control outcomes. We can control what we’re doing right now — i.e., how we do our work.
It’s counterproductive to have organizational standards on management philosophy. Each project might dictate a different set of constraints that would need a different philosophy or set of methodologies.
People are getting excited about DevOps because they think this is the glittering beam of hope that will make things always work out right. In reality, we don’t have control over the future.
An example of having a common goal is the “escape the room” game, where multiple people work together to solve challenges to achieve one goal: get out of the room. If you can let people do whatever they’re good at to get out of the room, you’ll find it’s a huge relief not to have to double-check people’s work, etc. It’s a “having your back” high — you don’t have to worry about others, because you’re all on the same page.
The goal also has to be something for people to care about (e.g,. improve patient outcomes).
The things developers are measured by — number of checkins, amount of code committed, percent of code coverage — narrows our focus to the how instead of figuring out what’s important.
If we don’t have a clear goal, all we have is our methodology, so we spend time improving that which we understand.
Some developers don’t want to think about the bigger perspective and get frustrated, saying, “Just tell me what to code.” In that case, micromanaging would be an effective match between manager and developer. It’s just not effective to use that management approach on every developer.
Just because a customer uses a part of your software doesn’t mean they like it.
The power lies in being able to pick and choose which one of these processes/methods to use that work best in the given context.
Sometimes it’s useful to try doing things slightly different (or using different tools) just to give you perspective on problems.
Dev and ops are artificial boundaries: In the end it’s all about delivering good software.
Putting people in teams can cultivate a we-they relationship, where you end up competing instead of collaborating.
It can be more useful to have more tools in your toolbelt than to have one really sharp tool.
You are not the code you write; what is a part of you is the result it has on other people, and that matters to us because we’re social creatures that thrive and are happy when we’re helping other people.