Chris Holmes Online

Scott Fujita, via Peter King:

A lot of people think their vote won’t make a difference, or that their voice will never be heard. But if we all felt that way, then the system would be broken. There’s a lot more good than bad in this country, and the only way to begin to fix what’s bad is to get out and vote. Also, suffrage rights didn’t come without incredible struggle for a lot of people in this country — women and blacks in particular. To me, not voting would be a huge slap in their faces.

I can’t remember ever being so excited for an election day. This could be a landmark day in American history, and we’ll all be present to witness it. Provided, of course, the Republicans don’t cheat their way to victory once again.

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.”

Some folks have asked recently what happened to my blog. Well, it’s pretty simple: On July 14th, 2008, my wife gave birth to our son, Cameron.

A newborn, as anyone with children knows, sucks up some free time. In addition, his big sis, Jessica, is becoming a handful as well.

I also spent some time this summer doing some .NET consulting for a friend. It was a great opportunity to share some knowledge and solve some problems. The consulting also took away some blogging time, but it did help pay for a couple new guitars, because…

In January, I co-founded a hard rock cover band: Day of Rain. When we started the band it was just two of us, a drummer and myself (on guitars). We had both been playing our instruments for 15+ years, but we had never done anything with that skill. Now seemed like the right time to both of us.

I’ve found the band to be a great source of fun and a great outlet for my musicality. Having to learn new material and having to be at my best so I don’t let down my band mates has forced me to practice and really become much more proficient with my instrument.

At the same time, putting together the band has tested our collective patience. The first several months were marked with one failure after another in our attempts to recruit a quality vocalist and bass player. Musicians are weird people, and often they lack in the areas of dependability and professionalism (or they lack in talent, which seems to be the case with so many people who think they can actually sing).

Recently, we did add a vocalist, and she is one of the best singers I’ve ever heard. We’re fortunate to have her. We’re still short a bass player, but our list of known songs is growing each week and we all believe we’ll be gigging next year.

I’m still working at Nez Perce County and still trying to do cool stuff with .NET. We just upgraded to version 3.5 and we’re now able to take advantage of some very cool Linq goodness. I hope to have more to say about that and what we’re doing with it in the weeks to come.

There’s so much to write about, and so little time.

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.