The “there are more important things to do” fallacy

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:

Continue reading

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

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:

Continue reading