Chris Holmes Online

Allow me to lay out a story that should sound familiar:

A couple of coworkers are discussing a bug in the software. In this particular bug’s case, it concerns an icon that appears in a column of a datagrid. Each row in the grid is either supposed to have this little icon in a specified column, or not. It depends on the data. But that’s not really important, just background info.

What’s really important is that the icon was previously coded and tested and worked. It appeared under the correct conditions and was hidden when it should be. Now, all of a sudden, it wasn’t working. We get an e-mail from customers saying, “The icon should show up in this circumstance, but it doesn’t.” Time to investigate.

While my two coworkers are hashing out exactly what could have happened, why, and how to fix it, I start thinking to myself, “There should be unit tests to catch this. This shouldn’t have happened. I’ll just go find the test suite and write a couple new tests to ensure the icon properly displays based on the criteria of the data.”

Sounds easy, right?

As I started digging through the specific class code and examining the unit tests, I notice that there are no unit tests for this functionality. That seems suspicious. Then I notice something else: there’s no code. All that exists is a method call to a service that returns a datatable.

As Alice did, I decided to drop through the rabbit hole and see what’s up.

When I get to the bottom I see a gigantic SQL statement – several hundred lines long. It is embedded in the application, deep down in the data access layer, complete with multiple sub-selects and even an SQL case statement! It’s got multiple parameters in the where clause. It’s the kind of thing that makes SQL admins all warm and fuzzy inside, I’m sure. The whole thing is then handed off to our OR/M, which returns a simple datatable. While it is not a stored procedure, it might as well have been – it only has one step remaining on the cliff before it jumps right off into the database.

And the killer is, it’s untestable.

The caveat here is that this particular stored procedure was written as a performance gain, because the nature of the data requested is complex in its selection. But still, I’m of the belief that there might be a better way to query the data than one giant stored procedure.

Because the minute you put business logic in a stored procedure you compromise the quality of your application. You introduce the capability for your team to make mistakes that are no longer easily caught by a regression suite of unit tests. More importantly, I think, is that you increase the probability of repeated bugs. And to me, repeated bugs are a cardinal sin of programming. Nothing makes a development team look dumber than fixing a bug only to have it crop up again, and again, and again. It makes the software look bad, and by proxy it makes the developers look incompetent.

Bob, lamenting the continued bloated nature of Windows OS, writes:

Personally I think they should clean house on the OS side, put the development tools in maintenance mode for a couple of years, and put Scott Guthrie and the rest of those geniuses behind Visual Studio to work on building a new OS from scratch.

This is something I’ve been saying for years. Windows needs to be rewritten from scratch. Start over, and let the guiding principal be: Simple Is Better.

Windows has become so big and bloated that it can’t do the basics anymore. I mean, really – what do you need your OS to do? I know what I want my OS to do: run my apps. That’s it; it’s that simple. Manage my files, memory and processes so I can run my apps. And even Windows can’t get that right.

Have you tried working with Explorer lately? Copying large files? Over a network? When was the last time you tried to kill a process in Windows? Guess what? It’s still easier and more reliable to kill a process in Unix/Linux than it is in Windows. Why is that?

As Riply said, “I say we take off, and nuke the site from orbit. It’s the only way to be sure.”

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.