Alieniloquent

I’m trying to blog more, so here’s an update on the house. We got a counter-offer last night and had negotiated to an agreement we all liked by 1100 this morning. By noon they had signed it and I had signed it and it was all locked in. We got them to agree to sell us the washer, drier, and some furniture we liked (on top of the other appliances they were already planning to sell us). It’s so exciting. Now all the real work begins (including the cashflow management to make sure we have the money to pay things when we need to up until closing).

We put the closing date at September 15th, so we should have two weeks to move in after we close. We’ll be moving during school, but it’ll be before it gets cold. Altogether, a good deal, I think.

I’m so stoked.

So Brian and I are refactoring some code. One of the things we want to do is get rid of a property that exposes an implemenation-specific detail and replace it with a boolean method that made the single check that those details were used for. Naturally, this is in code well-covered with tests (well covered, thank goodness), and they let us know right away when we made a stupid mistake.

Before our refactor:

After our refactor:

That is a perfectly valid test…syntactically. However it results in the following error message:

Now, those error messages are there for a reason: for us to ignore them. Brian and I spent at least five minutes scratching our head and stepping through the test before we noticed the Equals. Sure enough, had we bothered to read the message, it would’ve been only 30 seconds to our green bar.

A link to an article titled, “Agile Programming: How to doom your software project” by Steve Friedl was pasted into my IM window this evening. Steve wrote an excellent piece about being a consultant back in January, and I enjoyed it quite thoroughly.

Seeing as I work in an agile shop, I was drawn to the title of this article like a moth to a flame. It seems that Steve found the agile manifesto, and misunderstood each line item. Now, it’s really not his fault. The manifesto could use a companion document that explains it, or perhaps it should be rewritten such that it elaborates. But, the end result was that Steve came away thinking that all of us agile guys have had a bunch of kool-aid and are about to plunge our companies into deep pits of failure with these kooky ideas. This just isn’t true (well, except the kool-aid, but I mean, that talking pitcher is just so charismatic, I have to drink from its head). So I am here to explain the four points and hopefully allay any misconceptions you might have about them.

“[We value] individuals and interactions over processes and tools”

Steve seems to interpret this to mean that agile practitioners would rather throw people at a problem than find a good tool for it. That is simply not true. Even cursory research into agile practices (including surfing the Agile Alliance, which Steve linked) would reveal a heavy preference toward tool usage. In fact, agile practitioners strive to automate as much as they can so that they can focus on the hard problems.

The idea behind this principle is that our teams should place a higher value on our people than on which tools or processes that we use. The people that comprise a team are the most expensive, and most valuable resources that the business will put into producing software, and so it is important that they are valued. Individuals should be given the power to get things done the best way that they can. They should be given a license to be creative and innovate.

The people on a software team are the most important part. If the tools are getting in the way, then they need to be replaced. If the process is slowing things down, then it needs to be revised. Tools and processes are a means for the people on the team to get to and end. Each engineer should be able to get to those ends by the best, most efficient way they can.

Steve also says that in his experience, “a lot more projects have been sunk by not-enough-tools than by not-enough-interaction.” I’d wager that when he thinks of interaction, he thinks of meetings that last hours–nearly useless meetings that mostly serve to bore all those in attendance. That is, indeed, not going to help a project succeed. Thankfully, that’s not what agile practioners mean.

Agile practioners realize that developing software is not a technical business, at its core. It is a social business. It is about providing people a way to do something that they couldn’t do before. It is about making things easier for people to do. It is about enabling people to interact with technology.

At its core, software is all about individuals and interactions. Whether its a user interacting with his computer, a salesperson interacting with her client, a programmer interacting with his customer, or a programmer interacting with the code, software is all about individuals and interactions. Agile practitioners realize this and strive to make the interactions efficient and enjoyable so that the individuals can do more and enjoy themselves.

“[We value] working software over comprehensive documentation”

This is an easy one to misunderstand, and maybe Steve didn’t. There are two schools of thought when it comes to specifications: they are either redundant information that is duplicated in the code, or they are essential tools to communicating what the software is supposed to do. Whether or not Steve understood the manifesto, he clearly adheres to the latter school.

Agile practitioners realized that they were writing documentation that described how the program was supposed to behave and then they were writing code that described how the program was supposed to behave. Yes, you read that correctly. That is all code is: a description of how the program is supposed to behave. It’s expressed in very precise terms with very specific grammar, but it is a description of the program’s behaviour nonetheless.

What’s more, because we’re writing everything down twice (or more, depending on your process), there are two (or more) places that have to change if those behaviours have to change. And, unless you’ve got some magic voo-doo that I don’t know about, there’s nothing that forces you to keep your documentation in sync (even the best literate code tools don’t care if your documentation comments are out of sync with the real behavior).

The solution is to make your specification out of code. Write tests using technical-facing tools like these and write tests using business-facing tools like this. Use these tests to specify exactly what the behavior is: if the tests pass, the program works. What’s more, these tests actually use the code and inspect its behavior. So, if its behavior changes, the tests will know automatically. Furthermore, the tests serve as examples of how to use the code. With tests like these, you don’t really need a specification document anymore.

We all know that we should strive to remove duplication from our code. That’s why we refactor and that’s why we design. Agile practitioners strive to remove duplication from our processes as well. The less we duplicate information, the more efficiently we can change and the more quality those changes will have. This is what we mean when we say we value working software over comprehensive documentation.

“[We value] customer collaboration over contract negotiation.”

Steve’s right. Customers never know what they want. What he’s wrong about is that negotiating a contract up-front is the way to find out what they want. The truth is that the only way for a customer to find out what they want, and more importantly what they need, is to use the software. This is why agile teams place such a high priority on delivering working software quickly.

What’s more, agile teams tend to deliver their software in small increments and put in the features that are the absolutely most important first. I bet that if you asked a customer to come up with the list of features that would have to be in the product to make it have any business value at all, they wouldn’t have a hard time (”a text editor must be able to display text files, change text, and save text files”). Once you have this super-simple, barely valuable product in the customer’s hands they can give you good feedback as to what should go in next. Working this way, the customer gets exactly what they need and they get it as quickly as they can. It also allows their understanding of what they need to grow while they have a working program.

Give me a customer who wouldn’t want to have a working program that delivers business value after two or three weeks, and I’ll eat the paper you printed this out on (assuming, of course, you printed this out).

“[We value] responding to change over following a plan”

Steve returns once again to software specifications. We know what agile practitioners think of duplicating data, but that is all about documenting what the software does. How are we supposed to decide how to get from now to a time when it does these things? We plan. But built into that plan is the expectation of change.

Agile methods build in the assumption that change will happen and it will happen often. So Steve’s sentiment that “hopefully one has built a [software] system that tolerates change,” is reduced to “one built a software system that tolerates change.” Assume that there will be technical changes and ensure that your software is easy to change by keeping it well factored and easy to understand. Assume that there will be business changes so deliver software in short cycles.

Agile software development is all about embracing change and expecting it. As the old adage goes: the only constant thing in software is change. Learn it, love it, live it.

I’m certainly not the first person to say these things, and I probably won’t be the last. I hope reading this has shed a little light on what that manifesto really means, but the best way is to get out there and do it. Try an agile method on a project and see how you like it. If it works for you, great. If it doesn’t work for you, great, now you know. Sitting around and speculating gets you nowhere.

You might be wondering what happened to steps one and two. Step one is: decide you want to buy a house and learn some things about it. We already did that, and I didn’t muster the gumption to blog about it. Step two is: look at houses and find one you really like. We just did that this last week, and once again, I’m a lazy bum and didn’t blog about it. So that brings us to the step that we just completed and that I am blogging about.

We went to look at our house again (a very cute, two story house in Benson) today with Nate and Erica’s Mom. They both loved it. So do we. So, we went over to our realtor’s office right away and signed our life away initial offer. We should hear back on the offer by tomorrow around 1700, and we’ll take it from there.

Exciting times these are.

So for the last week and a half I’ve had this cough, and it just won’t go away. I haven’t had any sinus problems, and I really haven’t had any breathing problems. I just cough a lot. Most of the time I don’t cough up anything. Monday I went to the doctor.

The doctor looked me over, and listened to me breath with the stethoscope. Then, he told me, “well, son, you’ve got a cough.” Thanks, tell me something I didn’t know. His diagnosis was that I had some sort of viral irritation in my throat (which, as everybody knows, is where the coughing reflex lives) and that there wasn’t a whole lot we could do about it. He prescribed some anti-inflammatory drug for me to take in the morning and suggested I take some Tussin DM in the evening (”You’ll have to take a whole slug, though–3 teaspoons at least”).

The drugs are helping. The cough isn’t as bothersome now. But, hoo boy, I can’t wait for it to actually be gone.

Well, I got a call from State Farm and the little accident I had, will indeed total out my poor little Rio. I’m getting the full retail value for the vehicle, and thankfully I have gap insurance for my car loan, as I don’t think that will entirely cover the amount I owe.

Next month I’ll be shopping for a new vehicle. If I can find a pickup that I can afford, I think I’ll go with that. I want the ability to move things around.

I’ve posted about this in the past (although, the posts aren’t around any more). I’ve always thought that DST was just silly, but apparently I’m in the minority, as Congress has just passed a bill to extend DST by four weeks.

Yay! Let’s give the people more of a stupid thing. Of all the great ideas Ben Franklin had, why, why, why did anybody listen to this one?

I’m never the first person to work. There’s always somebody here before me. Even when I get in early there’s somebody here already. Until today.

How do I know I was the first person in the office? As soon as I stepped in I heard the klaxon of the alarm go off down the hall. You see, the first person that comes into the office in the morning has to disable the alarm. Since I’m never the first person (until now), I figured it had already been disabled.

That was just tons of fun.

So I bought went to Borders Saturday to buy the latest Harry Potter, and discovered that I should have reserved a copy ahead of time. They weren’t going to sell the normal edition to me until Monday. However, I could purchase the deluxe edition, and still read it over the weekend. After consulting with Erica, I decided to go for it.

And then I read. All day. Until 0300 Sunday morning. But, I finished it. It was good. I can’t wait for book seven (although, it’s not like I have a choice in the whole waiting deal). I’ll post more about the book later, but for now, just know it was good.

Here is a gallery of the pictures Erica took of my car accident