Weekend family reunion

We drove from Bloomington to Penn State this weekend. I took Friday off work and drove two hours to my dad's house, piled into his van and drove four hours to Cleveland, picked up his sister and drove four hours to my cousin's house. Sort of a college road trip, with less beer and more three-year-old. But it was a good time, and there was a pretty good turnout for the "Descendants of Jesse Fulton". That's my grandfather who died a few years ago. If he'd been there, he would have seen all three of his kids, four grandkids, and four great-grandkids. Maybe he was there in spirit.

With all the driving, we didn't really have much time to visit. But we wandered around campus, and discovered that the reason there were no hotels was the big high school volleyball tournament that was going on. My brother is in theory deciding what college he's going to - in reality he'll be going to Indiana - but he gave PSU a thumbs-up as a solid backup choice. He was noncommital, though, as to the part played by all the volleyball players running around in that decision...

Getting Things Done

Mike Stall comments on how not to organize your mail. I recently read David Allen's Getting Things Done, after reading a recommendation for Take Back Your Life by Sally McGhee, visiting the Amazon site, and reading a review that said it was almost the same as GTD. I decided at that point to take the reviewer's advice and go to the original. It was definitely a good read, and I subscribed to the blog. The main thing I took away from the book about email organization was to keep your Inbox empty. The auther recommends creating three folders: Actions, To Read, and Reference. As you go through your Inbox, determine whether you can take care of the message in two minutes; if so, do it. Otherwise, move the message to the To Read folder if it is something you need to look at when you have time; move the message to the Reference folder if it's something you might need to check back with someday; and otherwise move it to the Actions folder.

This is a huge oversimplification of course, and the book recommends a few other tricks. I am deficient in that I don't carry a personal organizer of any kind, for example. But I'm slowly working towards full organization!

ISO 9000 is good

If you use it correctly, ISO 9000 can be a positive thing for your software company. Here's the secret: Observe the procedure, don't dictate it.

There are two ways of looking at software development. Some people like to look at developers as artisans. They spend a lot of time on a single application, but when it's finished, it's like a really high-quality chair - it's really pretty to look at and works really well. Other people look at developers as assembly-line workers. They kick out a piece of software according to spec, and pass it on down the line to the next worker to glue in. This software is like a chair you can get at Wal-Mart - cheap and quick and does the job.

The truth, as is so often the case, lies in between, but there are a couple of undeniable facts: Not every software developer is an artisan that can make a really great chair. And even if they were, once the original developer moves on to something else, who knows what uses his chair will be put to? So whether or not software is craftmanship or assembly work, procedures are probably going to be necessary for making changes. And in the software world, if you're not making changes, you're dead.

The true raison d'etre for ISO 9000 is that processes can be improved. But you can't improve your process until you know what it is. So observe. Find out what your developers are doing, how they spend their time. (Ask them how it could be better, too. You won't always get a useful answer, but software developers are usually pretty darned opinionated and will have something to say.)

Now you know what your process is, you can document it, and you're most of the way there to your certification. And you'll be even further along once you document how you're going to accept suggestions for improving the process.

Once all that is done, you can change the process. You might see a lot of improvements in front of your nose, right after you write everything down. If your developers tell you they have to get 17 signatures in triplicate before they can issue a fix, you've got room for improvement.

But it all comes down to knowing the procedures. The easiest way to know them is to write them down. And once you have them written down, you're most of the way to your ISO 9000 certification.

OurMedia

This looks to be a really interesting project. They claim that they will archive your digital media forever, basically. Sounds nice, but I registered and took a shot at uploading a few files. What I'm really looking for is an online photo album - just someplace that will store my pictures for me so I don't have to worry about archiving CD's or making sure hard drives are backed up. People who are interested in archiving have to worry about a lot of things like making sure their images are dated, sourced, and described, and I bet quite a few people are doing that and then having a hard drive go south and losing all their work. So before I got onto that part I wanted to be sure I had a good file archiving system, and this site looks like it could be that. What I found was that it was pretty difficult to upload a picture. I uploaded a snapshot of my son and I had to fill in my copyrights, image information, approximate size, resolution, and a lot of stuff like that. It's not a problem for an individual pic, but if I have a couple of hundred it starts to get old fast. The site seemed pretty slow, too, but that might have been my connection. So I guess my next area of research will be image collection formats :) Wonder how they'd deal with a ten-page TIFF if I uploaded it?

Coding principles

* Avoid duplicate code. Anywhere there is duplicate code there is the potential for bugs. Code must always be changed, and anytime you leave the same code in two places, you run the risk of changing it in once place and not in the other, thus introducing a bug. This is the value of Simplicity.

* Don't go too long without soliciting input. You need to get input from users, to make sure that the application is doing the right things. You need to get input from programmers, to make sure your design and architecture doesn't overlook flaws. These are the values of Communication and Feedback.

* Make changes when changes need to be made. Don't fall into the trap of avoiding making changes because "it might break something somewhere." Ideally, of course, you have enough unit tests running to verify that things don't break when you change code, or at least that if they do, you know it quickly. But once the code is so complicated you are afraid to make changes, you can't respond to customer input quickly enough to keep up with your competition. This is the value of Courage.

It's interesting that these principles feed off each other. If your code has Simplicity, you are more likely to have Courage to change, which allows you to respond to Feedback more quickly.

One's virus grammar must be impeccable

Quote from this article in ComputerWorld: "Another recent variant, Sober.M, which surfaced back in April, deliberately used incorrect grammar within the subject line, thereby attempting to convince recipients that the e-mail wasn't a virus and make them more likely to open the infected attachment." Why on earth would people be more likely to assume that viruses have correct grammar? Since I tend to communicate primarily with intelligent people, seeing bad grammar in an email subject automatically makes it suspect in my book. But now I know better. If I ever write a virus, I'll be sure to have this in the body.

Terribly sorry to disturb you, old chap. Here's those jolly enticing pictures I told you about earlier. Just open the attachment and Bob's your uncle. Cheerio for now!

Will that help?

Indy NDA and VS 2005 Beta

Went to the local .Net users group meeting tonight. They showed off some of the new features of VS 2005, including refactoring and unit testing - two of my particular interests, of course. I think if they become generally adopted I'll have to find some new cause to evangelize :)

The main thing that occurred to me during the presentation was how similar the refactoring support looked to Resharper, and how similar the testing stuff was to NUnit. I hope one or both of these companies is getting a cut. (I asked the presenter to compare VS and NUnit but he wasn't familiar enough with it to say.) The refactoring support for VB was pretty jazzy, though. They're also bringing back Edit and Continue, which everyone was grumpy about being left out of earlier versions. It's just one more tool to help people write bad code, IMO. Much better to write well-tested classes instead of changing a couple of lines on the fly for each run.

Another presenter showed off Master Page support for ASP.Net 2.0, which did look pretty nice. I'm still behind in the Web world, but luckily I wasn't one of the six people tonight who went home with no door prize - I picked up a new book on XHTML and CSS. Worlds enough and time!

Vacation Bible School

VBS is coming up quick! My responsibilities are getting things written and printed, and handling the closing ceremony. I've written up a letter to parents and a letter to kids, and a registration sheet. The closing ceremony will be a bit scary; I'm sure I can get a couple of kids to sing, and maybe a couple to read Bible verses. But I'm thinking there's going to be plenty of time to sing some hymns and take an offering and all that good stuff :) So I guess the question is - do I start a separate blog for it? I guess the answer has got to be yes - at the end of VBS I'll shut down the blog and copy all the entries to the church site. That should be fun!

Implementing the Singleton Pattern in C#

Implementing the Singleton Pattern in C#

Nice discussion including threading issues.

ASP.NET

I'm taking the plunge into learning ASP.NET now. I have a couple of minor things I want to do for my first application: allow posting comments on the sermon at my church site, www.universitybaptistonline.org, and read scheduling information in from an XML file. The code for each of these items ought to be pretty simple, but I'm having trouble grasping the relationship between FrontPage, which the site is primarily written with, and ASPX. Like, I have a theme defined for the site in FrontPage, and it isn't being picked up by the ASPX pages. It appears that the only difference is a meta comment, and I added that to the ASPX, but it didn't make a difference as far as I can see. Also, I wonder if you can bounce the ASPX pages around to make the addresses consistent. Like, the page you get scheduling information from is http://www.universitybaptistonline.org/worship_schedule.htm now - note the navigation bar and the yellow styling - but in my .Net project the page would be http://www.universitybaptistonline.org/worshipschedule/webform1.aspx . No navbar, no styling, and an address that's rather more complicated. I suspect it's one of those things you just pick up with experience, and eventually I'll realize either that it's not working because something's wrong, or it's not working because there's no way to make it work. But I'd sure like to know the answer now.

Hitchhiker's Guide to the Galaxy radio show

Available online, very cool. Courtesy of Eric Gunnerson.

Book review: Getting Things Done, David Allen

I spent a few minutes before I started writing digging for the link. Doesn't it seem like anyone who makes a living as a consultant should have a blog? What a great way to get your personality across, and consultants are nothing without personality.

There was a book that came out a while ago about using Outlook as your primary organizing tool. I went to Amazon to read the reviews. Someone said that it was nothing more than "Getting Things Done" with a few tool-specific tricks. I thought at that point I should go read the original rather than the copy. I wasn't disappointed.

I wasn't knocked out of my socks either. It was a good book, and the principals seem straightforward, although to keep using the system sounds like a lot of work. For example, David recommends getting your workstation set up properly with file cabinets and in-boxes; I kept thinking to myself, yep, just as soon as I get a bigger house. But there was some useful stuff. He recommends an indirection from your Inbox, which is where everyone at my company lives, so I tried clearing out the whole Inbox to some alternate folders: "Action Items", "Read and Review", and a few others. I'm not sure how much the system will really help me, but I'm willing to give it a whirl for a while. I suppose I went into the book looking for a tie-in to XP - I figured I'd have my inbox on a set of 3x5 cards that I'd carry around with me. It does seem like you need to have some portable inbox, though, whether it's a Palm or a paper organizer, neither of which I have. Of course, my job requires just about zero travel anyway.

Anyway, my Inbox is empty now, and I have a list of things in my Actions folder, and another list of things in my Tasks, which hopefully I will remember to check every so often. So we'll see how it goes. Maybe it will revolutionize my life. Wouldn't that be nice?

How to lose a web site

Here's some really good advice, with lots of real-life examples, on how not to create a web site.

#1. Don't choose a site that's a random sequence of letters

I was casting around for a web site last year for our church, something I'd never done before. I was doing publicity for Vacation Bible School at the time, so I thought I'd try ubcvbs.org, for University Baptist Church Vacation Bible School. It was available, which is probably not a surprise.

#2. Don't choose the first registrar that you come across

I typed that address into my browser, which of course told me, that address is not available, would you like to buy it? I clicked yes, and was sent to the default MSN registrar, some company in Australia, and they charged me $35 for the site. (Now I know that $8 or $10 is probably more reasonable.)

#3. Don't let the registration expire

When I figured out that I'd overpaid, I thought, Aha! I'll just let the domain expire from this registrar and buy it again later from somebody else. I did that, but found that the Australian company's policy was to keep their domains unavailable for 76 days. So I had to wait that long before I attempted to buy it again. Unfortunately, I got squatted on. Some company in India that specializes in buying domains that might have inbound links snapped it up before I could get to it, and now it advertises gravestones. A particularly ironic fate for a church site, I thought.

So, that site is gone. I bought a new one, http://www.universitybaptistonline.org/, which is a much cooler name anyway. I'll try not to make quite as many mistakes this time.

Narcissism

(As if there was anything more narcissistic than a blog). I've started a web site devoted to people named Ben Fulton. We are quite the creative bunch, including artists, musicians, and writers. And one blogger. I was already aware of most of these people, having Googled my own name before, but I turned up a few new ones, and even found that this blog has made it to the first page of links, which was pretty cool. My home site is titled "Ben and Cathy Fulton" which really drops its rank for this search. (I also found some really strange references , which led me to check Google Groups as well. Ah, some great stuff in the early 90's. I was a laugh a minute.)

Book review: Laws of our Fathers, Scott Turow

There's a certain kind of multi-generational book that appeals to me; the kind where you get to look back across many generations and realize how they all fit together. The grandfather was like this due to oppression and violence; so the father was like that because of his father; so of course the hero has to be just like this because of his family history. This is one of those books, which is a bit surprising, really, since it's a courtroom drama primarily, and that's how we see it from the beginning. But you are bounced back and forth between the heroes as they are today (1995) and how they were 25 years ago as 60's flower children. And while only one parent-child combination are really major players, the ghosts of all of their parents are there, and they carry along the emotional baggage. The judge who is the daughter of the revolutionary; the reporter who is the son of concentration camp survivors; the politician who is the child of a plantation owner.

Maybe the reason I like this sort of book is because of how little I relate. I've done quite a bit of studying of my family history, at least the Fulton and Alspach families, and as far as I can tell they were upstanding and sensible to a man; leading directly to my upstanding and sensible father, and leaving me with no particular emotional baggage, or at least no more than anyone else. We've no horse thieves, we've no child molestors. Maybe we're just really good at concealing it.

But of course we're all blind to our own character flaws. Maybe the rest of the world looks at my family and sees...what? Arrogance? Pomposity? Pretension? It's hard to say. Of course, for the most part no one thinks of anyone else at all, preferring to concentrate on what other people think of them.

Well, but so on the characters go, slaves to their various family pasts. The book twists and turns but holds together somehow, over the course of its 800 pages. I had trouble concentrating on some of the 60's bits, since I had picked it up looking for a courtroom. But worth a read if you have time. Lots of inner-city gang characterizations, so skip it if naughty words disturb you.

Vacation Bible School ramping up

Our VBS has a directorship-by-committee this year, and I'm on it. It's a new thing for all three of us, but we're working together well, so that's a good thing. It seems to be coming together. We've planned just one teacher's meeting prior to VBS, although we anticipate a second, and also a meeting of the non-teacher leaders. We'll arrange a prize package for the kid who brings the most visitors, and we plan on having live animals there for the kids to see as well. Since all of our teachers are pretty experienced, we really hope our opportunities to screw up are limited :) The closing ceremony might be an issue, as our emcee plans to be out of town.

Finishing an agile project

I did a bit of research for this article, after it occurred to me that I really wasn't sure how to answer this objection. How DO you know when the project is done?

Most clients will want to specify the items I gave up front: time, scope, and cost. But specifying all three variables will, almost invariably, lead to overruns, bugs, and dissatisfied customers. Why? Because software is inherently an abstraction. If I want to build a skyscraper, I can get an architect, draw some pictures, do a 3D model. I'll have a pretty good idea of what the concrete implementation of the skyscraper will be before the first shovelful of dirt is ever turned over. But software doesn't work that way. By the time you've put together a decent picture of what the software will look like, you're well on the way down the road and have probably put a pretty nice chunk of change into it. Now, you can try specifying time/scope/cost, maybe even do a good job of implementing it. But chances are if you've done that, you've told the clients you can't make that little change they wanted without changing the contract, updating the design, and of course, charging a lot more money. Now everyone's unhappy. The clients didn't get the change they wanted, so they're not as excited about your product. You're unhappy - or you should be - because you have an unhappy customer and a product that isn't as good as it could be.

So here's the solution: Rather than allowing quality to be the dependent variable, hold it constant and let another variable, say scope, be dependent instead. So now, you've got a contract that says you will work on this project for x number of months, and it will cost y dollars per month, and for that money, the client can choose whatever features they want next at the end of the month. Or, to put it another way, get rid of the deadline.

Whew, I think I'm either going to have to stop this series, or write a book. Next time, I'll finally come back to my church application.

Problems of Software Development 3

One interesting thing I've noticed about Extreme Programming in particular is that any objection you can present to a single practice, usually can be responded to by pointing at one of the other practices.

"We don't have the manpower to test the whole project every two weeks!"

Ah, but you've been writing unit tests all along, right? If your application has a solid set of unit tests, and every one of them pass, then you have a pretty good feeling that even if the new functionality you've added isn't quite right, you've probably not made anything worse for the existing customers. Besides, on big, complicated applications there's usually a process for getting new, isolated fixes out the door long before the next release comes out six months or a year down the road. What these fixes come down to are sort of a "Frequent Iterations" emergency measure - that is, the company doesn't believe in releasing software very often, but the customers insist upon it, so out the door it goes, sometimes whether it's been adequately tested or not.

Finally, automated acceptance tests are a key feature here as well. Unit tests are great, but they work at a deep level of the application. When it comes down to it, the user is going to need to click some buttons and type in some data, and is going to get an expected result. But there's no reason for a person to be doing work that computer is able to do, even if the computer has to move its own mouse and type on its own keyboard.

"Our users are going to file hundreds of change requests! The developers will be buried!"

But you've got a Customer, right?

I think the word Customer in the Extreme Programming sense is really poorly named. Everywhere you read about someone attempting this practice, they say, "Oh, but we don't do that. We have shrink-wrapped software." Or, "We have a dozen customers." This misses the point. Customer, as defined in the XP sense, is required to be a single person, or at the very least a committee. Whether the person speaks for one, a dozen, or 100 million actual customers is beside the point. The customer is responsible for looking at all the change requests, putting them into a neat order, and getting them to the programmers, who will be able to estimate a date based on the highest priority items.

"How will we ever know when it's done if we don't have the requirements set in stone up front?"

But what requirements were set in stone? Generally, they involve three factors; the project's:

• Time allotted
• Budget
• Scope

It neglects the simple fact that a project actually consists of four factors: the three above, plus quality. However, only three of these factors are independent; the fourth one will depend on the others. So, if you specify a project's Time, Scope, and Cost, you have fundamentally specified its Quality as well, and the only way to raise the quality is to lengthen the time, increase the cost, or reduce the scope.

So how do you know when the project is done. I'll look at that next.

Xanga and RSS

This is a friend of mine who has been blogging for a while now, but I haven't found the site until now. Her host, Xanga, does not do an adequate job of providing RSS feeds. Skimming the web provides a whole host of solutions to this. Here are a bunch of links to RSS using various translations:

http://www.xanga.com/rss.aspx?user=amy_gs_reading
http://www.ephemeraleuphoria.com/xanga/rss.php?amy_gs_reading
http://www.joshstaiger.org/XangaRssFixer.pl?user=amy_gs_reading
http://www.mikexstudios.com/labs/XangaRssFixer.php?user=amy_gs_reading
http://www.jasontan.org/xanga/rss.php?users=amy_gs_readings
http://www.acr-web.com/xangafeed.php?friend=amy_gs_readings

How many of these give back RSS that can be read in RSS Bandit? Well, that would be: One (1), the one from MikeXStudios. Thanks to the External Mind for that.

Agile in the trenches

So who does this agile development stuff?

Ron Jeffries. Martin Fowler.

Duh. Who does it that's never met either of those two people? Who's actually doing this down in the trenches to develop real software applications? Most importantly, who's never met these two people, develops real software applications with agility, and has a blog?

Me, I guess. But here's a few others:

http://pab-data.blogspot.com
http://tedogrady.blogspot.com
http://hhroark.blogspot.com/
http://geekswithblogs.net/sbellware
http://theagiledeveloper.com/default.aspx
http://www.undefined.com/ia