Software development can be painful. We’ve experienced the pain. In this series, we are writing about the four most common types of software pain we’ve experienced or seen other people experience and how we try to fix them.
Here are the previous posts in this series:
- Part 1: The Bonfire (Expense)
- Part 2: The Crawl (Missing Deadlines)
- Part 3: The Black Hole (Lack of Communication)
In this post I want to introduce one final cause of software project pain that might not be apparent:
Part 4: The Tangle
The "tangle" is what we call the technical debt that builds and builds around a project until it seems like it takes forever to do anything. This is always a surprise to people new to software.
When you first start a software project, things might seem like they are flying. But when you are six months in, everything seems to take three to four times as long. What used to take an afternoon, now seems to take almost a whole week. This is due to something called "technical debt."
Technical debt: the tendency for software to become more and more complicated as it grows, this makes bugs harder to fix and slows progress.
This can't be avoided. I like to liken software development to standing up dominos along the edge of a table. After you've been doing it for an hour, it's possible that a new domino causes another it touches to fall. In other words, you have to be careful that new stuff isn't breaking the old stuff you've already done.
Every project will run into technical debt if you work on it long enough. There is no escaping it entirely, but they're some things you can do to minimize it.
Here is our strategy for dealing with technical debt before it starts:
We try to dedicate 15% of our development time to writing automated tests and aim for 100% test coverage of all backend code. What this means is, every time we add a new feature, we can run a script that makes sure that all the old features are still working, without the need of manually testing everything. On our team, a task isn't done and ready to be billed unless we have an automated test written for it.
On top of automated tests, we have code reviews built into our process. Each of our development teams has a senior developer who is responsible for checking every line of code that gets pushed to production and making sure that it meets standards for quality, documentation, and repeatability.
Human QA Tests
We also employ a Quality Assurance Analyst on each team who maintains a checklist of tasks and checks everything before any new code is pushed to production. These people are extremely visual and often catch visual bugs and inconsistancies that an algorythm or code review might miss.
Finally, we try to cut down on "the tangle" by using opinionated frameworks whenever possible. What this means is that for most development tasks there is a single right way to do things. Having these agreed on best practices makes it much easier for a developer in the future to figure out what is going on and make future changes to the code.
Nobody can completely eliminate "the tangle." It's an unfortunate part of the process. But by adopting agreed upon frameworks and doing regular testing and code reviews, we believe it makes technical debt more of a manageable problem.