Jon Kruger

Most businesses are creating software for one primary reason — to make money. In order to make money, we need software that meets the needs of the business and can be developed and maintained in a reasonable amount of time with a high level of quality. Test-driven development is a discipline that will help you achieve these goals.

Test-driven development involves writing automated unit tests to prove that code is working. The test code is written before the implementation code is written. By writing the tests first, you will know when the code is working once the tests pass. Test names are written as sentences in plain English so that the tests describe what the code is supposed to do. Over time, you will end up with a large suite of automated tests which you can run in a short amount of time. These tests will prove to you that your code is working and will continue to work as you modify or refactor the code base.

Most software applications are intended to be used for many years, and throughout most of their existence, someone will be changing them. The total cost of ownership of an application goes far beyond the cost of the initial effort to create the initial version of the software. The first release is the easy part — you can build the application from the ground up, you don’t have many hindrances, and developers feel very productive. But as time goes on, productivity tends to decrease due to complexity, developer turnover, poor software design, and any number of other reasons. This is where software development really becomes expensive. So much focus is placed on the original cost of building an application without considering how the original development effort will affect the cost of maintaining that application over several years.

Test-driven development can reduce the total cost of ownership of an application. New developers on the team will be able to change the code without fear of breaking something important. The application will have fewer defects (and far fewer major defects), reducing the need for manual QA testing. Your code will be self-documenting because the tests will describe the intended behavior of the code. All of this leads to flexible, maintainable software that can be changed in less time with higher quality.

Software is intended to deliver business value, and test-driven development will help you write higher quality, more maintainable software that can be changed at the fast pace of the business. Test-driven development will lead to successful software projects and enable you to write software that will withstand the test of time.

• Leave a comment... (6)

Three years ago, my three year plan was to go off on my own as an independent consultant. Well, it’s year 3 and the time has come to make it happen.

For the past four years, I have worked at Quick Solutions and I have loved it. I came into Quick Solutions never having done ASP.NET and ended up getting all kinds of experience in all kinds of different technologies. I never could’ve learned as much as I did and I certainly would not be in this spot today if it weren’t for all of the really smart people that I got to work with.

So what am I going to be doing now? I’m still going to be leading a .NET project for Quick Solutions. There will be plenty of blogging and I have some side business ideas to work on. You will most likely see plenty of me at various community events, lunches, code and coffee, and whatever else is going on.

I don’t know what the future will hold, but I always remember the line in Good Will Hunting where Robin Williams says that he’s going to put his money on the table and see what cards he’ll get. I’m really looking forward to it.

• Leave a comment... (0)

I was fortunate enough to have been given the opportunity to speak at CodeMash this past week. One thing I’ve noticed is that pretty much every time I speak (regardless of where it is), people will come up to me and offer feedback, advice, etc.

Personally, I really appreciate this. I’ve done my share of speaking over the years (both technical and non-technical), so I don’t think that I’m a bumbling idiot, but I certainly am aware that I have a lot of room for improvement. My biggest fear when giving a talk is that people won’t understand or I’ll say something wrong and no one will ever let me know what I’m doing wrong.

So I don’t care if you have been speaking for 20 years or if you have never given a talk in your life, I appreciate your feedback and especially your suggestions. If you come up to me and say, “That talk was terrible,” I might not be so happy! But if you come to me and tell me what I can do to improve, I’ll all ears.

• Leave a comment... (0)

If you’re going to CodeMash next week, I’ll be speaking at a couple of sessions. On Wednesday morning, I’ll be doing a PreCompiler session on object-oriented programming and the SOLID principles. I’m not big on 101 level talks, so this will be very little beginner material and mostly advanced OOP ninja stuff. I know this doesn’t sound very sexy, but learning advanced OOP and SOLID has drastically improved the code that I write, which is why I’m talking about it. We’ll do some hands-on coding too, so bring your laptop and get ready to learn from each other.

I’ll also be doing a short 30-minute session on how to convince others to do test-driven development. This is a touchy, difficult task that requires lots of tact, patience, and passion for TDD, but it can be done! I’m not sure what time I’ll be doing this, but check the schedule when you get there and you should find it (it will be in the vendor session timeslot).

• Leave a comment... (0)