Trying to meet deadlines on a software project is extremely challenging. Estimating software is inherently difficult because writing code is not like working on an assembly line. It’s more like writing a book. You can rush writing a book, but you pay the cost of continuity issues, poor grammar, half baked plots, and undeveloped characters. In software all of those thing manifest in the form of bugs or a product that just doesn’t work.
Much like a writer agonizes over the wording of certain sentences, developers will agonize over certain bits of code. Some of it can be subjective, such as trying to have clean code, but there is no subjectivity in whether code works or not. It just has to work. Dealing with these small issues to get code to work often takes the majority of development time. Managing these small issues will have a huge impact to getting projects on track.
These small issues are often neglected though. The reason is there are lots of them. Dozens. Hundreds. Often times they are specific to a company, or a single project within that company. Big things are much more obvious.
“Code reviews will solve our problems!”
“Test driven development will solve our problems!”
“Continuous deployment will solve our problems!”
“Upfront software design meetings will solve our problems!”
These are all good things to have, but none of these things are silver bullets. They get talked about a lot because they seem big and impactful. I’m not going to say they aren’t, but the point of these big process tools are to alleviate the pain from the numerous small issues that crop up in software development.
The best way I can describe what it’s like to debug software is to think of it like playing a game of “Where’s Waldo” Except there are tons of different issues you may hit. One day you may be playing a game of “Where’s Waldo” in the circus. The next day it may be at the museum. The next day you may not be looking for Waldo at all. You will be looking for Bob the bear:
It’s easy to find bob the bear if the image only has a single bear and he’s front and center. It gets harder in an image with dozens of tiny bears:
That’s what debugging is like. You never know when you’re going to need to find Bob the bear, but that time will come. When it comes, you will also not know whether it will be an easier game or a harder game than you were expecting.
Developers are constantly dealing with these kinds of issues. Each one may not seem like much. 15 minutes here. 30 minutes there. Add up a handful though and suddenly a half day of development has been spent on these issues. Add up a handful of these, multiple them by 3-5 developers, then multiply that by 10 days for a 2 week sprint and suddenly the project is completely off track. These are the many minor cuts that kill software projects.
They usually don’t get talked about for a number of reasons. These are small issues after all. Why have an entire team talk about something that slowed one person down by 15 minutes? If time was spent talking about each and every issue every team member encountered, the meeting to discuss them would last days. It’s much more efficient to just talk about big things like performing code reviews.
The problem with this mentality is that if the small things are ignored, then a team may never really understand the underlying issues they are encountering. While many of the big things are great to have anyway, blindly implementing them because they are A Good Idea will not fix the problems a team is encountering. Also, not every small thing needs to be discussed. A sample of a few can probably be enough to reveal these underlying issues.
Talking about the small stuff has some dangers though. The biggest is that if they’re small, then they are usually associated with a single person. If the discussion is not structured correctly, a person can feel like they’re being blamed for something and get defensive. No constructive discussion can occur if this happens. There’s no easy answer to how the discussion can be structured well either since each person is different and each team has its own unique history.
The rewards of a public discussion with the whole team are worthwhile despite the dangers. People may find that the issues they encounter are not just them. Other people may have either the same issue or related issues. In this case, the actual problems the team faces are clearer and if the solution is in fact some big process change, then at least the team will know which big process change needs to happen.
If a problem is localized to a single person, one could argue that it would be better resolved in a one on one. But another team member may have better experience to resolve that problem than the manager or team lead. There’s also the fact that it is going to be impossible to tell how many people suffer from the same problem until one person takes the risk of speaking up.
This isn’t an easy path. All of a team’s problems aren’t going to be fixed after a single retrospective. Yet progress can be made. It will take time, but it is better to address real problems with tailored solutions than it is to hope some best practice will save the day. Slow progress is still progress and better than no progress at all.
This post was originally published on blog.professorbeekums.com
Top comments (1)
It's a game of balancing priorities, as so often is the case in programming. Little issues tend only to become important when they're messing with a new feature, or causing a customer grief.
But it's also a bit of a mindspace issue. Usually when I tackle small coding issues I try to group them together. If I have several in one module I can get into that code, fix many things, and be more productive than if I jump around randomly. If there's no obvious grouping of issues you might just avoid doing them.