Occasionally when people are discussing the merits of software quality, someone will chime in and say something along the lines of “if it isn’t billable, there are more important things to do”. In this article I’m going to break down why this argument is a fallacy. It’s my belief that improving the software quality is just as important as billable hours and new features. I’m going to tell you why:
quality
Where does the name “Sleep Easy Software” come from?
A lot of the time I get asked where the name “Sleep Easy Software” comes from. When people have met me for the first time and I mention the name, they think I write software to help people sleep better. In a sense that is true, but not in the way they think.
Developers should not have to interact with human beings to set up a new environment
It’s typical for a developer to have to wait on some person to be able to get a new environment set up. For example, when the new project has its first acceptance test, a new server will probably be needed to run that test on. At your typical company, this developer will depend on another team to set up that server. Usually, that team is very busy working on more pressing matters (e.g., a production server seems to be low on RAM), so the developer’s needs are relatively low priority.
This type of situation should not even exist. Developers should not have to interact with human beings to set up a new environment. Continue reading
Sometimes turnover can improve quality
Turnover is usually a bad thing. It can be a sign that you don’t pay enough or employees aren’t enjoying their work. You’ll spend days and months finding a person to replace them. But there is a silver lining to turnover: It can be an opportunity to improve quality.
If you’re having trouble testing legacy code, mock a logger
I was working on some legacy code (“legacy” meaning it has no automated test coverage) and I really wanted to write some automated acceptance tests for it. The problem is, I could not think of a way to do that without refactoring the code first. I did not want to do this because “it was already working” and the refactoring could have introduced new bugs. I had a chicken and egg problem: I didn’t want to modify code until I had automated tests but I had to modify code to write the automated tests. Which comes first?
I ended up using a trick that minimally changes the production code, actually improves the production code base, and allows me to write automated tests. It’s these two simple steps: