quality

You can’t hire away your quality issues

4 Comments

I work with a lot of companies that have more work than they can handle.  Actually, almost every company is in this boat.  But some companies handle this scenario very poorly.  When there is too much work to do, they work harder to get it all done.  As a result, they are often desperate to hire new people to take on the work load.  In the mean time, it seems that quality suffers everywhere as a result.  People are assigned more work than they can handle and that becomes an excuse for why everything’s broken.  Eventually you might get into a situation where it seems like you’re spending more time fixing problems than working on new features.

Hiring more people is not going to fix the problem because the problem is the company culture.  If your team sacrifices quality when they are asked to do more than they can handle, then your culture is telling them that quality isn’t important.  You’ve already lost.  If you hire more people, the only thing it will change is that you have more people in the exact same situation.

Continue reading →

To those that advocate manual tests instead of automated tests

3 Comments

There are people out there who are not the biggest fans of automated tests.  They think they cause more trouble than they are worth.  I can definitely sympathize with that perspective. In fact, I will readily admit it can be completely true.  A bad automated test can be worse than no test.  But, I’ve worked on projects that had a lot of good automated tests and I think they were better off for them.

There are people out there who think writing all these automated tests is usually more trouble than it’s worth.  The alternative to automated tests is to “run your software frequently in a live scenario to test the features as they’re being deployed“.  But, I have some questions for the people that feel this way:

Continue reading →

Prevent your production issues from ever happening again

Leave a comment

This is a scenario that’s all too common: The product gets released and then a serious problem is discovered.  You think, “That couldn’t have been caused by me”, but then you realize that it was.  After you’re done beating yourself up about the mistake you should ask yourself this question next:  How can I prevent this problem from ever occurring again?

If your answer is, “be more diligent in the future” or “don’t do that”, bzzz, wrong answer.  That’s not good enough.  It allows other employees to make the same mistake in the future.  If your answer is, “update the documentation to say ‘don’t do this'”, bzzz, wrong answer.  If this mistake can take down an environment, it’s too risky to assume someone will read the documentation to avoid this in the future.  Don’t give someone the opportunity to miss this information.

Continue reading →

How to mock out a deeply nested class in Spring without going insane

Leave a comment

Lets say you have a bunch of classes that call each other like this:

Here, Root  calls Middle  which calls End  which calls Database .  If you would like to test from Root , and want to mock out the Database how can you do that in Spring?   Spring doesn’t make this easy. But I have figured out how to do this in a way that I consider satisfactory.

Continue reading →

You should not be afraid to change code

Leave a comment

If you ever work on code and are afraid to change a part of it because it might break, you’ve got a serious problem on your hands.  If you are afraid to change code, that means you’re afraid to improve code.  That means you can’t make it better and you can’t add features to it.  Living in fear is no way to live.

If someone ever says, “don’t touch it” in regards to code, that means someone screwed up a long time ago and now everyone at the company has to pay the price.  The code is holding your productivity hostage.  There are so many ways you’d like to improve the code in your project, but your changes keep on getting tangled up with this knot of instability.

This is not the natural order of things.  Just because a project lives long enough doesn’t mean that there has to be fragile pieces of code that break if you look at it wrong.  It’s just that so much technical debt has added up around the code that someone should have dealt with it a long time ago.  Now, nobody wants to deal with it.  If you or your company is afraid to change a piece of code, “you’re doing it wrong”.  Here’s how you can fix this problem:

Continue reading →