SB: It helps you maintain flow—I guess, another term people like to throw at you. You just focus on writing code and building value.
JV: How do you feel about the response towards CM in today’s market, given the rise of Agile? Do they still know what a configuration management is?
SB: I mean the agile thing. A lot of the early stuff on agile was about keep the main line working; focus on tests. For the most part that's not a bad approach. You have another group of people, especially a lot of tool vendors, push the idea of tools that enable you to see it streaming different stream. Sometimes it also just defers problems.
JV: How does it do that in that it just defers problems?
SB: If your argument is this is the common thing with a lot of approaches using tools. One conversation that happens a lot is the build keeps breaking, so what we’re going to do is we’re going to have people develop our branches. Then, we’ll do pull requests and we’ll stage the integration.
That in itself is not a bad thing. What the problem is is if the branch goes off for a number of days then you have to spend a lot of energy merging. Then, if you're merging a bunch of different changes you're just going to get a different kind of breakage. The problems still there, you're just finding it later.
SB: I'm not against branches and pull requests and things like that, but they're better as long as you're still integrating in the end and doing all the right practices; they’re not bad. Some people just use them as I'm going to build up my own universe and we’ll just defer the problem until later.
JV: Can you talk about the growth of agile? How it’s evolved over the years?
SB: Yeah, it's been an interesting thing. When people were first talking about agile it was people who were really into it. They read all the books. They tried to understand the principals of what was going on. There was actually a big cultural paradigm shift. It wasn’t about just a bunch of practices.
Agile is about focusing on value, getting rid of waste. Then, it becomes a little more buzz worthy. People are like “We unit test.” The joke I've heard people say, like Bob Martin does in talks, is “We’re agile. We don’t do documentation,” and they basically—all the things that are important—they just throw them away. They're not understanding why they're not doing them.
Now, it's even to the point that people out of school will say at a career fair, they’ll ask if you're doing agile without really having done a lot of it. They’ve done some unit testing, but they’ve done school projects or they’ve done small projects.
Which actually leads me to another interesting thing, I've been thinking about. I guess the good news about that is that people now are doing agile are maybe starting to think a little more that agile’s more than just about the practices or not just about even the values. There's got to be a culture change that underlies what goes on.
SB: So, my wife’s cousin’s got an interesting assignment. He's actually started a company a long time ago, called Culture Change, that's involved with safety, developing safety cultures. When I was married into the family I met him and we talked. I said there's got to be something about this that ties into agile software development. There has to be. He wasn’t a software guy; he was a manufacturing guy, so we had some nice conversations.
Last year I was noticing that Joshua Kerievsky had been talking about this thing called, I don’t know if I'm going to pronounce it right, anzen engineering.
The theory there is thinking about safety as you're doing your work; how does this increase or hurt safety. Safety in a larger sense, not just is someone going to hurt themselves. Is it going to add project risk?
JV: Right, definitely something that changes.
SB: I've known Josh from my patterns days or from the early patterns conferences. I said did you know about this? It might be interesting and he went to one of Steve Simon’s workshops and just thought it was amazing. Steve called me and said Josh is a great guy. It was great to see that happen.
Anyway, I think that might be an omen or portent of people who are doing agile are maybe re-realizing that it's not just about the tools or techniques or whether you're doing Scrum or XP. It's about an underlying set of culture and value changes.
JV: We need to talk about safety and some of those things. I mean we could even talk about security. How does agile development fit in with the old school way of thinking? With CM, everything has to be secure and safe, but now it's a rapid pace. How are those two being resolved?
SB: I was saying about the pieces right? Agile’s not just about moving fast. It's about moving fast and testing and validating as you go steps.
JV: Sure, yes.
SB: I think the big difference is that you can do agile just as well. I don’t know if this is entirely true, but when I was first talking about CM in the context of agile I'd say something along the lines of the old way is that you ensured quality by making things move very slowly. You would reduce risk by making things move very slowly.
SB: Agile’s more about reducing risk by finding problems sooner because you can't ever really eliminate the problems and by going slower you actually introduce business risk.
JV: Sure, which in itself is a problem.
JV: Got you.