If there’s one constant in software development, it is change. Our entire workday is spent changing things and responding to change.
Every time you write a line of code, you are changing it. You might add new features, fix bugs, or make changes to existing code. However you put it, you’ll be changing the code.
Requirements will change. You often find this out after you’ve coded a feature, and now the business either changes their mind or you find out that you made some wrong assumptions.
Business priorities will change. What was important yesterday may not be important today, and six months from now, all kinds of things might change. There could be new, more important projects on the horizon, new people in charge, or new business opportunities.
Software development teams change too. You might stay at your company for many years, but during that time, you might get moved from project to project. Developers will leave the company, and others will join. The end result is that many different people will end up working on the code that you’re writing today.
Since we know that we are going to have a lot of change, it would therefore make sense to reduce the cost of change so that we can respond to change as quickly and easily as possible. So how can we reduce the cost of change?
Every time I add a line of code, I risk breaking my application. Breaking the application is just not acceptable. We’ve come to accept bugs as a part of the process, but that doesn’t mean that it’s OK to write bugs. If you’re not striving to write bug-free code, then maybe you need to raise your standards.
Nevertheless, the fact is that we all screw up and we all have the capability to create bugs. Knowing that, I want a way that I can easily test my application so that I can ensure that I find out if I broke something once I change it.
On my current project, I’m writing an application that helps my client bid on construction projects. They can’t afford to have bugs in their system that will cause them to incorrectly bid on these jobs or they could be out a lot of money. The bottom line is that it has to work because their entire business is now running on the application that I’m writing. They also come to me on a regular basis with new feature requests and things they need changed. They don’t want to wait months to get this functionality, and they also don’t want me to break any existing code.
Thankfully I have a large suite of automated tests that I can run to ensure that I didn’t break anything. This isn’t foolproof and things sneak through, but it’s usually little stuff that isn’t critical. But it’s good enough proof for me that I didn’t break the existing functionality. As a result, I can release to production daily and I spend virtually no time manually regression testing my application when I deploy. My unit test suite has reduced my cost of change to pretty much just the time it takes me to code the changes, so now I can react quickly to changes, release all the time, and I can do it without breaking existing code.
Sometimes people will write their unit tests, write the code to make the tests pass, and then assume that that is good enough. That’s great that you wrote tests, but how easy is it for someone to make a change in your code?
I feel that clean, readable code is very underrated these days. When you write code, are you thinking of the person that is going to need to understand what you did once you’re not around anymore? That scenario is very likely to play out at some point. So when you write code, create methods, variables, and classes that are very descriptive. Place a priority in making your code easy for someone else to read.
“Clever code” is the opposite of clean code. I’m talking about using complex algorithms to solve simple problems, trying to using a complicated LINQ statement to do an operation that would be more readable in a foreach loop, or trying to implement something in the fewest lines of code as possible. There are times where you might want to do things like this, but usually it’s more important to write code that is easier for someone else to read and understand. Again, remember that someday someone else is going to have to change your code, so write descriptive code that makes it easier for that other someone to know what to do.
Your unit tests are documentation of what your code is supposed to do. I practice behavior driven development, which means that my unit test methods describe some business functionality that my code is in charge of executing. This way, if someone needs to know what my code does, they can look at the test classes and methods and see what it is supposed to do.
Lately I’ve started adding a lot more comments in my test methods. The class names and methods names may describe what the code is supposed to do, but it doesn’t always explain why. I’ve found that sometimes it helps to write down the why because that is also important information. Since people can look at my tests as documentation of what my code does, I figured that this would be the best place to put the whys, because if someone has to change my tests, they’ll immediately know why I did what I did and they’ll have a reminder that they need to update my comment.
Since business priorities and requirements are going to change, we want to reduce the cost of this change too. If the business comes to you and drastically changes the requirements or certain assumptions that you might’ve made, it might be really costly and painful to change, and you can only do so much about that. What we can do is make sure that we’re constantly checking back with the business to see what they want now so that we have as few surprises and as little rework as possible.
This is one reason why Agile projects often run on iterations. As a part of this process, meet with your business sponsor every week or two and talk about what you’re going to do next. Show them what you’ve done in the last week or two, and make sure you’re on the right track. This way, if they’re going to change their minds, you’re giving them permission to do so and you can adjust what you’re doing as soon as possible so that you have the least amount of rework.
Quit thinking short-term and quit shoving code in just to get it done as fast as you can. You may think you’ve done something good by getting it done faster, but if you create more work and pain in the future, it’s a net loss. Instead, always think about what the effects of what you are doing now will be two years from now. Your goal is to create business value without creating technical debt. A home builder can do shoddy construction and put nice looking paint and siding on the house, but 10 years from now when the problems arise, people won’t be thinking very highly of that builder. Don’t make the same mistake. Take pride in your work and strive to always leave your code base cleaner than you found it.
Here are the slides from my Productivity Boosters talk. Some other links you might be interested in:
Create a plan of how you are going to be a productive and effective developer!
I’m doing a quick little “grok talk” at the CONDG meeting this Thursday, July 22. I’ll be talking about some simple productivity tips that have helped me to get things done faster and become more productive and effective. While this does not sound very exciting and sexy as hearing Tim Wingfield talk about IronRuby, finding ways to become faster and more productive is something that we all could use.
And if I end up boring you to death (which I don’t plan on doing), you can stay and listen to Tim talk about IronRuby.
When you go to work and write code, you have one main tool that you use - your dev machine. The power of your machine will partially determine how fast you can get things done.
How often does your company buy you a new machine? Every 2 years? Every 3 years?
I don’t know many companies where developers get new machines every 2 years or less. I’m here to show you why waiting longer than this makes no sense.
It makes no sense because hardware is cheap, but developers are expensive. I’m currently on a project where I’m working on dev machines that were purchased in early 2008. I’ve worked on other projects with machines that were 6 months old that were considerably faster.
On my project, it takes about 45 seconds to compile the solution. But what if I could reduce that to 40 seconds per compile by buying a brand new top-of-the-line machine?
Let’s say that I compile every 5 minutes. So in an 8 hour day, I compile 96 times. Each day, I will save 480 seconds, or 8 minutes. If I work 1900 hours in a year (which equates to about 11 months of work days since most people have about one month of work days in PTO), I will save 1900 minutes, or 31.6 hours.
Let’s say that the average developer on your team makes $75,000 a year. If that were the case and you worked 1900 hours, you are making $39.47/hr. This means that if you save 31.6 hours of this developer’s time, you are essentially saving $1250 over the course of the year.
For $1250, I can buy a pretty good dev machine, especially if I don’t buy monitors to go with it and use existing monitors. I think I used pretty conservative numbers here too:
Even with my conservative estimates, I would say it is definitely worth it to buy new machines at least every 2 years. You might even be able to argue that you should buy machines every year. You would have to do the math and see if it’s worth it.
Convincing IT managers to go for this is difficult for some reason, even when you show them the numbers. So many IT managers will tell you that spending is frozen, or that they don’t have money in the budget for hardware, or that it’s not fair to buy the dev team new machines but not buy <insert team that doesn’t really need it> new machines. Are you serious? You would rather have your developers, who are expensive relative to the cost of hardware, have to sit and wait longer for the solution to compile? This is short-sighted thinking. You’re pretty much guaranteed some level of return on that investment within a year.
If you’re going to hold your developers to a high standard, empower them to meet these expectations and make sure that you’re giving them the best tools available.
I had a simple problem today. I had to turn this:
When withdrawing money from an account
- should withdraw the specified amount from the account
- should specify that the withdrawal was successful
… into this:
[TestFixture]
public class When_depositing_money_into_an_account : Specification
{
[Test]
public void should_add_the_specified_amount_into_the_account()
{
}
}
[TestFixture]
public class When_withdrawing_money_from_an_account : Specification
{
[Test]
public void should_withdraw_the_specified_amount_from_the_account()
{
}
[Test]
public void should_specify_that_the_withdrawal_was_successful()
{
}
}
I really didn’t want to do all of this typing every time, so I wrote code to do it for me. It works like this:
1) Copy the acceptance criteria text onto the clipboard
2) Run Specs2Tests.exe (will put the code onto the clipboard for you)
3) Paste the code into your code file
Now I can get all of my acceptance criteria nailed down in a text file where I don’t have the ceremony of a programming language, then let something convert them into tests. Since I just cranked this out today, I’m guessing that it doesn’t handle every scenario that you might think of, and it only writes out C# code. There is no reason that it couldn’t spit out VB.NET, RSpec, or anything else. If it doesn’t do what you want, get on github, create a fork, and send me a patch!
The code is here: http://github.com/jonkruger/specs2tests. Have fun.
During the last week I was able to go to two software development conferences, the Ann Arbor Day of .NET and Stir Trek. I love these events because I get to see a lot of people that I don’t get to see on a regular basis.
On the other hand, I don’t feel like I get much out of the sessions anymore. It’s not that the sessions are bad, but I feel like I’ve heard a 100/200 level talk on pretty much everything I want to hear about. At each of these conferences there have been some talks that I have really enjoyed, but a lot that I don’t have a real interest in hearing again.
Granted, I’ve been to more of these events than a lot of people. I remember the first time I went to events like this and they were awesome. I was learning a ton of stuff and it was new and exciting.
I miss that feeling. I certainly don’t know it all. I know there is a lot that I could learn. But I guess I’m ready for a new kind of conference. Some ideas floating around in my head:
I know there are conferences like this. I know I’m not the only person who thinks this because I’ve talked to other people feeling the same way. I’ve heard of some of these conferences, but they’ve been other places other than Central Ohio. For example, look at the session list for the most recent ALT.NET Seattle event and notice the difference between this event and the various Day of .NET events. Granted, the target audience is different. But I’m a part of that target audience. I don’t always have the time and money to travel to these events.
I think part of the problem is the wide breadth of technologies in the .NET space. In the last year Microsoft has released Silverlight 4, Windows Mobile 7, .NET 4, ASP.NET MVC 2, OData, and probably other stuff that I can’t remember off the top of my head. So it’s really easy to come up with an “Intro to <insert new MS tech here>” because there are so many choices. Often times these are compelling topics, don’t get me wrong. But every day I go to work and I’m working on plain old web apps or Winforms apps or WPF apps like the rest of you. I want someone to come talk about how I can do better at what I’m doing every day. Show me how to better implement design patterns, or how to test my code better, or how you structure your MVC app to take advantage of jQuery validation, or how to use some ORM, etc. Those things will help me do a better job on the projects that I’m working on today. Sure, I’m curious about Windows Mobile 7 and Silverlight and OData, but my first priority is to get better at the stuff I’m using at work right now.
I feel like I’m getting a lot of talks that might pique my curiosity about new technology, but not a whole lot about how I can improve at the stuff I already know. I’m talking about talks like Nate Kohari’s talk at MIX about how he built Agile Zen with ASP.NET MVC and jQuery. When I watched this talk, I got some ideas on how to do some things, but I also realized that Nate is doing some crazy stuff with jQuery and JavaScript that I would’ve never thought of. It showed me some things that I need to go learn that could really help me on my current ASP.NET MVC project.
Please don’t think I’m criticizing conferences like Stir Trek or the Ann Arbor Day of .NET, because they’re good events put on by volunteers who spend their own time to put it on without any compensation, and I’m really thankful that people spend their time so that we can have community events like this.
I guess I’m just looking how I can take my daily work to the next level.
Sign up for TDD Boot Camp at the discounted rate of $750! Also, if you sign up with a group of 3 or more, you get the even more discounted rate of $600.
The bottom line is that I want to help you learn TDD and get all the benefits out of it that I get on a daily basis.
If you read my blog at all, you know that I’m passionate about test-driven development. A few months ago, I announced that I was developing a TDD training course called TDD Boot Camp that will teach you everything that you need to know to do test-driven development on real world .NET projects.
I currently have two upcoming events scheduled: July 13-15 in Columbus and August 18-20 in Detroit. You can find out more details on what we’ll cover and how to register at the TDD Boot Camp website. If you can’t make any the events or if you would like me to come to your company, send me an email and we can work something out where I can come to you.
If the whole idea of test-driven development is new to you, or you’re not sure why you should care, come to the Path to Agility conference in Columbus on May 27, where I’m doing a talk on Test-Driven Development In Action. I’ll show you how TDD works and how it can help you deliver IT projects with higher quality, lower maintenance costs, and more peace of mind. Actually, you should go to the conference either way, because there is an excellent lineup of sessions for anyone involved in IT.
When we work on software development projects, we break the project up into features. But what do you do when that feature is assigned to you?
Something that has helped me is to break the feature up into as many small tasks as possible. This helps me deliver working software incrementally and do it in an orderly fashion.
Let me put this another way. Let’s say that you want to make a meal for dinner, and you have to go to the grocery store to buy the ingredients. You could just go the store and try to remember what you need to buy. I’ve done this before. I need to get 5 things, and I’m constantly repeating over and over in my head what I need to buy. It’s mentally tiring! Instead, I’ve learned to make a list of things that I need to buy, and I bring a pen along so that I can cross things off after I’ve put them in my cart.
The same idea applies to software development, and there are many benefits.
Before I start working on a feature, I stop and think about everything I’m going to do to complete the feature. I try and break this down into the smallest unit of work that produces some working functionality. So I’m not writing down things like “Put Save button on screen”, I’m doing stuff like “Save a new order”. Now that I have this list, I can work through it in an orderly fashion, and after several days when I’m starting to get tired of the feature, I don’t run the risk of not thinking of everything I need to do to complete the feature just because my brain is tired, bored, or frustrated.
If you add two lines of code and something breaks, I think you know where to look! If you spend a day writing code and then realize that something is broken, it’s a lot harder to figure out what you did to break something.
In my grocery store example, trying to remember my list while shopping was difficult because mentally I was trying to do several things at once. If you are working on a single task like “save a new order”, you’re not thinking about loading orders or saving existing orders, you only have to think about one task. Mentally, this is much easier to do (and less stressful).
It’s fairly easy to get a rough estimate of how far along you are on a feature by looking at your list of tasks and seeing how many you have completed.
It feels good to cross things off on a list. At the end of the day, you can look back and see everything that you got accomplished. You may have not completed the entire feature, but you can have the good feeling that comes with crossing things off. I’ve seen people get quite flustered after several days on the same feature because they don’t feel like they’ve accomplished anything.
You can use an online tool, a text file, pen and paper, or whatever else you like to keep track of tasks. I use Agile Zen to keep track of my tasks on a feature (Agile Zen can also keep track of your features in an online Kanban board). I used to use pen and paper, but my desk started getting cluttered with papers. Do whatever works best for you.
It also helps to have a source control system that helps you out. I like doing branch-per-feature, where you create a branch in your source control system for each feature that you work on, and then you merge that branch back into the main development branch once you complete the feature. In this case, you’re the only one working on your branch, so checking in is easier because you don’t have to do the usual check in dance. Now you can check in as often as you like with very little effort, and if you set up your CI server with a build that points to your branch, it will run the tests for you every time. This way, if you go down the wrong path with your feature or realize that you broke something at some point, you will have lots of checkpoints to roll back to.
In order to do branch-per-feature, you will need a source control system that makes branching easy. The one that I recommend (which I use) is Git. If you’ve heard about Git and haven’t learned how to use it yet, go watch this video. Mercurial is another one that is similar to Git. I’ve done branch-per-feature with Subversion, but every time you create a branch or check in, it has to make calls to the server, which means that it’s slower. Git and Mercurial do everything locally on your machine (so it’s fast), and then you push your commits and branches up to the server when you decide to.
If you’re stuck using a source control system that doesn’t make branch-per-feature easy, you can use Git locally for feature branches and then just check into your team’s source control when you complete a feature. I’m doing this on my current project and it’s not that hard to set up.
Regardless of how you do it, I think breaking features up into small tasks will reduce your stress level and make it easier to develop working software incrementally. Give it a try and see what you think!
I wanted to come up with a way to show people how to use Rhino Mocks (other than telling them to read the documentation). What better way to do this than by showing you how it works through a bunch of simple unit tests that document how Rhino Mocks works?
So that’s what I did. You can view the code here, or if you want to download the whole project and run the tests, you can get the whole thing here.
(If you’re interested in Moq, how it compares to Rhino Mocks, and to see Moq documented through tests, check out Steve Horn’s post.)
UPDATE: Fixed the test that was incorrectly showing how to use Expect() and VerifyAllExpectations(). Thanks to Sharon for pointing this out.
