doggie calculus

Richard Jones was CTO for a large retail company that relied heavily on e-commerce for most of its turnover. Aged 45, he’d been a software developer once and had risen through the ranks before reaching his current position. The responsibility of his position lay heavy on him but he took pride in the ability of his team and worried deeply when they weren’t performing.

This was one of those days. Development speed had slowed to a crawl and the defect rate was through the roof. Every time they fixed one defect, they created at least two more. He’d talked to the team and he knew they were doing everything they could but it just wasn’t working.

Richard knew they weren’t going to make their delivery date but he also knew he couldn’t talk to the board without a plan of action. A year or so ago, he’d engaged a coach to help the team improve their processes, which had a tremendous effect on the team’s performance and predictability. Was it time to and get the coach back?

Fast-forward a couple of weeks and the pair of them were enjoying a coffee outside the local Starbucks. Colin, the coach, had just told Richard the results of the static analysis he’d done on the team’s code.

“But my developers are brilliant, there isn’t anything they don’t know about Java, Web Services, AJAX… you name it, you won’t find anyone that knows more about it than this team” said Richard emphatically. “Everybody praises them for their solutions, we’ve won awards for the website and the customers absolutely love it.” He took a sip from his cup, “How can you sit there and tell me our system is poorly designed.”

“Ok,” said Colin looking him straight in the eye, “Let me tell you about my dog, Russell. Russell is good at catching balls. He always seems to be able to predict where the ball will land and get there first so he can catch it.”

“What’s that got to do with my team?” asked Richard.

Colin continued, “Does this mean Russell uses calculus to predict where the ball will land? I don’t think so. I think he gets feedback from his surroundings and adjust his position relative to the ball. When it’s close enough, he grabs it with his mouth. He doesn’t understand the underlying principles of ballistics at all.”

“I still don’t get it,” said Richard, looking puzzled.

“In a sense, your team is like my dog. They have excellent technical skills and they have excellent external design skills. They use those skills to deliver good-looking solutions and you reward them for it.” He leaned forward to make his next point, “However, the static analysis of the code tells us they have less understanding of the underlying principles of object-oriented design.”

Leaning back in his chair he continued, “The internal design of the code is poor and you’ve built up what we call a technical debt. This is what’s making it so difficult for them to deliver software. Your system is fragile – every time you try to make a change, you break something.”

“I see what you’re saying and I guess the analysis can’t lie, so how do we fix this?” Richard asked.

“We can train and coach your team, in design principles” replied Colin. “We can also teach them how to identify what we call smells in code and refactor them to improve the designs.”

“So some training for the team and everything will be fixed. I imagine we’ll need to spend some time reducing the technical debt, too?” said Richard, looking round for the waiter so he could pay the bill.

“The training is just the start,” said Colin as they walked back to the office. “You also need to start paying attention to internal design. Previously, you put emphasis on the external design and as a result, your team is good at it. Pay the same attention to the internal design and your team will become good at that too. Making static analysis part of the check-in process and doing team code-reviews are simple ways you can start to make the internal design more visible.”

They’re still working on it but Richard’s team are in a much better place now. The training gave them a new awareness of good design principles and prompted discussion amongst them. Implementing static analysis on check-in has forced them to pay continuous attention to the internal design of their systems.

Tags: craftsmanship, organisational culture, software design, Stories
Date: Sunday, October 13, 2013