Software Craftsmanship with Adam Sroka

Episode 37

December 07, 2011




The Agile Weekly Crew and Adam Sroka discuss software craftsmanship.

Episode Notes

Clayton Lengel-Zigich and Roy van de Water are joined by Adam Sroka from Industrial Logic to discuss software craftsmanship.

Resources for software craftsmanship have increased in availability

Measure the results so you know if you improve

Industrial Tourism – exchange program between companies to refresh perspectives

Important to be disciplined to work in tiny increments


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

Roy van de Water:  I’m Roy van de Water.

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

Adam Sroka:  Thanks for having me.

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.

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.

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.

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.

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 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 VDD, 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.

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 cr