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

Importance of the church web site

As Jordon Cooper was considering a church, he found very little about it. He'd find even less, I suspect, about our church if he looked for it. Quite apart from the generic name "University Baptist Church", the web site domain, www.ubcvbs.org, has been down for months now after I let it expire. When I realized it, I wrote to the registrar (Melbourne IT) asking if they'd drop it so I could get it back, but they told me to wait 76 days after the drop date. Ouch. But I'm sure that period's expired now, and I'd really like to get the site back to get ready for Vacation Bible School, the whole point of the vbs portion of the site. In the meantime, the site is hosted at one of my other web pages, http://fulton.home.insightbb.com/ubc , where I'm sure it gets about a drop of google juice a month, and no incoming links. Most annoying. I wonder what people would google for if they drove by and wanted to know more?

Problems of Software Development 2

I discussed some problems with software development here.

So what can be done? The basic problems I see here are #1: The Deadline, and #2: The Database. The programmers work in a panicky rush to fulfill all the items in the Database before the Deadline. So let's start with the obvious: Get rid of the deadline.

"Say what?" I hear you cry. "We can't just never release the project!" No, I'm not saying that. I'm saying - and this is one of the requirements of agility - release early and release often. Get the application into the hands of the users and let them bang on it. They may not find all the really picky little bugs, but that's OK for 99% of the users who won't ever use that functionality anyway. More importantly, the users are going to find the things like the button on the wrong form that would save each user four clicks if you just moved it. They'll find the missing report that they didn't know they needed until they saw how useful it would be with this application. Get the application out there quick enough to catch those things - and then fix them in the next release! How often? Every two weeks, I hear, is pretty reasonable.

But the objections now come thick and fast. "We don't have the manpower to test all the whole program every two weeks!" "Our users are going to file hundreds of change requests! The developers will be buried!" "How will we ever know when it's done if we don't have the requirements set in stone up front?" I'm not the greatest practitioner of agile methods in the world. But what I have found is that for every objection that someone makes to an agile idea, there's a pretty good response from the agiliots. I'll try to come up with responses to these next time. Oh, and I've even been working on an application! I'll try to get up to date on that as well.

Big visible belly

I love Brian Marick's idea to help him lose weight. I weigh almost exactly what he does, but I'm not as agressive in my goals; I'd like to be around 175 by the end of the year. I'll be comparing my weight to his though!

Problems of Software Development

I'd hazard a guess that most companies develop software in a manner somewhat like this: they come up with a short list of features, break those down into a whole bunch more smaller work units, assigning those to some programmers, and then go back and review the database every so often to see how many of the work units remain to be completed.

Now, for the most part programmers are good people. They're interested in the project; they want to do a good job and make something easy and fun to use. So what goes wrong? Why do most applications ship with glaring bugs and obvious usability issues?

Here's why: Everything starts to revolve around this work unit database. Near the end, emails go out to the programmers saying, "I see you still have six work units left. Will you be able to get all those finished by Friday?" As the project moves forward, additional work units are added for new features or bugs. More emails go out. Eventually the project gets thrown to a tester, who enters dozens more work units. The programmers, faced with a long laundry list of items and a deadline, starts to cut corners. "OK, this item says we need to add a State Last Worked In field to the form. I know we're eventually going to need a Zip Code too, but I don't have time to worry about that; I have 15 more units to finish by Friday!" So the program goes without the zip code field. It goes back to the testers, who look at the list of completed work items; yup, there's the State Last Worked In field, looks good. Nobody's told the testers exactly what the purpose of the application is, so they don't know that a zip code needs to be there. Finally, all the laundry lists are complete, the testers sign off on it, the application ships. And customers look at it, scratch their heads, and say, "Why on earth didn't anyone think to put a zip code on that form?"

So what can be done to break this cycle? Well, the various methodologies that call themselves Agile have some ideas.

Buying some oil tankers

I bought some shares of Nordic American Tanker (NAT) today. I went in looking to put some money into China or maybe Hong Kong in raw materials or transportation, but I really didn't see a whole lot in raw materials that really struck my fancy. NAT is based in Bermuda, which I find really strange; you hear a lot about off-shore tax shelters, and this may be exactly what this is; but I don't see anything wrong with it. It's a public company, and I can buy shares and make a nice dividend return, and that's all that's important to me. So we'll see. As a shareowner they'll be sending me their annual reports in nice printed pages, so maybe once I see those I'll see some disadvantages. In the meantime, maybe I'll ask them to put the current locations of the ships on their website. It'd be just like playing Risk :)

What did we do that worked?

The site "Church Marketing...", well, something or other, asks, "What did you do this weekend that worked? What did you do that didn't work?"

Great questions. Our service wasn't a whole lot different for Easter than it was for other weeks, but all I have to do is look at this week's service to get a mountain of ideas.

Why don't I keep a camera with me every week? We planted a tree in memory of a passed congregant after service. There were some cameras there, at least. I'll hope to get some pictures for the website.

Our service recording/archiving plan needs work. I didn't bring home the cassette tape with me, for copying to CD.

We got some brand new cubbies for the nursery. That should be handy, although volunteers are needed less in the nursery now that we have a paid worker again.

What did you do that worked? What did you do that didn't work?

Church management software part 3: Creeping feature

OK, the very next thing I intend to do is expand the range of the product a little. For months I've been primarily responsible for attendance-taking in the church; collecting the sign-in sheets, checking for visitors, trying to make sure they're followed up with appropriately. So this is an obvious extension piece for this software; a way to track attendance and followups. I'll think some more about the design of this, but it's similar in many ways to what I've already stated - data entry screens, a data store, and reports, so hopefully there will be some opportunities for refactoring here. Also, requirements for security are a lot less stringent - the data that is kept is names, dates, addresses and phone numbers, rather than social security numbers and income. So it's a bit easier to put together.

So right now, we're looking at three main pieces of the application: benevolence; attendance; and updating (wonder if I can come up with a word that means "updating" that ends in "ence", that would be cool). For ease of updates, we'll split these out into several assemblies:

1. A stub. This will be the launcher application. It will be very simple and hopefully will allow us to update the other pieces very simply.
2. A Benevolence assembly.
3. An Attendance assembly.
4. An Updates assembly.
5. A Persistence assembly. This will handle the interface to the data store. Now I really need another word for "Updateance"!

Next step: We'll throw a few screens together and see how they look.

Politics of choosing the next Pope

I still don't get Technorati

Poking around for information on this project, I did a Technorati search for "Church Software". This blog came up, updated 2 hours ago:

Reality Distortions: The Beginning

Very nice. Seems like an interesting guy. But this post was done four days ago. Why does technorati say it was two hours ago? Was there a format update? I don't get it. DLux, drop me a note if you want to talk about software for churches though :)

Church management software Part 2: Inherent requirements

So now we have a basic goal for the application; we have a vague idea what the users are going to want to do with it; the next question is, what are users never going to think about but are going to complain about if it is not present? Here's a few of those things.

#1: Security. We're talking about entering some very private information into a database here; not only are we talking about requests for charity, but personal data like social security numbers will be a likely requirement. Right now, the list of people to whom this information is available consists of: (a) the pastor, and (b) the deacons, and the file is kept locked in the pastor's office. So, while the ideal design would be a distributed one, keeping an online database behind a firewall and accessing it through a web service, I don't feel like I can guarantee the necessary security; even if I could talk all the users into keeping a nice strong password. So, for the initial pass, the data will be kept in local files on the computer. Presumably, when it is actually deployed, it will run on a single password-protected computer. I have some thoughts about using Windows Users and Groups to handle Role issues.

#2: Integrity. An important requirement for a church, huh? But specifically, I mean that the data shouldn't be corrupted; or at a minimum, regular backups should be arranged. The target audience for this project is a small church, and it's a pretty good bet that they won't be doing nightly tape backups of their systems. So at a minimum, regular backups should be done like Microsoft Word does, every minute or so; but ideally there would be a way to automatically back up to a different machine.

#3. Updatability. This is an agile requirement, really. I want to make the software very easy to update so that users will be encouraged to use the latest software at all times. This is a huge benefit for software developers. There's nothing worse than trying to figure out an issue based on a user who's running code from two releases, three service packs, and a hotfix ago. If people come to me for support, my first question will be, "Are you running the latest code? No? Update, and call me back if it's still happening."

Another agile requirement is that you avoid overdesigning the aplication. So, it's past time to write some code. One concept that really appeals to me is "Release 0". That's where you get an application out there that doesn't do anything at all except know how to update itself. Let's see if we can do that next.