Why do programmers hate writing unit tests? Why do they hate even more writing unit tests before coding? You don’t have to answer. I’ve already heard the excuses. These are rhetorical questions. I have a theory, however, what the real reasons are.
Thirty Days to Better Software
Reflective Improvement is number 2 of Alistair Cockburns 7 properties of successful teams. Of these 7, Alistair says the top 3 are core properties for success. Reflective Improvement is so important, because it gives such a big bang for the buck.
Best Job in America: Software Engineer
According to MONEY Magazine and Salary.com, the best thing to be in America is a software engineer. What’s so great about being a software engineer?
- It’s the second-fastest growing job title.
- It’s a highly creative position.
- It involves cool, cutting-edge technology.
- It pays decently.
- There are plenty of places to go once you’re experienced.
-TimK
Manual Test-First
Working on a team that’s not yet onto the value of unit testing, I frequently encounter what Michael Feathers calls “legacy code.” It is not unit-tested and can’t be. That doesn’t mean I need to forget test-first.
Posted in Uncategorized
Tagged legacy code, Michael Feathers, QA, test-first, testing
Leave a comment
James Shore on Good Design
Quality is one of those ineffable abstractions. Ask ten people, “What is good design?” Get twenty answers. But Jim Shore’s answer is actually worth something.
A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.
This definition has some pretty obvious, radical, and cool implications. Quality depends on what changes you’re making to the software and who is making them. How much time you’ll have to spend maintaining the code is more important than how much time you spend coding it in the first place. And all of this means you can’t plan ahead for design quality!
This may be a surprising conclusion, but it’s absolutely correct. I also agree 100% with Jim Shore on his universal design truths and on asking “Why?” and understanding context.
One more note: Good designs can degrade with age. Great designs take quality to the next level and actually improve over time. “Impossible!” you say? Well, it’s not impossible. I’ve actually seen it happen. But that’s another story.
-TimK
Break Your (Software) Process Addiction
How many times have you heard someone say—or maybe you’ve even said it yourself— “Yeah, it’s a hack. But we don’t have time to do it right.” Frankly, this one goes in the same category as popular rubbish like:
The Intuitiveness of Time-boxed Iterations
It started as a math project for my fourth-grade daughter and turned into a lesson in project management. I flipped a coin 10 times, counted 3 times that it came up heads, and recorded this on a bar chart: the bar labeled “3” on the axis labeled “Number of Heads,” one trial. We repeated the experiment, recording more trials to the chart. Eventually, we colored a familiar bell curve, big in the middle and tapering off to the sides. Each trial, we expected to see 5 heads, and on average, that’s what we got. Sometimes, we got more or fewer, and once we even got none, but mostly we got about 5.
