Friday, April 22, 2005
#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.
Thursday, April 21, 2005
Monday, April 18, 2005
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.
Sunday, April 17, 2005
Friday, April 15, 2005
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.
Tuesday, April 12, 2005
"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
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.
Sunday, April 10, 2005
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.
Friday, April 08, 2005
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:
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.
Wednesday, April 06, 2005
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.
Tuesday, April 05, 2005
Sunday, April 03, 2005
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?
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:
- 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.
- A Benevolence assembly.
- An Attendance assembly.
- An Updates assembly.
- 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.
Friday, April 01, 2005
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 :)
#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.