DISCLAIMER: Nothing said in this post should be taken as a reflection of my relationship with any of my employers or clients, current or in the past. Thankfully the ones I’ve had have been pretty good.

How do you view your relationship with your employer? More specifically, what is your response to your employer’s requests and demands?

I feel that many people view the relationship with their employer like a sort of indentured servitude where you also collect a paycheck. When I say that, I don’t mean that in a negative way, because most people don’t think of their manager or employer in a bad light. But I feel that most employees feel like they should do whatever their employer asks them do without raising a fuss (unless something they are asked to do is unethical). Again, I’ve thought this way in the past, and I never really thought of my employers negatively (in fact, I really liked them).

The Business Of You

Today I would argue that this is not the correct way for you as an employee to view this relationship in most cases. (Yes, I am an independent consultant, so I don’t really have an employer, but I still work for and report to clients.)

Business have all kinds of relationships without outside vendors. For example, a business may have preferred hardware vendors, vendors that provide hosting services, vendors that provide janitorial services, and so on. These relationships are all mutually beneficial partnerships, where each side of the partnership has something to gain from the relationship. Businesses also have partnerships with software developers like you.

Whether you think of it this way or not, you are running a business. Your business sells your software development services. You have a business plan, goals, a balance sheet, and things that you value (you might not have these things written out, but you still have them). Your values for your business might be to make a certain amount of money, to work using a technology you enjoy, to feel like you’re making an impact on the company you work for, have time for whatever hobbies you like to do, and have ample time to spend with your family. Your family is also a part of your business because they are something that you value, and what happens at your place of work affects them too (either directly because you’re gone at work or indirectly because you’re stressed out when you get home).

I think you might view your relationship with your employer differently when you view it as a partnership between businesses. Businesses and vendors negotiate all the time on any number of issues (and not always related to money). If you think of it this way, instead of your employer unilaterally deciding the path for your business, it should be something that you both agree upon that is mutually beneficial for both sides.

Protect Your Business Interests

Like I said, I’ve had the good fortune of working for good people throughout my career, but unfortunately there are employers and managers out there who will try to coerce you into do things that are not in your best interest. For example, maybe you’re heard things like these from your manager:

• “We have a lot to get done this release and we can’t afford to hire anyone else right now, so you all are going to have to work a little extra to get this done.”
• “I know that I told you to build the feature that way, but actually it needs to work this way… but I still need it done by the same date.”
• (a few days before a release) “This feature just came up and we really need to get this in, I’m going to need you all to stay late to get this done.”

Overtime, while not ideal, is a part of what we do. There are going to be deadlines, server outages, and things like that. But there’s a difference between normal overtime (server outages happen and someone needs to fix them) and someone taking advantage of you either for their own benefit or because they don’t have the guts to say no to their superiors.

Every situation is different, and maybe you’re OK with these sorts of requests. Maybe you get paid overtime and you like the extra money. Maybe you are willing to go the extra mile to get ahead or get a promotion, or maybe you don’t have many other job opportunities out there so you have to stay and deal with it. Maybe you’re in a job where overtime is expected and you knew that going in.

The important thing is to think of your career like a business. If you’re employer is trying to get you do something that isn’t good for you, don’t just sit there and let their decisions drive your business. This also applies if you want to work with a certain technology or skill set and your company doesn’t have that kind of work for you. Be willing to say no, or even be willing to go find another job. Your career should be something that benefits you and benefits the people that you work for, and as soon as one side isn’t getting any benefit, then something needs to be done.

I spent my lunch hour at the Path to Agility conference talking with a friend of mine who is in the middle of trying to get his team to embrace some agile practices, particularly around automated testing. Some of the changes that he’s trying to implement are causing some friction with the team who are not embracing the change.

People not wanting to change is nothing new. But what is the reason behind that unwillingness? It’s real easy to blame the team members and just say that they don’t care, they’re lazy, they like technology X instead of the new thing, etc.

Instead of just blaming others, maybe we should look at how we (as the change facilitators) are helping to create a desire to change and an awareness that there is even a need for change. If you’ve been doing your job a certain way for the last 10 years at the same company and you’ve been getting praised for your work or getting good performance reviews and raises, why should you change? After all, your company has been telling you that you have been doing an exceptional job. And now you’re being told that the way that you’ve been doing it is wrong?

This is what makes situations like this particularly challenging. Before we can even expect people to change, we need to show them that although they have been doing a good job in the past, we have an idea of how they can do their job even better. For some teams, having 50 bugs in production each month might seem good to them if last year they had 80 bugs in production each month, when for some teams having 5 bugs a month in production is a lot.

Unfortunately there is no easy answer to this problem. In fact, I can’t even say that I really know how to effectively handle these things. What I am learning is that the people side of software development is probably the most difficult part, and it’s probably where we all need the most work.

Here are the slides, code, and links from my Testable, Object Oriented JavaScript talk at Stir Trek.

Slides
Code
JSView
Jasmine

Have fun with it, I’m always open for suggestions with this stuff, so let me know if find ways to improve it.

TDD Immersion is a half-day session where we’ll cover what you need to know to do TDD on real .NET projects. We’ll go over stuff like:

• How to write tests first
• How to refactor your code to make it easier to test
• Mocking frameworks like Rhino Mocks
• Dependency injection – what it is, how it works, and how to set it up in your project
• TDD tips and tricks

We’ll also walk through a sample ASP.NET MVC web app and show you how you might set up an actual project, work with ORMs and data access layers, set up your test projects, and make things easy to test.

This will take place on April 21 from 8:30-12 at the Microsoft office on Polaris Parkway in Columbus. We’ll have food and drinks for breakfast, so show up a little early to get something to eat. We’ll start promptly at 8:30.

If you plan on coming I need you to register so that we make sure that we have enough room and food for everyone.

We won’t be doing any hands-on coding this time, so you don’t need to bring your laptops. There is no wireless access at the Microsoft office.

Since some of you asked, here are the slides from my TDD in Action talk at CONDG last week.

I’ll be speaking on test-driven development at CONDG on Thursday, Jan. 27 at 6pm. I’ll show you some live TDD coding and explain how TDD can help you write awesome code and eliminate defects. Hope to see you there!

One thing that you’ll find on pretty much every Agile project is some kind of card wall where features are tracked.

When I started working on Agile projects several years ago, I didn’t quite understand the purpose of the card wall. I thought, wouldn’t you rather just track everything in some online tool?

While tracking things in an online tool is still a good idea, the Agile card wall gives you a level of transparency that it’s difficult to get from an online tool. With a good card wall, you can easily see what everyone is working on, what still needs to be worked on, how long the remaining work might take, and what’s blocking your progress. There is so much to keep track of on a software project, and it really helps when you have a visual aid that can help keep everything in front of you so that you don’t have to juggle everything in your mind (or some online tool).

The trick is to tweak your card wall to give you the most transparency as possible. Here are some things that I’ve found help me get the most of my card wall.

Everything is a task

Everyone puts development tasks on their card wall. However, not everything that your team does could be categorized as a deliverable feature. In fact, there are lots of other things that you might have to do:

• Write up documentation on a wiki
• Onboard a new team member
• Set up a CI build
• Get ready for a demo

These are all tasks that are completed by development team members that take a measurable amount of time. So why not create a card and put them on the board? Maybe you use a different color card to indicate that it’s an internal task. This gives you two benefits — you know what people are working on and you can use the estimate to gauge how much work is left to be done.

Make card walls for your entire team

If our development card wall can help us track what developers are working on and how much work is left, why not create card walls for the entire team? You could have a card wall for BA requirements gathering, QA creating test plans, project management tasks, or some mini-project that you want to track separately. You get the same benefits that you get with a development card wall — you know what people are working on, you can easily see the status of the effort, you can prioritize the backlog, and it can help you get an idea of how much work is remaining.

Make problems obvious

Your card wall should alert you to any problems and blockers as soon as possible. As a team lead, your job is to try and remove any blockers and constraints that could keep your team from being able to do their job. Some ways that you can do this:

• Create a separate section of your card wall for blocked items
• If something is blocking a feature, put a post-it note on the card and write what the blocker is
• Structure your card wall so that you can see problems immediately just by glancing at it

Let’s look at some examples of some simple card walls and we’ll interpret what we see.

Example #1

In this example, we can easily see that we are either developing things faster than we can test them, or things are getting stuck in testing due to bugs. We may need to assign more people to testing or work on reducing bugs.

Example #2

There are a lot of features that are blocked. We should try and address the blocking issues and look and see if there is some greater problem that is causing things to get blocked. Maybe we need to write better features, or maybe we need to get more time from people in the business who can answer questions.

Example #3

We don’t have much in our backlog, so the developers are going to be out of stuff to do really soon. We may need to get more people working on requirements gathering.

Example #4

Things are flowing pretty smoothly. We have a good sized backlog, no blockers, the work is evenly distributed, and we’re getting a lot done.

The key is that we want to see problems as soon as possible so that we can take the necessary steps to correct the problem and keep things moving.

Address technical debt as part of the process

As much as we hate to say it, sometimes we are forced to shove in lower quality, untested code in order to meet a deadline. I don’t like having to do this at all because of the risks, but when this happens, keep track of all technical debt that will need to be fixed and create separate cards for fixing it. Make these cards a different color so that they stick out. Then use your board to explain to your manager or project sponsor that you’re going to need some time to go back and fix the technical debt. Many managers want to pretend that the work is done once you release and will convince themselves that they can just move on without addressing the technical debt. You know better, and it’s your job to state that case and show why it’s important.

Refactor your card wall

Your card wall is yours. You create it, you manage it, and it belongs to you. Don’t be afraid to rearrange and refactor your card wall so that it can better meet your needs. Don’t make excuses like “we’ve always done it this way” or “we read a book that said to do it this way” or things like that. Your process and tools need to serve you not the other way around.

Pick up a book on Agile practices and you might find a wonderful, yet often unrealistic view of a perfect world where everyone buys into Agile practices throughout the business and you glide gracefully down the road to success.

The problem is that for most of us, that perfect environment doesn’t (and will probably never) exist, and that’s OK.

Maybe your team isn’t staffed the way that it needs to be. Maybe the people on your team don’t have the right skillset (yet). Maybe you have to integrate with lots of other systems, so you have to do a lot of up front planning and design so that you can make sure everything gets done on time.

The point is not to implement 100% of Scrum or XP or Kanban or some other methodology. I like to boil Agile down to this:

Do more of what works and less of what doesn’t.

Implementing 100% of XP may not be the best thing for you, or it may not be feasible. That’s not XP’s fault, they’re just giving you a set of best practices to work with that have proven to work well for some people. It’s up to you to make it work for you. Frankly, I don’t think it matters if something you do falls in the category of “Agile”. I just want to find ways to improve the development process, regardless of what you call it.

One practical thing that we all can do (whether we’re in charge of a team or not) is to try to improve our development process every day. Try to find ways to do more of what works and less of what doesn’t, improve processes and communication, and help your team succeed. Set your sights on the end goal and start taking steps in that direction.

As soon as you write code, bad things can happen. Your code can be defective, and it can break existing code. It’s our job to make sure that we don’t break things.

Not breaking things is not easy. You might end up with only one bug that sneaks through into production but that can be one too many.

The team I’m on is currently trying to figure out what our plan is for testing and QA. We have two concerns:

• How can we wrote code without defects?
• How can we make sure that our code changes don’t break existing code?

The second one is proving to be the difficult one. Our application is 4 years old, and a good chunk of the code was written by people who are no longer on the team. It’s really difficult at times to not break something when you don’t know enough about the system to know the ramifications of what you’re about to do.

When I develop new code, I try to figure out how we can validate that everything is working and complete. When possible, I want to write automated tests. In the Ruby world, I’m using Rspec and Cucumber to do this. I want to make sure that all of the code that I write is covered by a test if possible. Thankfully Rspec and Cucumber do not make this very hard at all, and we tend to test the crap out of things as a result.

But some things are hard to validate. For example, if you’re pulling a subset of data from an external database using an SQL query, how do you know that you’re pulling back the correct data? It’s hard (if not impossible) to write an automated test for this, and in some cases you have to coordinate with someone on the team that owns the database in order to test it. It’s really important not to ignore these tests and just say that it’s going to be too hard to test. Unless you’re OK with it being broken, you have to validate it.

As a developer, don’t think that this is just the responsibility of your QA team to figure out how to test things. Certainly your QA team should be involved in coming up with the plan for testing, but you might know of edge cases that a QA person wouldn’t know about, and you might know of technical constraints that might make testing hard. Too many defects are created because developers put the onus on QA to find everything. Remember, we’re all on the same team.

So now you go into production and you move on to something else, but you’ve created a lot of features that will need to be regression tested. Here is where I think it’s really difficult. How do you keep these regression tests up to date? For example:

• When you add a new security role to the system, do you update old test plans to test whether or not the new security role should be able to do something?
• If you change a validation rule, do you update old test plans that could be affected by the new validation rule? (This could mean adding new tests to an old test plan because you might now have two paths through something where you might’ve only had one test before.)
• When things change like this, how do you even know where you might need to update test plans?

I’d be interested in hearing how you all handle these situations. This is a situation where I’m really glad that I have automated tests (yesterday I was doing a big refactoring and my Cucumber tests pointed out a whole bunch of things that I had broken). But automated tests only solve the problem when you have a test for something. If you create new paths through the code that now don’t have a test, you need a way to find those scenarios and write tests for them.

It seems that the accepted way to test in Ruby is to use Rspec for unit tests and to use Cucumber for acceptance tests (higher level functional testing). After doing a little bit of Cucumber, I’ve started to fall in love with the format of Cucumber tests.

Most Rubyists would probably agree that behavior-driven development is good (in other words, writing tests in a Given/When/Then format). We obviously do this in Cucumber (there isn’t much choice), but I’ve also written tests in this format in Rspec and in .NET.

I like BDD for two main reasons. First, I believe that software development is a series of translations. I want to translate business requirements into readable, executable specifications, then translate that into tests, then translate that into implementation code. Second, before I implement a feature and even before I write my tests, I try to write out what I want the code to do in English. If I can’t write out what I want to do in English, how and I supposed to know what I’m supposed to write in code?

Here’s my theory: if we agree that BDD is good, why don’t we write our unit tests in a format that is more amenable to BDD, that being the Cucumber format of tests? I’m not saying that we write acceptance level tests instead of unit tests, I’m saying that maybe we should write unit tests in a different format. Not only that, Cucumber tables give us a nice way to write more readable, data-driven tests. Here are a couple examples from the supermarket pricing kata (in Rspec and Cucumber).

Cucumber:

Feature: Checkout

  Scenario Outline: Checking out individual items
    Given that I have not checked anything out
    When I check out item 
    Then the total price should be the  of that item

  Examples:
    | item | unit price |
    | "A"  | 50         |
    | "B"  | 30         |
    | "C"  | 20         |
    | "D"  | 15         |

  Scenario Outline: Checking out multiple items
    Given that I have not checked anything out
    When I check out 
    Then the total price should be the  of those items

  Examples:
    | multiple items | expected total price | notes                |
    | "AAA"          | 130                  | 3 for 130            |
    | "BB"           | 45                   | 2 for 45             |
    | "CCC"          | 60                   |                      |
    | "DDD"          | 45                   |                      |
    | "BBB"          | 75                   | (2 for 45) + 30      |
    | "BABBAA"       | 205                  | order doesn't matter |
    | ""             | 0                    |                      |

  Scenario Outline: Rounding money
    When rounding "" to the nearest penny
    Then it should round it using midpoint rounding to ""

    Examples:
      | amount | rounded amount |
      | 1      | 1              |
      | 1.225  | 1.23           |
      | 1.2251 | 1.23           |
      | 1.2249 | 1.22           |
      | 1.22   | 1.22           |

Rspec:

require 'spec_helper'

describe "Given that I have not checked anything out" do
  before :each do
    @check_out = CheckOut.new
  end

  [["A", 50], ["B", 30], ["C", 20], ["D", 15]].each do |item, unit_price|
  describe "When I check out an invididual item" do
    it "The total price should be the unit price of that item" do
      @check_out.scan(item)
      @check_out.total.should == unit_price
    end
  end
end

  [["AAA", 130], # 3 for 130
    ["BB", 45],  # 2 for 45
    ["CCC", 60],
    ["DDD", 45],
    ["BBB", 75], # (2 for 45) + 30
    ["BABBAA", 205], # order doesn't matter
    ["", 0]].each do |items, expected_total_price|
    describe "When I check out multiple items" do
      it "The total price should be the expected total price of those items" do
        individual_items = items.split(//)
        individual_items.each { |item| @check_out.scan(item) }
        @check_out.total.should == expected_total_price
      end
    end
  end
end

class RoundingTester
  include Rounding
end

[[1, 1],
  [1.225, 1.23],
  [1.2251, 1.23],
  [1.2249, 1.22],
  [1.22, 1.22]].each do |amount, rounded_amount|
  describe "When rounding an amount of money to the nearest penny" do
    it "Should round the amount using midpoint rounding" do
      RoundingTester.new.round_money(amount).should == rounded_amount
    end
  end
end

A couple things stand out to me when you compare these two. First, if I want to run data-driven tests with different values, the Cucumber syntax is so much cleaner and more descriptive. Second, the “Given I have not checked anything out” section in the Rspec version is really long and contains two nested “describe” sections (many times you end up with many more than this). When you nest sections like this, it’s really hard to see the context of things or read the tests because the “Given” text is nowhere near the nested “When” sections in the code.

Rspec follows in the footsteps of previous unit testing frameworks that write test methods in test classes (or in the case of Rspec, something that resembles test classes and methods. But is this the best way, or just the way that we’re used to? We have been writing unit tests this way for years and years because we had no other choice. But that doesn’t mean that it’s the best way.

Here are the benefits I see of using the Cucumber syntax over Rspec:

• The tests are much easier to read (especially when doing data-driven “scenario outline” tests).
• The Given/When/Then text is all in one place (as opposed to spread out and mixed in with code).
• It forces me to be able to write out in English what I want the code to do.
• Any step definition that I write can easily be reused anywhere in any other Cucumber test.
• The code just looks cleaner. I’ve seen a lot of messy Rspec tests.
• Rspec doesn’t have a method that corresponds to the “When” step (unless I’m missing something), so you have to shoehorn it into before(:each) or the “it” method. (I’m not sure why this is, we figured this out in the .NET world long ago.)

To be fair, there are more BDD-friendly flavors of Rspec (like rspec-given). This helps you write tests in Given/When/Then format, but I still feel like all of the underscores and symbols and syntax is getting in the way of the actual test verbiage.

Favoring Cucumber is my personal preference and I know that there are some people that would probably disagree with my opinion on this, and that’s fine. But I’m really enjoying what Cucumber brings to the table, both in terms of functionality and the syntax.