How developer maturity affects building teams.

A conversation with SVP, Senior Consultant Marty Bradley about how developer maturity plays a role in forming software development teams.

Hey Marty, so what’s the difference between a programmer, developer, engineer or consultant?

To me the biggest distinction is that developers don’t do things more than once. For example, one of the first things we try to get a team to do is move towards at least a daily build. Initially they will have to do it manually. What will happen with a developer is that once they have done that once or twice a night they get tired of it. Then they will sit up all night, download the free software and get the builds going. Then if the builds are breaking they will begin to manage the fact that the team isn’t following the process. Eventually the whole team starts to come up a level.

We are seeing more and more now that we have to drive that automation in by coaching or forcing them to do that.

So why do you think it’s not sticking, why people are doing it?

When I was brought up as a developer, they sat me down with a senior level guy who showed me how to write code. He told me “You don’t write a piece of code twice.” He would give me situational things and review my code as I built it every day and talk to me about development best practices. My stuff would work. It’s easy to get it to work. But it’s hard to refactor on the fly. There’s a practice called legacy rescue or dojos, which is a practice we are starting up, where basically we pair up senior level developers with the team to work side by side. This moves the development of the application forward and gives the in-house team the deep level of training that you need as a developer in order to be more efficient, building better quality code.

A lot of organizations think they have senior level developers, how do you think companies should go about assessing whether or not someone is a senior developer?

I think you should start by looking at technical debt. If you have a lot of technical debt and you’ve had a senior developer that has been on that team for a year or a couple of years and they aren’t doing something to take care of it. That looks like a problem to me. Now maybe the problem is that he is so senior that all the problems go to him and the other programmers aren’t doing much. So you have to free those guys up. Now this is the problem that we get into when we look at utilization instead of throughput. If you take your senior guys and give them a little bit more slack time they could spread themselves and their knowledge across the team. But what we have a tendency to do when we are in trouble is we give all the work to the one guy who we know will get it done. These are they types of things that we try to solve by going to team based development. We pair, we do things to help the senior developer free his time up.

If you were talking to an executive how would you express how this is impacting them?

You can show over time to the executives the amount of defects that can be decreased by refactoring that code. It’s well documented that technical debt causes slower lead time to completion, increased manual testing time, and lower quality code.

I once went into a team where every time we made a change to a webpage it seemed to filter through and then other problems would pop up even through the webpage seemed fairly well isolated. When we went back and looked at it what happened was that the next page that had a problem was 90% the same with a slight modification. What that usually indicates is that someone needed to do something specific, for a customer perhaps or add a new feature, and instead of figuring out how the page worked they just duplicated the page made the change and everything was fine because nothing had changed in the system. Once you changed the original page you have to remember to go back and change the second page. When you have 6 web pages like that, where everytime you make a change you have leaking defects through out the other pages that no one can figure out.

So how do you help these teams grow?

We take teams and teach them how to add refactoring into their development process and their estimates. When you write the first piece of code it’s hard to think in objects, which is a lot of the reason we want test driven development so that it forces you to think about the interfaces and the design. If you don’t start by learning test driven development you just don’t head down that path. So what we do is take teams that have been doing things this way and we pair them with a team. While they are helping them build the code they are teaching them ways to refactor. As a result the teams get a deep learning that they were never taught in school and the one-on-one mentoring that they need.

Another topic that everyone wants to know. How do you get QA integrated into the team? Not just on the team but fully integrated into the team.

To me QA has to be involved from the very beginning with requirements. We talk a lot about behavior driven development and test driven development. The QA people tend to look at the problem differently, so if we get them involved up front and talk about the edge cases they’re concerned with or the big problems they see in the system once it gets deployed you start to train the developers to look out for that. Then the QA people become more analysts helping to drive the requirements the right way. A good stand up would be where a developer says he is working on some certain code and the QA person jumps in and notices that he will need test data. Not only that but the QA person can get them recent test data they need complete with the edge cases that the QA person wants included. Over time they will integrate themselves into the team and things begin to flow a bit easier. When this occurs you won’t hear the team talk about “QA people” it’ll just be “the Team.”