Simon has a new post describing how they’ve revamped their planning board. I found it to be an interesting read because for once someone else’s board looks similar to ours.

Our board has undergone a few makeovers as well over the past couple of years. In the beginning we tried to do what everyone else was doing. We had a big board with several columns. But our shop was small (at it’s peak, three developers and a PM) and the extra columns seemed wasteful. We didn’t really have a QA team, for instance, because we were the QA team. A “Testing” column seemed like a waste because we practice TDD as much as possible, so testing is part of the process of development. Same goes for acceptance tests, hands-on testing and customer approval. It’s all part of the process of developing software. Personally, I don’t look at the different elements - like architecture, design, testing or customer feedback - as separate phases. I see them as the one thing: developing software. They are all necessary elements to reach the final goal of a completed, working, and trusted software feature.

In the end, we finally settled on was the simplest thing that could possibly work: Backlog, In Development & Done.

Our Backlog is every story card in our possession. We don’t categorize; we just let the customer prioritize. In Development is everything we’re working on during this iteration. Since we - the developers - do it all, then In Development carries a comprehensive meaning. And when all the bases are covered, regardless of what order they were performed (although I hope unit tests were written before the code was) then, and only then, does it move to Done.

What I enjoy most about our board is that it is so simple to read. It’s easy to determine what’s left to do (Backlog), what’s being worked on (In Development) and what’s ready for the next publish at the end of the iteration (Done). And I don’t need to worry about testing or customer approval because those elements of the development process are implied.

For a while now, my employer has maintained an opening for a talented software developer. They have not advertised the position very heavily because (a) we live in an area that is not rich with developers and (b) our small, Agile team has chugged along fairly well without this extra person.

That all changed today when a colleague - and friend - opted for greener pastures. He’s returning to the company where he started his career as an intern, a place he is particularly fond of, and I cannot blame him for taking a job that more closely fulfills his professional and personal desires. I wish him all the best.

Still, our small team of developers just shrunk by one, and we need to fill the gap.

In a larger city this would not be a problem. We’d just advertise the position and the resumes would pour in. But our location is our biggest hurdle when it comes to attracting talented developers. We simply can’t pull from as large a pool as a city like Austin, Texas can.

So where do I work? Nez Perce County, a small county government in north-central Idaho. As one might imagine, it is not exactly a mecca for software development talent. But that hasn’t stopped us from trying. People we talk to are always surprised to learn that our tiny little IT shop in Idaho is practicing Agile techniques. Yet that is exactly what we’re doing.

We subscribe to Agile practices, Extreme Programming in particular, and we drink from the TDD fountain. We use Continuous Integration, unit tests, acceptance tests, and frequent customer feedback along with short iterations to write quality, maintainable code and deliver business value to our customers (which, incidentally, includes us, since we are also taxpayers; we’re our own bosses in manner of speaking).

We work in an open environment and every developer has two monitors at their workstation. We work closely together as a team and have an on-site customer to help provide rapid feedback.

What We’re Looking For

We realize that we’re a bit handicapped by our geography. We’re not going to see a lot of great resumes. So it’s important for us to identify candidates that have the capacity to learn and possess a passion for software development. Ideally, candidates for our shop would have the following qualifications:

• Knowledge of Object Oriented design and principles
• Knowledge/Experience with C# .Net, or a similar object-oriented language (Java, C++)
• Database experience
• Willingness to learn

Bonus points for knowledge/experience with any of the following: Gang of Four design patterns, Unit Testing, IoC, CAB and/or SQL Server.

More information about the position, including benefits and pay, can be gathered by contacting my boss, Randy Buttenhoff, via the Nez Perce County IT web page.

“You need to unit test your emails”

Comment from a coworker, proofreading another coworker’s email, after discovering grammatical errors that were the result of a long day.

Recently at work I was asked to review some code with a coworker who was concerned with the way her code look. It didn’t seem “right” to her, and she wanted to me to look at it and see if there was a better way.

The code had unit tests and FitNesse tests and the code coverage statistics revealed that it was covered 99%. It was a complex piece of business logic and it did what it was supposed to do according to the tests; they all passed. But still, my coworker didn’t feel like she had written it as well as it could be written.

“It seems too procedural,” she said. So I took a look.

It was a single class that consisted of one method; it’s job was to perform calculations on some values on a given business object. The method consisted of 433 lines of code. Sure, it was broken up into smaller private methods that were a bit more descriptive, but it was still 433 lines of code for a single method call. And there were comments littered throughout the code informing the reader of what it was actually doing. See, despite the dozen or so private methods that had descriptive names, you still couldn’t follow it by just reading the code. It was too complex, a by-product of the code being procedural.

The length and complexity of the code wasn’t the only smell. The unit tests gave off their own oder as well. Some of the unit tests were as many as 30-40 lines of setup code; tons and tons of mocks just to test one path through the code.

To my coworker’s credit she recognized the deficiencies in her code. She knew it was too procedural, she knew the tests were too big and required too much setup, and she knew that the entire solution needed to be more object oriented.

She just wasn’t quite certain how to get there.

We started refactoring by first asking the question: What is this method doing? What is its responsibility? At first glance, it looked like it was supposed to do one thing. But when I prodded my coworker further we both realized it was actually doing six different things. Six different things in one method; that was too much work.

So we left her code behind and started with a new concrete implementation of the main class, implementing the interface that the original class implemented. We began by asking questions about what each responsibility inside that giant method call was, and what might a class look like that would implement just that single responsibility. The outer class and the single method call would then become a simple coordinator between all the smaller classes.

When we finally started coding, we creating those classes, test first. Each little class got its own test fixture and group of unit tests. The logic in the 433 line of code method started to get pushed off into he smaller objects. Since they were small classes responsible for a single responsibility, the code that got pushed off actually became smaller. There was less to do - less branching - so the result was a tight unit of code that did one thing and did it well.

Slowly, piece by piece, bit by bit, the giant 433 line method got broken up and reformed into a new method that called the tiny classes where appropriate.

We didn’t finish the entire refactoring that day, but we were well on our way to a much better design. And the process was a great learning tool. My coworker got to see how procedural code could be turned into an object oriented design, and how certain small classes could be reused in the larger algorithm.

At the end of the day my coworker turned to me and said, “So I guess if a method is larger than my screen, I need to rethink it, huh?”

And I thought: that’s a great rule of thumb. It is one that I have followed for quite some time in a sort of instinctive way. If I find myself writing a method that ends up being larger than my screen in Visual Studio, I know there’s a chance to refactor to a better design. Methods shouldn’t be that big.

When we left work that day I felt a great sense of accomplishment, and I know my coworker did too. She learned a lot, and our code quality improved significantly. The FitNesse tests will still pass when we complete the refactoring, so the end result won’t have changed much. But a big win still occurred: our design was better and would be much more maintainable moving forward.

I got into software development because I wanted to make video games. That didn’t work out, but I stayed in software development because I enjoyed the idea of being able to enact immediate change in my work. Software is soft, and that means we can improve it today, tomorrow, next week or next year. And we can see the results of our improvements immediately; we don’t have to wait for the cement to harden, we can just hit “Build”.

But quite often there are barriers to enacting change and improving design, and often those barriers come in the form of customers.

Agile development teaches us to be flexible: we utilize clean designs with clear separation of concerns so that we can refactor our code as necessary to meet the changing demands of the customer; we use proven patterns and practices so we can stay out of dangerous waters; we use nifty tools to help increase our productivity. But the thing that doesn’t get talked about enough is the inflexible customer.

There’s a phrase where I work that crops up in just about every conversation we have with our customer: We’ve always done it that way. That phrase has has single-handedly added more lines of code and more complexity to this project that anything else I can think of. It has destroyed our ability to simplify our design. It has lengthened our development time considerably.

And it has ripped out my heart.

I love software development - when it is software development. What I don’t enjoy is having the customer rigidly dictate the design of an application based on some pre-existing paper process and then making sure to squash every effort to improve the workflow or the software by repeating the mantra, “But we’ve always done it that way.”

I can honestly say nothing kills my excitement - nothing quenches my fire - faster than, “We’ve always done it that way.” I imagine it is like staring at a hideous mess of code and having someone say, “You are not allowed to touch that - don’t refactor that at all - we’ve always written code that way.”

I’m curious to know what other developers do to survive a customer like this. What keeps your passion afloat when you’re presented with this situation? I’m having to fall back on Personal Pride and Work Ethic. And honestly, I hate those guys. Yeah, they get the job done, but they’re so much less pleasant to be around than, say, Passion and Excitement.