Month: January 2016

Martin Biron was the last player in the National Hockey League to wear #00. It’s one of my favorite stories because it mixes hockey with the pitfalls of software development.

Biron, then a rookie goalie for the Buffalo Sabres, appeared in three games in the 1995-96 season wearing #00, which he had worn during his junior career as well. He wasn’t the first to wear it – John Davidson had donned #00 for the New York Rangers in the 1970s and Ed Belfour wore it in an All-Star Game in the early 1990s – but by the time Biron made it back into the Buffalo lineup during the 1998-99 season he’d lost the number forever, switching to #43.

Between Biron’s final appearance in #00 and his first in #43, the NHL rolled out a new stat-tracking software package. If I recall correctly, it was developed by IBM (though I’ve heard Compuware mentioned as well, I could be mis-remembering) to much fanfare. Unfortunately there was a bug that only applied to Martin Biron: It assumed jersey numbers were non-zero.

When I wrote the software behind the short-lived Hockey Sweater Numbers web site I specifically made sure to handle this. IBM – ridiculously, to me – did not, and rather than fix it the league just banned the numbers that the system didn’t account for.

Why is this story on my mind right now? Because of John Scott and my own web site.

There used to be a listing of all of the winners of NHL awards on DetroitHockey.Net. I just pulled it off the site because that data is all over the Internet, I don’t need to worry about it on DH.N. But I still maintain the database for my own personal uses.

John Scott is a journeyman enforcer. He started this season with the Arizona Coyotes, out of the lineup more often than he was in it. When the NHL launched their web-based All-Star voting campaign, though, Scott quickly rocketed to the top of the voting. When the dust settled, he had been elected as the captain of the Pacific Division team.

Almost immediately he was traded to the Montreal Canadiens of the Atlantic Division, then demoted to their American Hockey League affiliate. The league never wanted him in the All-Star game and it appeared that their problem was solved. In the end, with the support of many players but seemingly few front offices, Scott was allowed to play in the All-Star Game. He would captain the Pacific Division but would represent neither the Coyotes nor the Canadiens. His petition to represent the St. John IceCaps, his AHL team, was denied. He was a man without a team.

Like something out of a movie, the journeyman now-minor-leaguer with five career goals scored twice and was named MVP of the event.

Within minutes of the announcement, I found myself staring at the administration system for the NHL awards on DH.N, entering Scott as the winner of the All-Star MVP award, and stumped because my system requires a player to represent a team and Scott doesn’t have one.

The story I’ve laughed at so much has come around to bite me in the ass a bit. Software not written to handle the strange things hockey throws at it.

Unlike the NHL, I’m adapting my software. I’m hacking in the St. John IceCaps as Scott’s team.

I love agile development methodologies. Specifically the ability to fail fast and adapt as necessary.

I love cloud services for making failure cheaper and therefore easier. We can try new things because the risks are lessened.

We have the process for failure figured out. We have the technology for failure figured out. I think we’ve still got to figure out the emotional impact of failure.

We don’t like to talk about touchy-feely things in engineering, but the fact of the matter is that failing fast, failing in ways that we’ve built business cases around, failing inexpensively… is still failing. And it doesn’t feel good to fail.

The team I’m working on had what we thought would be been a rubber-stamp demo scheduled for last Thursday. We were a few weekly sprints into the project. We’d demoed it previously and made some changes based on that demo. We were working the way we were supposed to.

The demo revealed that a handful of requirements hadn’t been communicated. Somehow this was missed earlier. Much of our work was invalidated.

We failed. We failed quickly. We failed in such a way that we could iterate on our work and save the project. We did what we were supposed to do.

But in our next retrospective, we couldn’t get over how much it stung to do it. We recognized that the process was meant to catch these things, that we hadn’t done anything wrong inside that framework, but couldn’t shake the feeling that how things went down just sucked.

I don’t know how to get over that. It feels like failure because it is failure. If we expect it at a process level, maybe we need a way to account for it on an emotional level, too.