Battlestar Galactica and Developing Software

For Christmas this year, my wife got me some really cool gifts. And a few days ago, I read an article that Joel linked to in his Dreaming in Code article. It got me to thinking, especially Joel's Yiddish to English analogy.

The two books, in particular, were very good. The meat of the books focuses on the creation and inspiration for the episodes, including the starting concepts (the episode Scar was initially just an idea: "the Red Baron episode") and their evolution into what I saw when I plunked my butt down on the couch with my wife and friends every Friday night.

There seemed to be a lot of vague ideas that went from brainstorming sessions, to screenwriters, to the producers, back to the screenwriters, to the producers, back to the screenwriters, to the producers, the director, back to the screenwriters (yes, I am repeating myself on purpose), and so on. And once a script was written, the actors would do take after take until the director was satisfied.

It got me to thinking about how many teams approach software specifications, estimates, and that oh-so-fuzzy factor I like to call "Client Satisfaction." This client can be the general public (if you do shrinkwrap software), the big multinational corporation that's going to send your consulting business into the stratosphere, or your professor grading your midterm project.

You start with an idea: We need an "inventory system." If you're like some custom-software consultants, at this point you send a fleet of analysts that "speak customer" to try to figure out how to translate "inventory system" into a 200-page specifications document.

Then, the document goes to the developers to estimate, of if you don't want to use that word as a verb, to give an estimate. Read that last word again. Estimate. Dictionary.com defines estimate as:

to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately

or

a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work

Notice the key word in both definitions: approximate. We all know what that means (as I'm sure you knew what estimate meant, but I'm trying to illustrate something, so bear with me.)

Approximate. Why is it that an approximation in many software shops is treated like a prediction from Nostradamus, and not more like a "I hope it takes this long, but maybe not." If you're someone in charge of scheduling, please don't divide this by some number (usually 8, which is wrong), figure out which day of the week that falls on, and sign a contract with a client gauranteeing that it'll be done on that day. You'll be sorry.

In the past, I've been tasked with estimating very large pieces of software. There's been some with very well-written specification documents, and most of what has been asked of me is not difficult, at first glance. There's been others where it was just an idea.

Usually, when it comes down to giving the final "magic number" of hours, it's not that that number is balked at. It's that several times, scheduling based solely on that number of hours usually results in missed deadlines, frazzled developers, and perhaps most importantly, unsatisfied customers.

Why unsatisfied customers? In my experience, when I've developed larger applications, with a traditional BDUF pattern, the customer won't see a product until about 75% of development is done. By then, they've probably formed some more concrete ideas in their heads of what they want, and since they're (most likely) not developers, it may not be what you give them.

What does this have to do with TV? Many of the roles are analogous. Actors are developers - their performance can be thought of as the actual computer. Screenwriters function as a business analyst. The director is the client. (You could argue they're QA, and the client is the viewer. But it's my blog, so I'm making the analogies.)

There's lots and lots of revisions in this process. The client gets immediate feedback from the program's output, and if he doesn't like it, he asks the developer to try again, "with feeling."

This is something that many need to realize about developing software. The client has a fuzzy idea about what it is they want, and it's hard to nail that down in "specifications documents" or "business requirements." I'm not advocating throwing these documents out the window - well-written specs are invaluable to have. They need to evolve with feedback from the client - and it needs to be sooner, rather than later. And you better schedule that in too - because no client is ever satisfied with the first draft.

That's why good actors are paid lots of money - they start to instinctively know what it is their client wants and can give it to them with the least amount of iterations. I think that people who serve this role in the development world, like free electrons, or business analysts that are "good at dealing with people, can't you understand that?" are who you want on your team. They can get the satisfaction up high with the fewest iterations. They grok what the customer really wants.

So, remember this: clients don't know exactly what they want. They have an idea. Help them shape and mold that idea until they look at you give them and say "YES! That's what I've been after." Be sure to build that into your schedule too.

It would be nice if we could have a "satisfaction requirements" document, though. That's definitely the answer.

Subversion Conversion, concluded

Woo! More than a month without posting.

Now that that's out of the way, let's get down to business.

Previously, I covered Subversion and Apache. While this was working great, what I really wanted in the end was to get https (http + SSL) working as a transport for the repository, so that remote developers wouldn't have to connect over VPN to access it.

Well, I failed. I looked and looked, and there's a lot of great tutorials out there, but none seem to work. It may be an issue with our setup (we are getting "This method not supported by your operating system" or somesuch, I'll check it tomorrow at work). We're using Windows Server 2003 R2, which isn't much different from 2003 Original (at least, not that I'm aware of) and I think I'll have to break down and compile the httpd from source, with mod_ssl.so as well. Not something I'm looking forward to.

But, it's working great otherwise. A huge project takes no time at all to Update/Commit, or pull down for new developers. Everyone using it agrees - it's definitely helping us get our work done faster.

Speaking of new developers - we're hiring. Be sure to drop us a line - and tell 'em Nic sent ya.

The Subversion Conversion

If you've ever looked for a blog on software development, you've undoubtedly stopped off at Joel Spolsky's little corner of the inter-web. And if you have, then you've probably read The Joel Test. That first item on it - "Do you use source control?" is something I'd like to talk about over the next few weeks.

If you use Visual Studio, you've at least heard of SourceSafe. Heck, you've probably used it, or are using it right now. Would everyone reading please raise their hand if they really, really like SourceSafe? Do you feel warm and fuzzy inside knowing your code is "protected" inside of SourceSafe? Anyone?

No? Me either.

So, what do you do? You can either live with it (not a good idea) or you can change it. Now, in an ideal world, you'd be able to either convince your boss/CFO/purchasing department to whip out the credit card and buy everyone Team System. Try it. If they react the same way most would (and to be fair, it is approximately 1 hojillion dollars per developer) then you've got to find something cheaper. Or, dare we hope, free.

Enter Subversion. It's open-source and free-as-in-speech, and best of all, some of the CVS developers that got tired of it work on Subversion. So you know they've got some background on the subject.

"But Nic", I hear you say, "isn't getting this running for a group of developers who are familiar with SourceSafe and doing things Their Way going to be a pain?"

Yes, probably. But, instead of dealing with quirks and worrying about database corruption and that offsite developer whining about how slow it is, my company decided to take a more pro-active approach. I'm a firm believer in Getting Things Done. And if I have to "deal" with my source control system, I'm not Getting Things Done.

So, go ahead and download the latest copy for your environment from here. And if you're using Windows, and if someone tells you that you must have Apache installed before you can use Subversion, they are either a LIAR, or simply confused. You only need Apache if you're going to be doing http/https-based access or want to do some fancy authentication (like Windows Domain). For testing on your local machine, you don't need it.

If you're a Windows user, definitely get TortoiseSVN. It's a Explorer Shell Extension that encapsulates just about everything you'd do with the command-line version into that pretty GUI that we Windows users need. If you're using Visual Studio, then you should also pick up AnkhSVN. It's a plug-in that will enable SVN commits/updates from within Visual Studio, and it knows not to check in your compiled DLL's, or the SUO files.

From my testing, I've found it best if you have all of the projects within a solution in the same working directory. This will probably not be the way that Visual Studio is doing things for you - it defaults to putting ASP.NET websites in one directory, and everything else in another. For both Subversion's sake, and your own, keep everything in the same directory. Cassini can run a website wherever you put it. If you're still building .NET 1.1 websites, you can also setup IIS to have a website wherever your working directory is, and the applications should get created automatically when you pull them down, or when you create new ones. I'm still experimenting with this, so please leave me some feedback if you have any insight on this.

If you're serious about taking this plunge, then I highly recommend you first go pick up Pragmatic Version Control: Using Subversion. It's short, and has a great overview of what someone who likes to Get Things Done should be doing with their source control system. It says version 1.3 on the cover, and 1.4 is the latest version as of this post. Nothing significant from a user's perspective has really changed, it's a lot of internal improvements, API changes, and some administrative enhancements.

Now, as far as a company-wide conversion, we haven't taken that plunge yet. But, we will. We need to figure out some best practices, repository structure/locations, and the general process first. So, stay tuned. We're in this together.