Christian Peters

Red , Green , Refactor is the mantra for Test Driven Development.  When I started out with Unit Tests the idea of creating tests to make sure that a function behaved properly was easy to understand, but the rest of the cycle didn't really sink in until later. Red , making a failing test, is important to the TDD approach. When practicing TDD, if you start out by creating a test and it passes without the actual code having been written yet, then there is something wrong with your test. By making sure that your test fails first, then you can be sure that whatever changes you make to pass the test will have been valuable changes that were needed to make the function work properly. If you are writing a test against existing code and it passes immediately, then you do not need to make any changes to your code as your are already passing whatever that new test is validating for. Green , making the test pass, is the obvious part of Unit testing.  You want lots of green in your pr...

Developing code can be a little like trying to complete a Maze. You generally know where you want to get to and you may have an idea of where to start, but the in between is all unknown. As a kid I was told to always start the Maze from the beginning and not to cheat by starting from the end because that would spoil the fun of figuring out how to get to the finish. I feel like a lot of my development time up to this point has followed those same guidelines, start from the beginning. Most of the time I still end up getting to the end product just fine, but there are also a lot of times that I miss something, I end up with bugs or other issues in code. Starting from the end of the Maze may be cheating for a Maze, but it shouldn't be seen as cheating when developing code. In fact it should be encouraged and used exclusively. So how do you start from the end of your code? You use Test Driven Development. You begin by creating tests that will prove that your code ends with the result ...

When deciding on an upgrade, whether its a new piece of software, a new computer, or a new process to automate a task, the math is fairly simple to determine if the cost of the upgrade is worth it. To figure out if the price is justified you need to figure out the cost of the tool, the time saved by using that tool, and the cost of the labor gained or lost. For simplicities sake I will use examples with easy round numbers. Lets say that you have an employee that makes $100,000 per year. Now take that annual salary and divide it by (52 weeks per year, times 40 hours per week, times 60 minutes per hour). You have $100,000 divided by 124,800 minutes worked per year, resulting in $0.80 paid to that worker per minute. Meaning that if the upgrade cost you less per minute saved than that worker is being paid per minute, you should make the purchase immediately and begin saving money. Lets take a look at some upgrade prices to see how much they cost based on how much work they save. ...