Software Craftsmanship with Adam Sroka

Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich.

Roy vandeWater: I’m Roy vandeWater.

Clayton: Joining us today, we’ve got consultant at Industrial Logic, Adam Sroka. Welcome, Adam.

Adam Sroka: Thanks for having me.

Software Craftsmanship

Clayton: Taking a little back straight to the audience, we met Adam at Agile Open in California few months ago or weeks ago now. You had some interesting things to say about some kind of things in the software craftsmanship, maybe more of the technical side of things, so we’re curious what you thought about that.

What do you think of the software craftsmanship movement or how that’s affecting the industry right now?

Adam: That’s an interesting question. For the most part, I’m a fan of the software craftsmanship movement. There’re a lot of really good ideas coming out of there and people really pushing some things forward that I think came out of extreme programming that maybe have gotten neglected by a lot of folks in the community as they go other ways. Software craftsmanship is backlash is against that.

Although, sometimes I have to admit I feel they go too far the other way, pushing against the Scrum. Kill all the managers, kind of thing.

But I think that we really do, as a community, need to focus on being technically competent because it’s so important to what we do. Especially, look at Lean Startup and those kind of things, how they are really pushing the boundaries of what we can do as businesses based on having these technical disciplines.

We are going to have to practice those to get them to that level where they are really going to make money for people.

Getting Started With Software Craftsmanship

Clayton: Let’s say that I’m a developer and I’m working on the Scrum team or in some Agile team or whatever, I am interested in the software craftsman thing, but I don’t really know where to get started. What’s a good first step? If I want to improve my technical skills, for instance, I say, “I realize I may be deficient. I want to get better. Where do I go next?”

Adam: There are a lot of good places you can go. I think it depends somewhat on language, what environment you work in because there are some really good books out there. There are really screen casts and stuff where you can watch the way other people work and learn from them. Just as a minimal investment kind of thing, just getting in where you are.

Then of course, if you’re willing to travel and go and meet people, there’s some excellent software craftsmanship oriented conferences now. There’re lots of code fests and those kinds of things, so there’s community opportunities to learn from other people. Even people who are really willing to invest a lot, have gotten into this touring craftsmen idea.

It really depends how much you want to put into it, but the resources out there are really amazing. Compared to when I first started programming, I don’t really have any of these things out there. I had to figure it out on my own. It’s really cool nowadays.

Reducing Technical Debt

Clayton: If I flip that question on its head and say, what I am say, a Scrum master or a product owner, or something. I realize my team’s generating lots of technical debt. We have lots of defects, and we were not testing. I hear about all these things when I go to user groups, but my team’s not doing them.

What are some ways that you could drive that from that side of the equation to try and help people who are on your team become better in a technical sense?

Adam: Sure, it’s challenging. A lot of folks find themselves in a position where they’ve been developing on some project for a really long time. Maybe they more recently adopted Agile, and they feel like they don’t really have a lot of this. They say, “Oh, all this tester and development stuff and everything, that’s really cool. But there’s no way that it will work.”

Sometimes you’ve got to build incrementally towards it, and try little things. I don’t know that there’s one right or wrong answer of how to start there. It helps to have some skilled help, to get a coach. But you can do a lot just by experimenting and seeing where you are, and definitely measure it. Pay attention to what you are doing, and measure the results.

How long are you spending re‑factoring in the red, and those kinds of ideas. If you invest in figuring those things out, then you have metrics on which you can improve. I think that’s the area that really is pushing the boundaries that we really need to get more into as a community.

Touring Craftsman

Clayton: A few minutes ago you mentioned a term that I didn’t hear before. You mentioned a concept called a “touring craftsman.” Would you mind explaining a little bit about that?

Adam: Yeah. I don’t know where that started, but it’s become popular in the craftsmanship community. Particularly in Europe, I think it started more in Europe.

There are some folks around here, Corey Haines, in particular. He left the job and toured around the country in his car going from shop to shop volunteering his time working wherever they would let him work. Now, others have copied that.

In Europe, they have this idea of industrial tourism where like two companies will actually just swap people for a brief period of time, so they get exposed to the other environment, get to bring back new ideas, challenge some of their own assumptions about how they should be working, that sort of thing.

I couldn’t send you straight to any of the links, but if you look at like the software craftsmanship Google group, there are folks in there talking about doing it. I think some people have even been talking about putting together a website where you can kind of list the companies who are willing to participate in this.

Industrial Logic has been doing it for a while, very informally. Anytime you’re up in the Bay area, you can show up at the Berkeley office. If Joshua or anybody is in town, you’re welcome to compare or pair on our code with us, that sort of thing. It takes a lot of different forms, but that’s the idea.

Common Technical Excellence Anti-Patterns

Clayton: In your experience, doing some consulting, working with different teams, things like that, what’s a common pattern that you see that kind of violates some of the eXtreme Programming XP principles or maybe violates some of the kind of technical excellence stuff? What do you see a lot of teams doing?

Adam: There’s a lot of different ways to go with that question, but the one that I guess I’ll focus on because it bothers me the most is your teams adopt Scrum coming from something else, whether it’s just sort of a hacking environment or a cowboy coding type of thing or a more formal like waterfall process, but they come into something like Scrum and they’re told we got to have shippable software every two weeks.

Then what they try to do is they try to take whatever they did before and shrink it into two weeks. It just doesn’t work.

That’s just not the right way to look at the problem. It’s not the right way to solve the problem. Figuring out how to get to smaller resolutions, when we’re working really the way at least Agile craftsman like to work where it’s truly TDD or BDD, so you’re working very tiny cycles and you can compose those tiny cycles into much larger changes, but they happen very incrementally. That mode of working is so vital to being able to really realize the benefits of what something like Scrum is promising.

That’s the thing I wish more people were aware of and more people were focused on. We don’t just want to bang it out in two weeks. We want to get disciplined at working in these tiny increments.

Clayton: Yeah, that’s a good point. I think we see a lot of people that are told that they have to start doing Scrum. You’re right, there isn’t a lot of direction from a technical setting. That’s kind of a thing that’s becoming a little more pervasive in Scrum or in other Agile communities. It’s not enough just to say that you’re going to do this methodology. There are some other things that go along with it. That’s a very good point.

Adam: I like the way David Anderson puts it from the Kanban site. He made the point that if you estimate two weeks’ worth of work and you expect to get those done in two weeks that should happen about half the time because there should be statistical normal variation in your estimates.

Aiming for two weeks’ worth of work is kind of missing the point, need to do something different to get two weeks’ worth of value.

Software Craftmanship Gone Too Far

Clayton: In the introduction you talked about some people may be taking the idea of software craftsmanship too far. Where do you see the downfall or maybe some pitfalls of software craftsmanship or maybe some things that people who are not as nuanced might be getting misled? Where do you see the problems or the side effects?

Adam: I really have a lot of respect for the people who are sort of the leaders of the software craftsmanship [indecipherable 09:49] right now. I think that they have the best intentions and they’re working in the right direction.

Where I would caution people, is anytime you get a new sort of movement, it tries to differentiate itself from the thing that came before it. There’re a lot of sort of anti‑Agile or post‑Agile ideas coming out in the craftsmanship community.

I try to caution people about that. Craftsmanship really isn’t saying anything particularly new, at least the underlying principles were there in XP since the beginning and probably in whatever came before XP as well. It’s not like, “Throw everything else because here’s this new thing.” It’s another piece of the puzzle. It’s another way of looking at things. It’s valuable that way.

But, don’t say, “Oh, you know, I’m a craftsman now, so I don’t need iterations or I don’t need to have a Scrum master or whatever.” That’s taking it a step too far, I think.

Introducing Software Craftmanship To The Team

Clayton: Looking at it from another perspective of somebody who’s in charge of an Agile team, whether I’m the product owner or the PO of a company, and I’m seeing that they’re constantly producing unstable output that is defect ridden and is causing all sorts of problems.

How would you recommend that that type of would motivate their team to start caring more about software craftsmanship?

Adam: It’s tough. It’s a complicated question. It’s really a people question.

So really you’ve got to get down into the details of, “Why are people doing what they’re doing? Why aren’t they doing something else?” In order to get that, you really need to bring in expert people who know how to uncover those kinds of things.

What it really implies is does the company care enough about this idea of producing great software and not having defects and all these kinds of things? Does it care enough to invest the money it’s going to take to really get under the covers and figure out what that issue is?

Because I really doubt it’s the fact that you’ve got an office full of professional programmers who don’t want to act like professionals. That just doesn’t seem plausible to me. I think there’s probably something more going on there.

Software Craftsmanship Two Years From Now

Clayton: Where do you see the software craftsmanship movement or the community? Where do you see that in say like two years? Which, I guess, in this industry is a long time.

Adam: I hope to see a lot more of the same. I hope to see that there’s been some interesting movement in terms of tool support in some languages. We’re doing some actually cool stuff in Industrial logic in terms of being able to measure what developers are doing inside the tools and figure out, “When did they re‑factor? When were their tests passing or were they failing?”

Some of that’s been around for a while, but we’re going beyond what we’ve had before and hopefully soon building some really new cool stuff. But, that’s sort of the idea, measure what you do. Balance what you’re doing to improve against what the measurements are telling you, you need to improve. That’s what I hope to see more of in a couple of years.

We’re already leaning that way, but I think, also, maybe we’ve extended like the [indecipherable 13:24] metaphor as far as it’s going to go. Repeating the same thing over and over again isn’t going to get us what we want. What we want is to really measure it and improve it scientifically.

Improving Technically

Clayton: From a personal development or professional development perspective, what are some things that you can look back in your career, your experience that you feel really helped you improve either from a technical sense or from maybe the process sense? Is there anything you can pinpoint, any experiences in particular?

Adam: Yeah, I think moving around a lot. There are good parts to that and there are bad parts to that. But, I’ve seen a lot in a relatively short career.

I’ve been doing this professionally for about 13 years now, so I know a lot of guys who have been doing something like what I’ve been doing for maybe 20 years. But, they haven’t necessarily done more jobs than I have because I’ve just moved around a lot.

That helps. It gives you a broad perspective. It gives you that consultant’s mentality of, “Yeah, this is where you are today. But, you could be at a better place if you tried this, that or the other because I’ve seen it.” That I think has been really valuable to me. But, it’s not the path for everyone.

The other thing, too, is just continuing to focus on the technical side of things. There have been plenty of opportunities in my career where I could have gone to management side and maybe made some more money, but it has never appealed to me.

I always wanted to stay in the details. I’ve been able to make a decent amount of money and have an influence in the community while staying technically focused and I think that if you want to do that, you should do that.

Clayton: If someone listening wants to find you online or go to your blog or whatever you have, where would they go look?

Adam: You can look for me on Google Groups (software_craftsmanship). I’m particularly active on some of them like the Scrum development and XP, Yahoo Group and I’m all over them. If one of them interests you, hop on there and you may see me. I don’t have a blog up right at the moment.

If you Google my name, there’s some old ones out there on the bigvisible.com and a couple of other places. I should have a new one coming up sometime soon, but I don’t know the details of that yet. So stay tuned.

Clayton: Is there any tool or a website or person or process or something that you’ve been real hot on or real excited about in the last couple of weeks maybe that you want to plug or let everyone else know about?

Adam: I just recently started Industrial Logic, so I’m trying to get up to speed on things going on there. I haven’t been paying too much attention to what’s going on outside of it, but Industrial Logic is worth checking out.

Are You Learning is excellent, particularly for folks working in Java, C#, C++. They’ve got some really excellent stuff there. Like I said, it’s moving. We’re trying to move it to the next generation where we’re really measuring what you’re doing and helping to give you useful feedback about how to improve.

Clayton: Awesome. Well, we really appreciate you taking your time to do the podcast. We look forward to talking to you in the future.

Adam: Yeah, thanks. Thanks for having me.