Wow, that was exhausting.

I just took two weeks of courses from the folks at NetObjectives concerning agile development. It was very thought-provoking. There was too much to go over in a single blog post, but I can tell you what I got out of it most was not the course material itself (much of which I already knew). But rather, the shared vocabulary and tips on how to show others how to adopt these practices.

That's really why these methods fail to gain traction. One or two guys learn them, but they can't get anyone else to play ball, so they give up. But these courses really help give you better ideas for how to get better practices more firmly established in your organization.

I don't know how it will go in the long run, but let's see what happens.

By the way, Scott Bain (one of the partners of NetObjectives) is an amazing speaker and teacher. He can even make irrelevant anecdotes seem relevant, and he can talk about his successes without sounding arrogant. Good guy.

Ban the drop-down.

A drop-down control on your website tells me two very bad things about your mindset.

Let's use an address entry section of an order form as an example. Using a drop-down for state is nearly universal. Here are two very bad things:

1. You think I am so stupid that I don't know what the hell state I am in--that I need a reminder or can't remember how to spell it. Or worse--the two-digit postal abbreviation.

2. Your business logic is so stupid that you don't know how to deal with people who really ARE that stupid or make a simple error (for instance, I might type "Wahsington" because I'm in a hurry).

Either may be true or both. It doesn't matter--it's a horrid thing, because I'm sitting here typing-and-tabbing from field to field. And now you want my state code, and you make me choose from a list of fifty-one OR MORE items.

Rethink how you do this, people. There are two very easy-to-do things in this day and age and one not-so-easy to do thing:

1. Dispense with state entry altogether. Ask for city and postal code. Ask for country as well, if your application is used by people outside the USA. This has the benefit of automatically telling you what state they are in. As well, it is easy to localize, as EVERY COUNTRY'S postal system assigns different codes for areas in two different subnational units, no matter how close together the areas are. That is to say, you can tell Kansas City, KS from Kansas City, MO by the postal code.

The data you need for this with respect to American addresses is freely available from both the Census Bureau and USPS. In Canada, both are available from Canada Post and Statistics Canada. They put this stuff on their websites in reasonably-accessible formats for you to download. USE IT.

BY THE WAY, if you have them enter their country--FOR THE LOVE OF GOD DO IT THE SAME WAY. While searching for through a list of 51 states is annoying, searching through a list of 220 countries is REALLY ANNOYING.

2. There are "did-you-mean" libraries available for every mainstream web programming language--Java, Python, Ruby, Perl, and PHP. Perfectly OK to present an error message in some way saying "hey, did you mean...Washington instead of Wahsington?"

3. Now for the not-so-easy to do thing: Allow someone to type a free-form address in one field. Be bold, Google Maps does it. This could require some effort and/or use of a third-party address validation service (Google might be willing to let you borrow their code via a web service in fact). People actually LIKE this interface, especially from mobile devices. Consider using it.

This is 2009, people. Let's get with the program.

OK, so I'm bragging.

I'm not sure whether to be thrilled or worried by the fact that I just wrote 1000 lines of unit tests and they all compiled and ran and passed the very first time.

Get real!

I've been reading Getting Real, by the 37signals guys. You know, those dudes that inflicted Ruby on Rails upon the world.

The only word I can think of is jejune.

Actually, you gotta hand it to those guys in a backhanded way. Who wouldn't want to get rich with the following business plan?

1. Develop a bunch of silly little toys solving problems that people never realized they had.
2. Spread a bunch of propaganda about "agile" and "less is more" and "worse is better". Wow them that you can throw together toy websites in minutes. But make sure you call them "ready-to-go mature business solutions."
3. Profit.

Not bad. Meanwhile, in the "real" world, where we provide services that people actually need, things aren't quite so simple.

"Extreme." "Agile."

Whoever inflicted these adjectives on us needs to be harshly dealt with. I guess Ron Jeffries is principally to blame for this, yes? Bad boy, Ron, no cookie.

The reason I mention this comes from discussing Scrum with an acquaintance. One of the sacred rules of Scrum is that projects are organized into short periods called sprints (originally 4 weeks, but lots of places seemed to have settled in on 2-week sprints). The deliverables for each sprint are locked in at the beginning, and they cannot be increased. Nor can the dependent requirements for the deliverables (called "stories" in Scrumese) be modified.

If "needs of the business" dictate such a change, then the only alternative is to fail the sprint. The only fair thing to do when a sprint is failed this way is to pretend the sprint never existed when measuring the dev team. However, the stakeholders should get serious demerits from failing sprints this way. Unfortunately, in practice, dev teams get demerited for failed sprints regardless of root cause. A good reason why the world will never be perfect.

The other alternative is, of course, to wait until the end of the current sprint, modify the stories, and issue new deliverables for the next sprint. We like to call that The Right Thing To Do. The only reason you'd fail a sprint instead is if the work is obviated or it's an emergency (it had better be one of those "going concern" types of emergencies, too).

My friend pointed out that this isn't very "agile". Which leads me back to why I made this post. I'm not sure Jeffries intended the word "agile" to connote "bending to every whim of the hornhairs*." But senior managers who drink the Agile Kool-Aid often think that's precisely what it means. Which is why a lot of people are having problems with Scrum.

There's nothing we can do about it now. But if Ron Jeffries comes up with a new flavor of Kool-Aid, I suggest no one let him be in charge of naming it.

* EDIT 9/OCT: Some people expressed confusion over the word "hornhair." It's a reference to the comic-strip Dilbert, by Scott Adams. A recurring character is the unnamed Big Boss. The Big Boss is balding, and his remaining hair suggests horns. Hence, "hornhair." Other people call him the "Pointy-Haired Boss" and therefore might use the word "pointy-hair" or "PHB". Definition: Ineffectual middle management suckup.

How to fail at mentorship.

Some dude at code_poet: "Untested Equals Broken"

Ever work with a software dev this mindbogglingly arrogant? Yes, we all have. I haven't lately, because guys like this tend not to get hired at the last several places I've worked, and my current gig is no exception. Maybe he hides this nonsense in his interviews. Even if so, he wouldn't last long on any team I've been on recently.

Let's review the sins:

1. Unilaterally removing the work of someone else. The time to question this sort of thing is either in a code review or in a cleanup iteration (sprint or whatever you call it). Our "hero" is also probably one of those guys who constantly pressures people to keep their current work checked in so in case a new priority comes up or someone gets sick work doesn't get lost.

Therefore, what probably happened here is that the other dev was working on something in stages and got called away to another emergency, which often happens. He checked in his partial implementation and shifted gears. In the meantime, our "hero" zorched his work for some pointless aesthetic reason. NOT COOL. Unless your goal is to find yourself marginalized. I have to wonder about that in the case of our hero.

Better solution: Check the logs to see who added this code and, I don't know, send them an e-mail asking them what the hell this was about. If this half-implemented code still bugs you, then maybe you can negotiate a solution. Maybe you could just get over your bad self. If you have to, then add something like

// TODO: 7/OCT/2009 Half-implemented. Complete implementation or remove next cleanup sprint.

Or if you need to refactor it for some other reason, well, alerting your team to this plan of yours is probably a great idea so they can go, "er, I'm about to use some of that, be careful." Maybe they could negotiate a solution in this case, as well. Maybe you can gasp write some unit tests yourself, as testing is a shared responsibility and not necessarily the duty of the person offering the functionality.

It's also helpful to use a source-code system that supports shelving so half-implemented stuff stays out of the codebase and gently encouraging people to shelve if they get interrupted.

But, whatever you do, don't go unilaterally stomping on other people's work and then throwing 'tude when questioned.

2. Aphorisms. Methodology fetishists like our hero here love to do this. Aphorisms like "untested code is broken code" are used as substitutes for critical thinking, probably because the users of these aphorisms are too busy feeling elite to think critically about anything. Or they may not even know how--programmers tend to be superlative pattern matchers, which is great for doing their jobs, but not very good for confronting things that actually need disciplined thinking.

Seriously, dude, are you going to tell me we need a unit test for code like this?

public String getName() {
    return name;
}

public String toString() {
    return String.format("%d: %s", getId(), getName());
}

If you say, "yes," you are guilty of aphorism-induced brain addling. Perhaps you've also fallen victim to the "we have 100% unit-test coverage therefore our code is great" meme.

There are many ways to test code. VISUAL INSPECTION IS ONE OF THEM. Unfortunately, it is often a lost art among those who have drunk the Agile/XP Kool-Aid. If code is obvious, it doesn't need a test. If you have doubts, then sure, write a test. If you have doubts about someone else's code, then do them a solid and write the damn test yourself instead of complaining about how non-elite they are.

Not to mention that unit tests are often the wrong thing anyway, because most things go wrong when units talk to each other, and therefore most effort should be put into the integration tests. This is such a contentious and difficult issue that I will discuss it at some other point.

3. Being proud of humiliating your charges. The best way to make friends with and influence junior devs is to identify yourself with their shortcomings and reminisce about how you have screwed up just as much as (or even more than) they have. This will tend to reassure them that software engineering is indeed a hard thing to learn, and even your "leet" self has tons of battle scars. You will buy a lot of cred with your future suggestions if you apply humility and empathy to the situation.

If you revel in humiliating them and displaying smug self-superiority, then they will tend not to come for you for future help. You will suffer because you will no longer be viewed as a mentor, and they will suffer because they will have one fewer avenue for self-improvement. And your team suffers for obvious reasons.

Hat tip: A former co-worker of our hero who would probably nut-punch me if I mentioned her name, but she knows who she is.

Sabbaticals.

Let's start this off by extolling the virtues of just getting the hell away from everything for a while.

I didn't take off an entire year, but I did take a few months off to sort out how I related to this high-tech stuff. Here's a highly ambitious man, Stefan Sagmeister, talking at TEDGlobal about how taking a year off every once in a while helps him out.

Of course, this is not practical for many people. But if you can figure out how to make it practical, I highly recommend it.

Of course, now the rest is over, and I'm heading back into it!

Well, all right. Let's get this party started for real, yo.

I guess my blogging career wasn't ready to start last March. But now that I'm actually excited about working in IT again, maybe I'll start using this thing.

The startup didn't work out for various reasons that I might or might not go into at some point. I'm now working for a web-oriented software company near downtown Seattle. It's not a startup (it's been around for 15 years or so, though it's still pretty small.) This blog will discuss the insights I've had concerning software development in recent years as well as what I'm learning on the job there.

The ground rules:

1. You'll never get to know who it is that I'm working for, since blogging too closely about one's employer is a good way to get fired. Even if you accidentally figure it out, I'll always have plausible deniability. I can't even tell you which industry segment I'm in, though, because that will totally give it away. Hell, even telling you that might give it away.

2. I'm never gonna rag on my co-workers. Though that might make the blog more interesting, my co-workers would probably find out if I were ragging on them, even if I anonymized them. That can't be a good idea. I reserve the right to praise them, though.

3. Any political issues will go in the other blog. That way, I could even use this blog to do some networking or even show fellow employees without aggravating them.