Alieniloquent

So, Brian and I are going along writing code that was supposed to be easy. Then we run into a problem. Some of the super secure encryption we do to obfuscate some constants in our code wasn’t working right – in .NET. It worked fine in Win32. So, we put on our spelunking hats and settled into our harnesses and went down into the depths of our code.

What did we find? We found hint H2455. It says “Narrowing given wide string constant lost information.” The helpful help says that if it encounters characters with ASCII values above 127 it may yes, I said may, replace them with a ‘?’. How nice of them.

So we try declaring a typed constant as an AnsiString, but no, why would that work? The string literal is still WideString. We look at the assembly and sure enough, the byte 0x97 is getting replaced with 0x3F: ‘?’.

What did we end up doing? We ditched the string constants. We use an array of Byte and we made a function that will make an AnsiString out of it. As a nice conclusion to this little vignette, that array is prettier to look at.

So my boss walks into the room and slaps a print-out on the wall with some tape. It says:

Gilb’s Law: Anything you need to quantify can be measured in some way that is superior to not measuring at all. – (Tom Gilb)

Kent’s corollary: Any imperfect measurement can be abused during planning and decision-making by assuming a level of precision greater than what the measurement actually delivers.

I previously blogged about Subversion at my workplace. I promised that I would write a blog post about how the conversion went. Many of you may think that I forgot. I didn’t. We just finished it today, and as I expected, I have things to share.

Saturday evening I kicked off vss2svn after installing all the things I needed to run it. I had done this before on a small repository, but it was long enough ago that I didn’t remember exactly what it was like. So I started it, and disconnected from VNC figuring it would take it a while. It did, indeed, take it a while. In fact, it still hadn’t done a single thing when I came in Monday morning. VSS has this need for a username to be specified. It will use your windows login if it’s a valid VSS user, but if it isn’t, the command line tool will prompt for one. The script ate that prompt, so I didn’t see it. That brings me to the first lesson.

Lesson #1: Login to windows as a user with a VSS account.

Monday, having guessed that was the problem, I fixed that by creating a VSS account for the user I was running as. Problem solved. The script ran and it built its database, and it told us what users we needed to have. I put all of those users in my password file and hit enter. Boom! It blew up. It gave some sort of error about not being able to import. After a good deal of time, it was discerned that the script was not properly forming the import command. It’s a good thing I know Perl.

Lesson #2: Download the perl script, not the executable, you will need to hack the source.

Having fixed the script I launched the process. It ran again. This is the point at which I start getting really annoyed at the fact that the script doesn’t pick things up where it left off. We are dealing with a very large codebase here, so it takes a while to analyze. Thank goodness I was running this on the machine where VSS and SVN are served and not over the network.

So it starts going. It converts. It converts some more. We get through two hours and about 1500 revisions when, yes you guessed it, BOOM! It blows up. This time it is asking for a revision of a file that VSS doesn’t have. This is somewhat odd, because you’d think that’s what version control is for: to keep old revisions. Well, you see, Microsoft decided to add a feature to VSS that would allow you to keep all the revision history but only store the most recent version of the file. So, if you analyze the history to figure out commits and then ask for an old revision…you get nothing. Try to add a file that doesn’t exist to Subversion, and you get an error.

Lesson #3: VSS has a lot of retarded [mis]features.

Ruby to the rescue! We write a script to figure out how many of these files exist. We run it. Wow, that’s a lot of files. We look at all of them, and determine that we don’t care about their revision history anyway. So we’ll just “delete” them all from VSS and then re-add them. We’ve got a command line tool. It can perform both operations. Excellent! We’ll just write another Ruby script. If only things were so simple.

Given that it’s Microsoft – the same company that said nobody would need more than 640k of memory – I don’t find it surprising that our script didn’t work. I think somebody said “nobody will ever want to script VSS.” You see, when you “delete” a file from VSS, you don’t actually delete the file. You simply set the file aside in a pile of files that you don’t play with any more, but it’s still there, even though you don’t play anymore. If you try to add a file with the same name in the VSS GUI, it will say “You used to play with this file, would you like to just play with the file you used to have, or would you rather play with this new file instead?” If you try the same thing using ss.exe (the CLI), it simply says “You already have a file with that name, sucker.” Stupid program.

Lesson #4: ss.exe sucks

Once I readded all of those files by hand, and later discovered that ss.exe put them somewhere else that was nowhere near where we asked it to, I kicked off the script again. It ran, and ran, and ran, and ran. Then it ran and ran and ran and ran. We started it Monday afternoon and it finished Wednesday morning. It did, however, convert successfully.

Lesson #5: 1,000,000ish lines of code and 8ish years of history = 2 days to convert

So, today we fixed up our buildscript (which was easyish) and our cruise control, and we got everybody switched over. Our shop is now powered by Subversion.

A year and a half ago, when I started working at my company, one of the first things I saw was the version control they used: Visual Source Safe. My immediate reaction was, “Why don’t we ditch this crap and use a real version control tool like Subversion, or at least CVS.” Unsurprisingly, the response was, “We’d love to ditch this crap, but we can’t afford to right now, and we don’t know what we want to switch to anyway.” So began our journey.

The first task set before us was to decide which version control we wanted to switch to. There was Vault, which would have theoretically been a drop-in replacement. I like Eric, but I don’t like the VSS/Vault paradigm. Another contender was StarTeam, since we’re a Delphi shop, but it is expensive. There were a few other contenders as well, but they all had one thing in common: they cost money. I sat in the corner as this list was assembled and kept piping up, “What about Subversion? It’s fast, it’s fully- featured, and it’s free.” It was added to the list, but not as a serious contender for starters.

Then I bought Pragmatic Version Control Using Subversion, and devoured it. I hadn’t even known how cool Subversion was, and now I really wanted to use it. The first thing I did upon completing the book was give it to the senior engineer in charge of deciding what we were going to move to. He worked his way through the book and agreed with me: it was cool. Finally, Subversion won the Jolt award last year, so it was decided. Needless to say, I was excited.

That was months ago. We were in the middle of a big development push and couldn’t afford the time to port everything over. So, it was decided when we released, we’d switch. Well, that time came and went in late August, and we are still on VSS. We have, however, finally been feeling severe pain about merging and various other activities in version control. So, I finally got the go ahead to start working on it. Today I set up our Subversion server and got it ready for prime time usage (pending blog post about how). Tomorrow I will actually move our source tree into Subversion. Next week, we’ll cut over. I am very excited.

I’ve always set up Subversion and Apache on Unix systems. Heck, aside from work, I generally don’t use Windows. However, at work, it’s all Windows on our production boxes. So, naturally, we needed our version control to run on a Windows box.

I started out reading Brian’s guide to installing everything. Now, I didn’t use his one-click installer, but I followed the rest. Notably, I believe the system account on our server didn’t pay attention to the path I had set system-wide, as it could not load the Subversion modules unless I gave it absolute paths for everything. But I got that working. It was interesting to note that when I had Apache installed, the Subversion installer actually offerred to install and configure the modules for me. I had Subversion access through HTTP.

Since we were going to be keeping our source code in this, I wanted to make sure it was secure. Only authorized people should be able to access the repository. I don’t want to administer a password database, and furthermore nobody wants to remember two passwords, so I wanted to hook into our Windows domain authentication. The way to do this is mod_auth_sspi. I spent about thirty minutes tracking down that module, as apparently the original author no longer publishes it. Furthermore, I could only find the source.

Finding the source was only a third of the battle, though. Getting it built and installed each took another thirty each. The Makefile is not very generic. You have to edit lots of paths to get things to work, and it doesn’t even define $(RC) even though it uses it. But, I finally got it to compile. Then came the adventure of installing it. I copied the module to the right place and added the right line to the config. Apache won’t start. I run it by hand from the command line, and it tells me it can’t find the file, despite it being right there next to all the others it can find just fine. I spent most of thirty minutes googling, and finally realized that it could find my file just fine. It was a DLL that my module loaded it couldn’t find. Namely, msvcr71.dll. I copied that in, and everything worked hunky dory.

My last concern was backing up our repository. Currently we just do a disk backup of our VSS repository. I don’t think we’ve ever had to restore from one of those, and I’m not entirely sure it would work. But, I do know that straight disk copy out of an active Subversion is bad, since it’s database files. So, I go looking about how to back it up. There’s a script that comes in the source tree called hot-backup.py. I installed Python and tried to run it. No luck. It wasn’t written with Windows in mind. I had to spend most of an hour poking and prodding it. It turns out that os.spawnl doesn’t read from the path environment (on purpose) but does not need or want the path to the executable quoted, but os.popen3 does read from the environment and does need and want the path to the executable quoted. Once I got that all figured out, I put it in the scheduler and hopefully it will run tonight during the wee hours backing up my nearly empty repository.

More soon about moving the source over. It’s very exciting.

So I’m working on a website for Erica. She wants some custom coding done and some database goodness, so naturally she asked me to do it.

Being The Ruby Guy, I decided to do it in Rails. I also decided to use MySQL, as it is what I know. Well, I ran into some snags, and I still don’t know what was causing them. Suffice it to say, MySQL was just not working. So, I decided to give PostgreSQL a try.

Now, I’ve always know that PostgreSQL had more features than MySQL. I’ve heard that it’s generally better than MySQL. Yet, I’ve always been afraid to try it. It has been a completely irrational fear, of course, but fear nonetheless. Well, since I found myself needing a different database, I bit the bullet.

It was about damn time. Building PostgreSQL from source was a breeze. I’ve built MySQL from source, and it’s a pain in the ass. Setting up my database was also a breeze. It is also a pain in the ass for MySQL. So PostgreSQL has two counts of not being a a pain in the ass, and MySQL has none.

Then it comes time to think about database users. I’ve always thought it was a little silly that MySQL conflates granting privileges to users with creating users. PostgreSQL doesn’t do that. You create users and then you assign them privileges, as it should be.

The command line shell for PostgreSQL also is easier to explore and learn than the one for MySQL. The built-in help is nice, and the online manual is much easier to read.

So, all told, I have a new favorite database.

I know, I know. It’s been a while since I last blogged (9 days, and longer since it was anything of content). I’ve been busy! Every so often I think to myself “Do I want to blog about what I’m doing, or just do it.” Between work, school, home-ownership, and sleeping…there’s not much time to do all the things I find fun. Sadly, blogging seems to fall to the wayside.

But, I am getting better about sharing with other people. For the third time in two months, I gave a talk about Ruby at a user group meeting here in Omaha. This time it was OJUG, and I gave them Jim Weirich’s OSCON 2005 talk, “10 Things Java Programmers Should Know About Ruby” (yay for creative commons). Well, at least I gave a talk using Jim’s slides, as they were just perfect.

I’ve really enjoyed doing this, so I’m going to put this out there. If you are a group in the Omaha area, and would like to have me come talk about Ruby, shoot me an email. I’m cheap. All I need is some free food, and I’m your man.

Well, we sat down to do some budgeting, and one of the things that got trimmed was our cell-phone service. The timing was very good: our contract just ended last week. So, we no longer have our cell phones. If you had my (or Erica’s) phone number before, just post a comment or send me an email and I’ll let you know what the new number is.

Well, I was going to do it Saturday morning (really early before it got hot). Then I thought, hey I can do it Thursday after I’m done with class but before I go pick up Erica. Then, tonight, I couldn’t wait. I pulled out the lawn- mower that my co-worker has loaned to me and mowed my front lawn. It’s not that big. It’s actually kind of awkwardly shaped due to the large (12-feet in diameter) evergreen tree taking up much of the area.

It was kind of dark by the time I got mowing, but I think I did a fair job. We’ll see tomorrow, I suppose. I’ll be mowing the back tomorrow afternoon.

So I was looking at a C# class that looked something like this:

class FooFactory
{
  private BazCollection _bazzen;
  private QuxCollection _quxxen;

  // ...constructors, other methds, etc...

  public Foo BuildFoo(Bar bar)
  {
    return new Foo(bar, _bazzen, _quxxen.FindQuxForBar(bar));
  }

  // ...more stuff...
}

Now that smells to me. Take a moment and see if you can sniff it out. I’ll wait.

That’s right. We’re passing in bar and then also passing in something that we use bar to get. But that’s not all. I didn’t show it in the snippet, but inside Foo the way we use the BazCollection is also indexed by bar. So, we have this object and sometimes it indexes into a collection and sometimes the objects that construct it index into a collection for it. The responsibilities are muddled. Sometimes a Foo indexes in and sometimes it doesn’t.

The power that objects give us is to wrap up data and the responsibilities associated with that data into a nice little bundle. That power doesn’t do us a lot of good, though, if we don’t actually use it. In a case like this the responsibility of which object should be indexing into the collection is spread onto two objects, and only should be in one.

Now, one refactor that we could do would be to just pass the collection in for the Qux as well:

public Foo BuildFoo(Bar bar)
{
  return new Foo(bar, _bazzen, _quxxen);
}

This refactor is not the one I would choose, though, as now it is even more complicated to construct a Foo. Specifically if I want to test my Foo (which I do, of course). The foo is only ever interested in a single Baz and a single Qux, so it’s just extra overhead to have to create a collection for each. That brings me to the next refactoring that I might try:

public Foo BuildFoo(Bar bar)
{
  return new Foo(bar, _bazzen.FindBazForBar(bar), _quxxen.FindQuxForBar(bar));
}

This has the advantage of making Foo’s responsibility very clear. It is meant to bring the bar, baz, and qux together. But, that call-site still stinks. In fact, it reeks more with that original odor. At this point, it would be worthwhile to see what Foo actually needs the Bar for and further factor that out. Maybe we can have something like this:

public Foo BuildFoo(Bar bar)
{
  return new Foo(bar.name, bar.id, _bazzen.FindBazForBar(bar), _quxxen.FindQuxForBar(bar));
}

That way we remove the dependence on Bar completely from the Foo, and push it into the FooFactory. Maybe we will create an object that encapsulates those parameters. In fact, maybe this factory is that object. But one thing is for sure, this code is better separated and easier to test and use than the original.

Today has been a very long day. To sum it all up, I’ll simply tell you what I’m doing now: blogging from my front porch. That’s right, my front porch. I love wifi. We closed on our house today. We’ve got internet hooked up. Our bed is moved. Our cats are moved. All of our dirty laundry is moved, and being cleaned by means of our new (to us) washer and dryer.

Closing went very smoothly. It went much more smoothly than everybody had led me to expect. I think it’s a big conspiracy amongst homeowners to make new home-buyers feel like they’re going through some big ordeal. Trust me, I know just how big a deal this should be. 3715 pages to sign and 3024 pages to initial and 1207 pages to sign confirming that I initialed the 3024 pages and 237 pages to initial confirming I signed the 3715 pages, that’s hardly any paperwork at all. It went by in less than 45 minutes.

It’s getting late, so, in short: first post from our new house!

I gave a talk about Ruby on Rails at the Omaha Smalltalk User Group tonight. It went rather well. I’ve posted my slides for anybody that would like them.

The talk was mostly focused on the Ruby for Smalltalkers portion, but that was largely because Rails made my demo go so fast that I had to find something to fill the time with. It was kind of fun, actually, showing everybody around the Todo project I had made. I haven’t really done any serious railing since version 0.10, and a lot has changed since then. So it was just as exciting for me to open up some of the files and see how they did things as it was for the rest of the group.

I’ve been so busy lately taking classes and buying a house, so I wasn’t as prepared as I would have liked to be. But, everybody seemed to enjoy the talk and take away something valuable from it, so I’m happy with the talk. I really enjoyed it, and I think I’m going to try and do more things like this.

An astute reader may notice the new category and link in my sidebar. OCFit is a project I’ve been working on for a few weeks (well, really just a couple of weekends over the last few weeks). It is intended to be a replacement for Fit for Cocoa developers. I started it because I could not find the Objective C implementation of Fit, and when I did, I just could not bring myself to use it. I’ve set out to write a program that follows the spirit of Fit, but is idiomatic to Objective C.

Right now the framework only provides PrimitiveFixture and ColumnFixture. I will be implementing ActionFixture soon.

I’ve waited and waited and waited. Now the waiting is finally over. I have in my possession a copy of Mage: the Awakening, and I’m stoked. I would have said something yesterday, when I actually bought it, but I was too busy reading.

Around my office, I’m generally the guy who knows the most about the non- windows and open source worlds. That’s where I come from, and that’s what I stay the most current with. So, when we started looking for a version control system to replace Visual Source Safe, I immediately started selling Subversion. I succeeded.

Today I gave a lunch-time presentation about Subversion to the whole team. It was just a short talk with a brief history and a high-level overview of the features. If you’re interested, you can download the slides.

Over the past two years I’ve hopped around from blogging tool to blogging tool, and many of my blog posts have fallen to the wayside. Pleasantly to my surprise, somebody was backing them up for me. Yay for the Internet Wayback Machine. So, Sherman, it’s time we take a trip back to…May 4, 2004 on this very blog…

With apologies to Frank Herbert:

I must not prematurely optimize. Premature optimization is the mind-killer. Premature optimization is the little-death that brings total obliteration. I will face my desire to prematurely optimize. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the desire has gone there will be nothing. Only I will remain.

Apparently, the folks at VitalSource have used Rails in a client application.

Now that I think of it, with WebKit, it was only a matter of time until this happened.

It’s no secret that the next version of Java will have generics, as will the next version of C#. This is nothing incredibly new. C++ has had templates since the dawn of time and they’ve always made code unreadable and needlessly complex (okay, so I’m a dynamic language nut). It basically amounts to wanting all the neat tricks that dynamic typing gives without any of the programmer niceties (like trusting that the programmer knows what she’s doing).

Over on Blaine Buxton’s blog he posted about Java generics and the recommended naming for the generic types:

A note on naming conventions. We recommend that you use pithy (single character if possible) yet evocative names for formal type parameters. It’s best to avoid lower 3 case characters in those names, making it easy to distinguish formal type parameters from ordinary classes and interfaces. Many container types use E, for element, as in the examples above.

public interface List<E>
{
  void add(E x);
  Iterator<E> iterator();
}

public interface Iterator<E>
{
  E next();
  boolean hasNext();
}

In the comments over on Blaine’s blog, this guy named Issac (who’s mission it appears to be to disagree with everything Blaine says) said:

Everyone knows better than to use single letter names for classes and interfaces - so when we see a single letter name, we can be confident the parameter is not a class or an interface but is a formal type parameter.

Isaac clearly have a very narrow definition of “everyone” or a very narrow sample of code to draw from. I see terrible naming in every language and it makes code harder to read every time. I see the single letter and have to spend the split second saying to myself “E, what a terrible class name, nobody in their right mind would name a class that. Oh, right, that’s the name of the generic class.”

The cognitive dissonance only becomes worse when you want to make a class generic on more than one axis. When you have something like:

public interface Matrix<E, F>
{
  add(E x, F y);
  //... more methods in E and F ...
}

When does it stop? How are we supposed to make “evocative” names when we only have one letter to choose from? Sure, we can take the class name we would’ve used and use the first letter, but then we are limited to only 26 names. It might very well get confusing when we use E to mean Element in one place but use it to mean Enumerator in another.

Now, if I actually give the thing a name, like ElementClass, I can say “Oh, right, that’s the class of whatever element is in here.” Heck, I don’t even need to think that hard, it just reads that way. It may seem like a small win, but it’s a huge win to somebody coming into the code from outside.

A week ago I read this presentation by Wil Shipley (of Omni and Delicious Library fame). It has inspired me. I’m going to write a Cocoa program that does something useful and then sell it.

Cocoa is fantastic. It makes things so easy. The best part is, Apple is always making things easier for developers. One of their latest technologies, Core Data, makes things orders of magnitude easier for developers. I just put together a prototype in under two hours (most of which was poking around documentation since I’m new to using Core Data). I had to write maybe ten lines of code, and that’s because I was doing something a little out of the CD paradigm. That code will probably go away soon.

My application already knows how to serialize its data, with zero lines of code from me telling it how. It knows how to add and remove records from a collection and refresh the UI for it, with zero lines of code. Core Data and Cocoa Bindings are just awesome.

Erica has blogged some pictures of the house we’re buying. Note the porch funiture that we got into the contract!

For those of you who know Omaha, the house is here right outside of downtown Benson.

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:

Assert.Equals(1, object.Detail, "Details don't match")

After our refactor:

Assert.Equals(object.hasDetail(1), "Details don't match")

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

"True" does not equal "Details don't match"

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.

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.

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.

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.

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

So, a couple weeks ago, my friend Joe got in a car accident. Erica and I went and helped him and his wife out that afternoon. Little did we know that the car accident virus was being passed on to us.

I got rear-ended on the way home from work. I was traveling east on 72nd near Dodge (right by where I live) and the traffic was backed up (which it frequently is there). I came to a stop, and the guy behind me thought I was moving. The result? My bumper was bent so far under my car it rubs up against the rear wheel. Not exactly drivable.

Nobody was hurt. The guy was nice. I’m still waiting to talk to his insurance people, but I’m sure things will work out just fine. Not exactly my idea of fun.

The product I work on is big. It has hundreds of thousands of lines of code. There are some objects in that code that are used all over the place. A lot of those objects are actually kept as global instances. This, of course, creates all sorts of problems about data being synchronized and memory being freed. The solution, of course, is to not use global objects.

While not using global objects is the solution to the general problem, it is not easy in the least to make that change. There are hundreds of places where these objects are used and each place is a little different. So, it would be fairly costly to go in and fix them all, and it wouldn’t show any visible business value.

So how does one approach the problem? With baby steps. Each time I am in a piece of code that uses one of these global references, I look at it to see if I could pass in an object as a parameter to the method instead. If I can, then I make that change. I just pass in the global at the call site, so it’s still using the global object. But, now that method has been severed from depending on the global object. If you conscientiously do this as you go through the code, leaving it a little better every time, then eventually those hundreds of references will become a handful. Once you only have a handful of references, you probably don’t need a global any more.

My feeds should be back up and running. An upgrade to the install of WordPress on our server tromped on my .htaccess file, and so my rewrite rules got trashed. They are all up and running again, sorry for the time. I think most people will have missed one post unless they come and read my site by hand.

To those on LiveJournal who may very well get a big flood because of this, I’m sorry. Use a better RSS reader. grin

The product that my company sells is very data intense. The data is stored in a database. Of course, from time to time we have to make schema changes to that database, so we have a program that does this for us.

In previous versions of the software most of this was done in Delphi code. However, now that we run on a database that has good SQL support, we realized we could just run queries to get 99% of what we wanted done. To take this a step further, we could just write a SQL script that does all the work and not have to recompile any code for the schema updater to do the right thing.

[2.1]
ALTER TABLE ...

[2.2]
DROP TABLE ...
CREATE TABLE ...

[2.7]
INSERT INTO ...

You get the idea. The program would then check the database to see if it was on the latest version and it would run any relevant SQL snippets on it in order to bring it up to date. For each section it ran it would increment the version of the data to that version, run the SQL, and move on. Of course, after it runs the last one that brings the data up to the last version. Neato, right? If only it were that simple.

The problem was that our code has a symbolic constant which is [supposed to] always be set to the latest data version. The schema updater assumes that there will always be a section in the SQL script for the latest version and that will match the symbolic constant in the source code. However, if the symbolic constant is incremented but the SQL script is not changed, the data is never brought up to the “latest” version, as the updater only increases the version number for each section in the script.

The “latest” version number is defined in two different places: the script and the constant. The version is set to the value in the script, but validated against the constant. This is the cause for the problem. Now, I am biased toward the script being the One True Source, but in truth it only matters that there is only One True Source.

Either the schema updater should set the database version to the value used by the symbolic constant or it should check it against the last version in the script. That way a single change will drive both pieces of functionality, and they’ll always be in sync.

It’s been over a month since I last posted. There have been a couple of times I’ve considered writing something, but I’ve been to tired or busy to do it. Between work and school I’ve been pretty drained, and what little energy I’ve had left has been directed toward reading and housework.

I just reread all of the Harry Potter books. I, of course, did this in anticipation of the next one which comes out a week from Saturday. It only took me about two weeks to get through all five, and now I’m primed and ready to jump into book six.

The other notable book that I’ve read recently is Ron Jeffries’ book, Extreme Programming Adventures in C#. It is absolutely fantastic. I had glanced over it a number of times at the book store as I don’t normally buy C# books, but when Ron was last out at our shop he offered me a copy from his personal stock, and I couldn’t turn him down (if i’d ever bothered to look close enough at the spine to see he’d written it, I’d’ve already bought it). I have learned a lot from the book, and so has Joe since I made him read it.

I hope to start writing more frequently, but I’m not going to make any promises. Work has been really intense lately (in a good way), and I haven’t been opening up my powerbook much at all when I get home. I’ve got a few weeks before classes start up again, so hopefully I’ll find some time.

So, Erica and I have both been feeling a little constrained in our apartment. It’s a studio apartment, and we have a lot of stuff. Granted, the whole reason we moved into a studio was to force ourselves to get rid of a lot of stuff, and we did. But now we’ve got lots of stuff we want to keep. Not to mention, the apartment is small. So, when our lease is up this fall, we may consider moving.

But, we’ve been renting for five years, and don’t really want to continue. I want a yard that I can grill in without having to drive out to the state park. Erica wants a basement she can setup as a photo studio. And, we’d both like to be secure in the knowledge that we aren’t throwing our money into a black hole every month. So, we are looking into buying a house.

Now, the first step we’re taking in this endeavor is fixing our credit. Or, rather, fixing our credit reports. Our credit isn’t stellar, but at the same time, what the credit bureaus are saying about us isn’t exactly true. As I write this, Erica is making phone calls to creditors that we’ve never heard of before and getting things straightened out.

One thing is for certain, we’re not rushing into this. We’re staying in the apartment until the lease is up, which gives us all summer to shop for houses and financing. I fully intend to look around at least five houses that I won’t buy, if not ten, before I get really serious about buying. With school and all, we’ll have to start looking early.

Stay tuned for more as it comes along.

Tonight was amazing. I was amazing. Well, at least I amazed myself.

Before I tell you what amazed me, let me fill you in on the background. I’ve been stalling on my latest project for a week now because I’ve had a mental roadblock on how to refactor it to a place where I can add the next feature Meg (my Customer) wants. I knew that the code was not in a place to add it, but just could not find the path to salvation.

When I got home from work, I had some time to kill, so I pulled out my powerbook and started refactoring. It was absolutely inspired. I just started extracting little methods. I renamed a class. I renamed some methods on the class. Just a handful of teensy little changes like that and all of the sudden my code made so much more sense. Simply renaming the class and extracting a couple of methods had revealed the design that I’d been looking for.

I went to dinner.

When we got back from dinner I set in to refactor more, and I’ve been refactoring all night. It’s been more of the same: teensy little changes. I’ll rename a method, or move it. I’ve removed three parameters from the constructor of an object that had no real reason to ask for them, and that made my code a lot prettier because I had to fish those parameters down everywhere I constructed the object.

I think that the code is finally in a state that I can add the feature Meg wants, but beyond that, it’s in a much better state than it was this morning.

It’s also worth noting that I’ve been doing this project test first, so I have a safety net under me as I make all these broad changes. I’ve got a good test- bed and that makes all of this possible.

I’ve been gone for quite some time. Well, not gone, but not blogging. The blog has, in fact, been gone.

In short, Arete was hacked. Tyler and I had to reinstall. That is a blog post all on its own. We finally were back up and running with most things about a week and a half ago. But, for whatever reason, Rouhgcut wouldn’t work.

It seems something changed from Rails 0.10 to 0.12 that broke it. So my blog remained down, as I didn’t want to bother fixing it. I’m now using WordPress, and I think I’ll stay with it. While I don’t like PHP, I do like blog software that Just Works and requires Very Little Effort On My Part. Despite all my posturing, writing code for my blog doesn’t excite me very much, and so what language the blogging tool is written in isn’t nearly as important.

I’ll be importing all of my old entries (well the ones that were in roughcut, at least) very soon.