Test features, not implementations

I used to try to test my code. I would fire up some JUnit classes and go to town, trying to think of what parts of my code were testable. Having read a bit online about unit tests I would try to do all the things I was reading about - test public method signatures, parameter validations, and even do some wiring tests making sure my code was calling my other code in the ways I expected.

However, at the end of the day, I just didn't see all that much value in writing these tests. They did help a bit, and often made writing the actual code easier if I was dedicated enough to test drive. But it came at a high cost - not only did I have to spend time writing the tests, I had to spend time maintaining them as well. Every time I changed code I had written before, I had a horde of broken tests to deal with.

I really wanted to figure out this whole testing thing, but it just wasn't making sense.

Enter Business Driven Development (BDD). It was like a veil was lifted and I could see what I had been missing before. You still wrote tests, and wrote them first so you were still test driving your code, but instead of testing all the little details of your code, you tested features! It made so much sense.

Now, what is a feature you might ask. I define a feature as anything your application is supposed to do. If you click a button and an overlay is supposed to open, that's a feature. If the overlay is supposed to display an image, that's a feature. If you click a close button and the overlay closes, that's a feature.

Let's assume you have a jQuery plugin named "overlay" that, when called, opens an overlay. Let's also assume you're using Jasmine for your JavaScript tests because it's awesome and BDD oriented.

Here's the wiring test for opening the overlay:

it('should call the overlay plugin', function() {
  spyOn($.fn, 'overlay');
  $('button').click();
  expect($.fn.overlay).toHaveBeenCalled();
});

Here's the feature test for opening the overlay:

it('should open an overlay', function() {
  $('button').click();
  expect('.overlay:visible').toExist();
});

They might not look all that different, but the difference is very significant.

If you wrote the wiring test, it would make sure that your plugin was indeed called. However, what if you wanted to refactor your code later? What if you needed to change the overlay plugin to only configure the overlay but not open it? Your wiring test would need to be rewritten. What if you had ten of these wiring tests? Hundreds? Any refactoring you do would cause a ton of test maintenance!

Now look at the feature driven test. What is it really testing? The user clicks a button, and and then an overlay should be visible. There's your exact requirement from your customer and there's the test that makes sure it works. Refactor your heart out, the test can stay the same because you're testing your feature, not your implementation.

This is a very simple example, but the concept only gets more important as the features get more complicated. Your tests should always work for you instead of against you, and letting you refactor without needing to change your tests is a huge win.

---

P.S. I'm not saying you shouldn't ever write wiring tests, but I would recommend using them as plan B. They can still come in handy (e.g. when integrating with libraries that you can't control), but I would recommend against writing them for everything.

Craft

A while back it occurred to me that not every software developer strives to be the best at their craft that they can be. Many don't even regard it as a craft at all, and see it simply as a way to make some money.

Now, I'm not talking about people that put in the 8-5 and go home because, admittedly, that's what I do. But, rather people that are too content with the status quo, or unwilling to change it if they're not. People that aren't opposed to learning new things, as long as they can do it by accident.

I'm not sure why this revelation surprised me, it seems incredibly naive in hindsight, but it did. I guess it's because to me, the interesting part of writing software has always been learning new things, pushing the boundaries of what's been done, and trying to do better than you did last time.

We're not always presented with new, groundbreaking opportunities every day. For example, my current project is an Android app where our biggest goal is to "make it like the iPhone." Not the most exciting thing in the world.

However, the interesting parts are in the details. We're using some great libraries to make testing the app easier, and challenging ourselves to make a cleaner app with better patterns than the last one we did. Everyone on the team is engaged in making this the best app it can be for our client.

It's not always the technical details that matter either. We've been giving thought to how we can improve communication with clients, how we can begin a project with the best chance of success, and how we can make sure we're on track as the project continues. I also feel like I've made huge personal leaps by learning how TDD/BDD development really works and how pairing can help make you better as well.

So who are you? Are you someone who is content with what's been done before? Or are you someone who constantly strives to push things and make them better one step at a time? It doesn't have to encompass your whole life, but it's a fascinating world we work in, and I urge you to take a look.

Do your tools make sense?

A couple of days ago I was talking to a friend and he asked me what some of the fundamental things were that caused me to change jobs. After thinking about it for a while, I think I can start to answer it in reverse - what new things I have seen that I hope every organization I work for from here on out will have.

The first thing that came to mind is just doing things that make sense. This seems like it might be obvious and something that people do anyway, but I assure you, it is not. It's not to the extent that I named this very blog after that very thing - does having a cement cutting board that will dull your knives really make sense? Yet I used one every day for months.

One of the biggest tangible things I can think of is using tools that make our jobs as developers easier. Making our jobs easier = happy developers. We use IntelliJ instead of Eclipse since you get a complete polished package with awesome refactoring tools. We (mostly) use RubyMine instead of TextMate for the same reasons. We use git instead of subversion because you get a much more powerful feature set. We use github instead of our own server so we have less operations overhead. We use rails instead of Spring/Struts/Django/.NET/etc. because we feel it gets the job done easier and faster.

The list goes on and on, and it's always a work in progress, but that's what's so great about it. If a new tool comes along that we feel will significantly make a difference, I guarantee you it will show up on peoples' machines right away.

The point of this isn't to say "you need to use tool xyz", but simply to say that it feels great to work for a place that is willing to invest in a toolset that lets you simply get work done.

It always baffled me before when I was told that I couldn't use a certain tool that had a cost involved (often under $100) because it was too expensive. If that tool had saved me even half an hour of time total the company would have broken even at the rate they billed me for.

One of the biggest examples of this I can think of involved code reviews. At my last company we had always tried to code review everything but had trouble making sure we were diligent about doing them. One day I decided that we needed something better. I started researching code review tools and found one in particular that looked really promising. There was a 30 day trial so I got it up and running in about an hour and we started using it on my team with great success.

The issues started when we tried to convince Those With Money to spend $500/seat on this tool. I completely understand wanting to make sure that you invest your money wisely, but the battle that ensued over this tool, when it had rave reviews from any engineer that used it, was lengthy and ended up with everyone upset and exhausted by the end.

The funny thing is, if this tool could prevent everyone using it from writing one bug every 3 months the company would have broken even on the cost in the first year of using it. (These numbers are based on their calculations.) We had already seen results much better than that in the first 1 month trial, and had already expressed other benefits such as knowledge transfer, reduced time bringing someone new onto a team, and cross-team reviews to name a few. Yet still the battle was fought every day for weeks until a decision was finally made.

(By the way, if you are doing code reviews, I highly recommend using Code Collaborator. It is well worth the price tag and was called out by others as the single biggest improvement in our engineering process that year.)

Probably the craziest situation that I have ever seen happened at another company I was working with. They had a development team of about 10 people, and all the engineers were given mediocre laptops as their sole development machines. To top it off, they were running a heavy webserver (Weblogic), had only 2GB of memory, and had 5400 RPM hard drives with software encryption used on every read/write.

To give you some data points - publishing code changes to the Weblogic server on my dev machine, a fairly pimped out Mac Pro, took about 12 seconds. To publish changes on their laptops took around 7 minutes. Really. I timed it. Twice.

This means that _every_single_code_change_ they did took them 7 minutes before they could see and test it. It was amazing to see their management continually shoot down requests for new machines and then complain about how unproductive this team was!

I guess what I'm really getting at, is working for a company that honestly supports you in getting your work done is an amazing thing. Does it cost more money up front? Yes. Will it pay off in the end? Absolutely. Is it awesome to get to use tools, languages, and frameworks that the developers like? Oh yeah.

So, until next time, keep your toolkit close and your knives sharp.

Why I like pair programming (and why I'm not leaving)

A few friends have pointed out a blog post from someone who recently left Pivotal Labs due to the fact that he didn't enjoy pair programming full time. (It's well worth the few minutes of time to go read it.)

I read through a bunch of the comments on the blog and the linking reddit page and most of them started as "Well I've never done paired programming but..." or "That's stupid! I did pair programming once and...", so I figured I would write up my own reply as someone who has done pair programming full time for around 4 months now.

Mark's post has gotten me thinking a lot about the whole pairing thing and whether it is all that it's cracked up to be. I'm always trying to reevaluate the practices and techniques I'm using, even if I do work for a place that has mandatory pairing on my agenda. (For the record, a few months ago there was a company wide forum where everyone reevaluated as well. The result was nearly unanimous for pairing full time.)

One of the biggest arguments that I heard from the post was that pairing doesn't allow for that sort of reflective, meditative approach to programming. You know, those times when you have a big problem in front of you and you need to spend at least an hour or more thinking about it and coming up with a wonderfully elegant solution. Some people are better at this than others, and Mike seems to be one of them.

In fact, my biggest challenge with pairing is probably the same thing. I like to think I'm pretty good at that technique myself, and I've had my share of cool ideas that have paid off from doing things that way.

However, something just doesn't sit right with me about that. Sure, that lone ranger style of coding can be a lot of fun, and you can feel very proud of your results at the end, but I've found that when pairing you almost always arrive at solutions that are just as good, and often better the first time around than doing them by yourself.

Just last week, my pair and I had a problem where I had a vision of how I thought a part of our system should work out. Part of me was screaming, "I know how to do this... I don't want to explain it, I just want to go off and do it by myself and get him to review it when I'm done!" However, because I was pairing, I found that my pair had some great insight into the problem, and, even though the vision was still mine, the end result came out way better than it would have if I had done it on my own (and I learned a lot from my pair along the way!)

I think that we often overestimate how well we do things the first time. Looking back at some of the code I've been the most proud of, I could convince myself I do it great the first time around. But the reality is nearly every single one of those things has been through a number of revisions that has gotten the code to the state it is in today. Had I paired on those features, I'm sure they would have ended up in a better place more quickly.

Ultimately, I think the pill I've had to swallow about this has been to give up the self for the greater good. As I mentioned, it can be a lot of fun and feel very rewarding to go off and do some meditative programming, but is that what is really best for the project? For the team? For your client? Yes, great things can come from that, but I've seen time and time again that you get to a better place faster by pairing. You also spread knowledge between team members faster, write fewer bugs, and generally stay more on course by writing less unnecessary code.

Additionally, I find the extra knowledge and learning I get from pairing helps make up for the lack of satisfaction I used to get from being the lone coder. There are many ways to collect paychecks as a programmer, and I can't fault someone like Mark deciding pairing isn't how they want to do it. But for now, I've decided to try to give up a bit of my pride, drink the kool-aid, and embrace pairing and the team centric atmosphere it creates. I can't ignore the results I see every single day of being more productive and having a better product to show for my efforts. Obviously you will have to make your own decisions for yourself.

P.S. Here's another post from a Pivotal person on the same topic. Also worth a read.

Trifecta

Software engineers are a strange bunch. We're forced to thrive on bits of random trivia, and are often literal to the point of being intolerable. It's sort of a cart/horse dilemma though, I'm not sure how to write the causal equation although I suspect that software gives us an outlet for our oddities more than it creates them.

One of the seemingly more peculiar attributes (good) software engineers have is the fact that they want to be productive and do good work. If given the choice to face a challenge or avoid doing any real work most of us would pick the challenge every time. What this gives a manager of such engineers is huge potential that just needs to be pointed in the right direction.

However, there are a few key things that can squash the enthusiasm of any engineer. Or rather, there are a few things that need to exist for them to be content. After many conversations about this with my colleagues, I think I've been able to boil it down to three fundamental concepts.

Here, I present to you, the Software Engineer's Trifecta of Happiness:

- Cool stuff to work on
- A good work environment
- Fair compensation

If we can have these three things, happy and productive engineers we will be.

Cool stuff to work on

First and foremost, cool stuff to work on is going to be key to most software engineers. If we are bored at work we won't be sticking around that long. This doesn't mean that we have to be constantly inventing the latest and greatest startup idea with bleeding edge technology, but we need engaging challenges to work on.

Bob's Brochure Site #7 might not sound all that exciting, but there can almost always be challenges found in the details of even a mundane task. However, if our work environment doesn't encourage innovation and forces us to do Bob's Brochure Site #7 exactly the same way as we did #1-#6 any chance of it being a cool project are nil.

Software engineers love our craft because it lets us invent things. One of our core principals even states that repeating ourselves is one the greatest sins you can commit. If we're not given the freedom to experiment and try to improve the project and ourselves we'll grow tired of any project that is thrown our way.

A good work environment (a.k.a. respect)

Respect is our currency. It's how we interact with each other and how we organize ourselves. Pretty much everything that goes along with a software engineer's good work environment has to do with respect. Sure, fun perks are great, but even that gets translated to showing respect for the employees' well being.

A good work environment also has to be supportive and empowering. Like I mentioned about cool projects, if the environment isn't conducive to growing and being productive it's really hard to be satisfied. If we can't feel any ownership over the projects we work on our motivation plummets.

We're stereotypically quick to complain, but that stems from having a very low tolerance for things that don't make sense. This low tolerance is part of why we are good at our jobs - being able to quickly decide something is suboptimal is a key skill to have for software development. There are few things that kill our enthusiasm faster than feeling like management or policies that don't make sense are getting in the way of our work. To us, it seems like these kind of managers or policy makers don't respect us enough to bother making good, thoughtful decisions. We're coming in every day, trying to work, and people that are supposed to be on our team are putting roadblocks in our way.

I could go on and on about what makes a good work environment, but it's way too much to go into right now. To summarize - treat us with respect. We don't have to get our way all the time, but you can't pull the wool over our eyes about things that directly affect us and expect us to not notice. Let us know why things are happening that seem counterintuitive and they will be much easier to swallow. If you can do that and give us an environment that encourages us to grow and constantly improve ourselves and we'll happily crank out feature after feature. And always remember the cement cutting board principle - let people affected by the policies help make the decisions.

Fair compensation

Ah, everyone's favorite topic. At the end of the day, the reason everyone goes to work is to get paid. The trick is to make us forget that's why.

Money really isn't a good motivator for software engineers. We're more than happy to get paid a fair market price to do our jobs. However, money is a great de-motivator. Not getting paid competitively ties back to the the respect issue. Unless you can provide amazing projects at an amazing place, we're going to notice that our paychecks are lighter than they could be. We're pretty good at doing greater-than and less-than comparisons ;) Soon we'll begin to feel that people don't appreciate the work we do.

I think places like my current job get this one right. Everyone's compensation is presented neatly and fairly and is competitive in the local market (really). You know exactly what you're getting, and then you can forget about it. The last thing you want is as bunch of employees focused on their compensation. You need those brain cycles spent on development, not grumbling about money.

---

So there you have it, the Software Engineer Trifecta of Happiness. Three fundamental principles that when combined make a surprisingly potent combination. The best part is all the legs of the trifecta focus on being more productive and being able to take pride in a job well done, something that everyone from clients to managers to the employees themselves want anyway.

Extreme musings pt. 2

This is part 2 of my reflections after 2 months of XP development. (Part 1 can be found over yonder.)

A culture of productivity

One thing that XP really fosters is a culture of getting things done. The entire process is focused around delivering tangible business value to your customer. TDD, and even more-so BDD, are setup so you only write the code you need to get an actual task done. Gone are the days of engineering an entire framework only to later realize it won't work with future requirements or that it wasn't needed at all.

One thing I do miss with this style of development is that it can be fun to architect the frameworks. There is definitely a perceived elegance to throwing some headphones on, getting in the zone, and cranking out huge swaths of code.

However, even though I think I've had success with writing those kinds of frameworks, I can't argue that XP delivers more business value faster. There is still room for those frameworks in XP, but you don't end up writing them until there is a real need for them.

I've heard a saying before that goes something like "The first time you write something, do a one-off, the second time do a one-off, and the third time figure out if there's an abstraction." This what XP guides you to do.

Another thing that's really refreshing is that everyone I now work with is simply focused on being productive. It's not even a burden to them mandated from some whip-cracking exec as much as it is just who they are. An XP shop, at least the one I'm at, seems to automatically weed out anyone who would rather spend half a day surfing the web than be working. The fact that your pair can probably tell the difference between reddit and an IDE probably helps ;)

Less stress

As a whole, the developers I work with who are doing XP are less stressed than any other group I've ever seen. A lot less actually.

A common myth seems to be that if you're not stressed, you're not working hard enough. It's as if there is this secret potential that can only be unleashed if you're stressed. I think it's just the opposite, at least with people who naturally want to be productive. (And do you really want to work with anyone who's not?)

XP (and Agile) is all about getting the most value out of the time you have. You have 4 developers and 2 weeks - lets get the most value we can out of it. Everyone is considered on the same team and everyone has the same goal.

As long as everyone on the project agrees to stick to that approach it results in really happy developers who are excited to crank out quality features faster than I've ever seen. I've been lucky and haven't had to deal with external pressures such as a conference or presentation that might squeeze the timeline yet, but I would say there is less total stress among the ~50 developers I currently work with than the amount in the 12 developers I was with previously.

Also, in true XP fashion, overtime is pretty much disallowed. There are rare cases where this rule is broken, but it's far from the norm. Having a team of fully rested, alert developers seems be often under-appreciated elsewhere, and I'm glad that, as an anti-cement-cutting-board company should, a good life/work balance is highly valued.

Happy customer

All these factors seem to result in happy customers, which is a huge win. Having an honest and engaging relationship with your customer might seem scary at first, but when it works it's a beautiful thing.

Most of our projects have the product owner on-site where they can see exactly what is going on every single day. There's really no way to hide anything, and in the end you realize you don't need to.

For example, my current customer has been quite satisfied with the results we've been able to deliver, and I think it's largely the XP process we can thank for that. We've been honest with him, and he's appreciated that. When thing are good we let him know, and when things aren't going as planned we tell him honestly. The transparency has built a level of trust within the team that is really refreshing. Ultimately, it's better to have your customer decide to abandon a non-essential time sink of a task than to pretend everything is ok and end up delivering sub-par quality.

If XP is wrong, I don't wanna be right

At the end of the day, XP isn't a perfect glowing mecca of butterflies and sunshine, but it's as close as I've seen so far. I often feel like I'm at some sort of oasis where developers have gathered after being worn out at other jobs.

It's really great to be a part of a dedicated team of people solving real problems and providing real value every single day. When you couple that with an environment of honesty and an intentional lack of overtime, you don't have to twist my arm to convince me it's where I want to be right now.

People ask me how we can survive in the economy when we bill in pairs and pay employees well. I tell them I don't know all the details, but we constantly have so much work we're turning down jobs - so something must be going right. At this point, as long as I can have a job where I get to work like this I'll let someone else worry about the rest :)

Extreme musings pt. 1

The main reason I started this blog was to chronicle my thoughts as I transitioned not only to a new job but to an entirely new development style. Since I'm approaching the 2 month mark, I figured now was a good time to check in.

To recap, I'm now doing fairly strict XP - pair programming full time, test driving everything, and an engaged customer whose job it is to manage our backlog. Previously I was doing some sort of half-assed scrum/agile where our biggest victories were having CI, sprint planning meetings, and short (2 week) releases.

Pairing

One of the biggest changes and something I've written about before is pair programming. I had done some pair programming before both in school and professionally, but only when tackling an especially hard problem. Doing it for a full 8 hours every single day is a different beast entirely.

It probably goes without saying that the most critical piece of the pair programming equation is who you are pairing with. I've had the opportunity to pair with 6 people in the past 2 months and each person has been radically different than the last. I could probably write an entire post about different pair personalities, but to keep this at a high level, I think there are 2 main points I've discovered: There are people I really enjoy pairing with and it's been equally helpful to pair with everyone on the team. (To be fair, I haven't paired with anyone I've disliked, but inevitably you'll work better with some than others.)

Obviously it sounds like it would be great to pair with the people you really click with, and it is. But I think that pairing with the other people is equally important. There are always things to learn from pairing with someone new, and I've found it's very important when working on a team to understand the position of all team members on the project. Most of the time when developing, you're spending your brain cycles figuring out how pieces of the application should go together, and the more people you've paired with, the better your understanding of the pieces will be.

Tests f-ing rock

Having a full test suite on your application is awesome. I really can't say that enough. Having a full test suite on your application is awesome. There, I said it again.

I've been writing unit tests for a few years and before doing full time BDD I always felt like I was missing an important piece of why tests are useful. I get it now. When you truly have complete test coverage of your application you are in a position of great power and flexibility. Refactoring, even scary refactoring, is suddenly conquerable. Bugs are more often "oops, we forgot about..." instead of "dude, did you even run this before you committed?!"

The thing about tests is that if you don't have full coverage, you're only getting a fraction of the benefit. It's not until you can reliably count on your tests catching any bugs that you can reach the full potential of a test suite. I do think that some tests are better than no tests, but once you hit the magical full coverage mark, it's an exponential growth in what you get out of them.

(By "full coverage" I don't necessarily mean every single line is directly tested, but that the intent of each method and class is covered. Think BDD instead of TDD, although I'm sure more "pure" TDD can have the same benefits as well.)

...

This post started to get a bit longer than I originally expected so I'm going to break it up into more parts... installment 2 coming soon :)