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.
Ramblings of a software developer with a degree in bioinformatics. Agile development mixed with DNA sequencing - what could go wrong?
Friday, April 15, 2005
Tuesday, April 12, 2005
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:
"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.
Sunday, April 10, 2005
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.
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.
Friday, April 08, 2005
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
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.
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
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.
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
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 :)
Sunday, April 03, 2005
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?
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:
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
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 :)
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.
#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.
Thursday, March 31, 2005
Church management software
One thing I'm looking to do is to make this blog a little more technically oriented. My other blog is really an Interactive Intelligence thing - the site is clientcom.blogspot.com, and it's named after the Interactive product ClientCOM; so it really seems most sensible to keep posts to that blog on ClientCOM - tips and tricks for using it, etc. Unfortunately, soon after I started that blog, I stopped focusing on ClientCOM in order to do other things, so it has been dark for quite a while. I'd like this blog to be about some technical work I'm doing, as well as the books and plays I'm currently seeing. (Once again - blog categories. C'mon, Blogger!)
So my church is looking for a better way to handle benevolence requests. These are requests that come in from people who need charity - say, $100 for fuel in the winter, or help with gas to visit a sick mother. I was casting about for things I might do as a Micro-ISV, so I thought I might be able to help out - and perhaps, if it works out well for this one church, be able to sell the application to others as well. That's a bit of a ways off, though.
So I'm tackling this project; more or less on my own as far as the design goes. I don't think my "customers" are going to be too demanding, so I'll have to keep on top of them to make sure that the application is actually useful to them. I'll be creating the design and requirements, etc., myself, so I think this is a good application to use some agile methodologies on. Specifically, this project will have: Test-driven development, frequent iterations, and easy updates.
So what are the requirements? If I ask the pastor, I'll get an easy answer: A way to enter benevolence requests online, without paper forms. A surprising addition, to my mind, is: A way to track down resources that might be able to fulfill a request. What this is, basically, is an algorithm for finding places that will take vouchers for gas; maybe food banks that could help a hungry person, etc. To my mind, these are such different goals that I'll just be ignoring this one, until I get further along in the development. So I'll concentrate first on the paperless form.
So the next question is, as a techie, what requirements do I see that underlie this prime requirement?
So my church is looking for a better way to handle benevolence requests. These are requests that come in from people who need charity - say, $100 for fuel in the winter, or help with gas to visit a sick mother. I was casting about for things I might do as a Micro-ISV, so I thought I might be able to help out - and perhaps, if it works out well for this one church, be able to sell the application to others as well. That's a bit of a ways off, though.
So I'm tackling this project; more or less on my own as far as the design goes. I don't think my "customers" are going to be too demanding, so I'll have to keep on top of them to make sure that the application is actually useful to them. I'll be creating the design and requirements, etc., myself, so I think this is a good application to use some agile methodologies on. Specifically, this project will have: Test-driven development, frequent iterations, and easy updates.
So what are the requirements? If I ask the pastor, I'll get an easy answer: A way to enter benevolence requests online, without paper forms. A surprising addition, to my mind, is: A way to track down resources that might be able to fulfill a request. What this is, basically, is an algorithm for finding places that will take vouchers for gas; maybe food banks that could help a hungry person, etc. To my mind, these are such different goals that I'll just be ignoring this one, until I get further along in the development. So I'll concentrate first on the paperless form.
So the next question is, as a techie, what requirements do I see that underlie this prime requirement?
- A backing store
- Data entry screens
- Reports
Seem to be the minimum. I'll think about how I'll be fulfilling these requirements next time.
Tuesday, March 29, 2005
Writing again
I've been so busy lately that I haven't bothered to write anything. But today I fired up Bandit to catch up a little bit on http://scoble.weblogs.com/, and I remembered what it's all about. It's about keeping in touch. It's about exposing a little bit of yourself to the world. Blogging is an interesting feedback loop. You write something interesting, and people read what you have to say. But if you don't write anything interesting, no one will visit your site; so it's about buzz, it's about attention. There's lots of interesting things going on in the blogosphere, and no one has time to keep up with all of it, but to keep in touch you absolutely have to do one thing: write. I think blogs, along with wikis, are the most important new internet development in years, and I'm trying to figure out where I fit in. I should be writing about work. I should be writing about church. I should be writing about interesting things I find on the internet. I should be writing about Extreme Programming, or C#, or Ultimate Frisbee, or anything I know something about.
There's some similarities between blogging and Extreme Programming, I think. They both rely on a tight and fast feedback loop. They both support rapid and easy change. They stress communication as a core value. And maybe most importantly, they both require a lot of discipline. It's easy to write code, hard to remember to write a test every time I make change. It's easy to start a blog, hard to remember to keep it going and keep it interesting.
So maybe this is my latest attempt to regain the discipline. I'll try to write some interesting things. We'll see if it works :)
There's some similarities between blogging and Extreme Programming, I think. They both rely on a tight and fast feedback loop. They both support rapid and easy change. They stress communication as a core value. And maybe most importantly, they both require a lot of discipline. It's easy to write code, hard to remember to write a test every time I make change. It's easy to start a blog, hard to remember to keep it going and keep it interesting.
So maybe this is my latest attempt to regain the discipline. I'll try to write some interesting things. We'll see if it works :)
Friday, December 03, 2004
Ballet Review: Nutcracker
As a matter of fact, I don't go to a lot of ballets. It's not really that I have any objection to them, but on the whole I tend to prefer opera, or at least a play. But it's definitely one of our holiday traditions now, to swing over to the IU Musical Arts Center and catch Nutcracker when it's here. A couple of years ago a friend told us that we were really lucky to see Julie Kent performing in it, as she was one of the greatest American ballet artists living, and we felt appropriately privileged, but Julie was back again this year, so she must have some kind of special connection with IU and it wasn't a once-in-a-lifetime experience.
Highlights: The Arabian Dance, Mother Ginger, and Damian Woetzel as the Cavalier. I thought his solos were an impressive display of leg strength. He's from the New York City Ballet. His duets with Julie Kent were good too. Mother Ginger is played by the same person (Colin Donnell) every year and he's utterly hilarious, camping up the role and bumping and grinding his 20-foot wide hips. Joshoa Sutton and Angelina Sansone did a very erotic Arabian Dance. They play a snake and a snake charmer, and she spends her time mostly crawling up and down his body. You could just feel the steam coming off them. I mentioned it to my wife, and she said, "Oh, the one two years ago was hotter." Guess I was still too sleep-deprived then.
Lowlights: The Prince didn't quite make it under Father Christmas's robe. You could see him running along behind, and that effect didn't work at all. I've thought the last few years that the magician (Theodore Keener) kind of gets short shrift. You can see the intent in what they're doing, to make him look mysterious and magical, but the timing always seems to be just far enough off that you don't get the impression of a puppetmaster pulling the strings of the other characters that they're going for. We thought the choreography in the Dance of the Snowflakes was slightly off.
In general: Fritz (Justin Zuschlag) was very effective, hassling the girls, swordfighting the magician, and sticking his tongue out at him when he thought he could get away with it. I wasn't that excited with any of the marionettes, which is a bit odd, because Joshoa Sutton played the Moor, and he also played the Mouse King and the snake charmer very effectively. They've redone the Chinese dance recently. I dunno; the dancers were very good, but I think I still preferred the dragon from last year. The Russian dance is my favorite to watch, it just pulses with energy. There was a baby on stage for the party scene. The lady next to me said it was Ms. Kent's, which is why she didn't perform last year. Having a baby must be one of the worst things a professional dancer can go through.
Here's what I found most odd: I think they were lacking a dancer. Not that they were lacking any of the parts, but the sequence at the beginning of the second act where the prince narrates the battle with the Mouse King, is supposed to be narrated TO someone - and no one was there! They told it all to themselves, just a little narcissistic reminiscence. I also thought that Julie Kent played the Dew Drop Fairy, but now that I check my program I see that's wrong; unless maybe that dancer was the missing one and Ms. Kent took over for her.
It seemed short to me this year, but maybe that's the sleep deprivation again. I can't imagine what they would have bothered to cut. We were home by 10:30. It plays twice tomorrow and once again on Sunday. See it if you have a chance!
Highlights: The Arabian Dance, Mother Ginger, and Damian Woetzel as the Cavalier. I thought his solos were an impressive display of leg strength. He's from the New York City Ballet. His duets with Julie Kent were good too. Mother Ginger is played by the same person (Colin Donnell) every year and he's utterly hilarious, camping up the role and bumping and grinding his 20-foot wide hips. Joshoa Sutton and Angelina Sansone did a very erotic Arabian Dance. They play a snake and a snake charmer, and she spends her time mostly crawling up and down his body. You could just feel the steam coming off them. I mentioned it to my wife, and she said, "Oh, the one two years ago was hotter." Guess I was still too sleep-deprived then.
Lowlights: The Prince didn't quite make it under Father Christmas's robe. You could see him running along behind, and that effect didn't work at all. I've thought the last few years that the magician (Theodore Keener) kind of gets short shrift. You can see the intent in what they're doing, to make him look mysterious and magical, but the timing always seems to be just far enough off that you don't get the impression of a puppetmaster pulling the strings of the other characters that they're going for. We thought the choreography in the Dance of the Snowflakes was slightly off.
In general: Fritz (Justin Zuschlag) was very effective, hassling the girls, swordfighting the magician, and sticking his tongue out at him when he thought he could get away with it. I wasn't that excited with any of the marionettes, which is a bit odd, because Joshoa Sutton played the Moor, and he also played the Mouse King and the snake charmer very effectively. They've redone the Chinese dance recently. I dunno; the dancers were very good, but I think I still preferred the dragon from last year. The Russian dance is my favorite to watch, it just pulses with energy. There was a baby on stage for the party scene. The lady next to me said it was Ms. Kent's, which is why she didn't perform last year. Having a baby must be one of the worst things a professional dancer can go through.
Here's what I found most odd: I think they were lacking a dancer. Not that they were lacking any of the parts, but the sequence at the beginning of the second act where the prince narrates the battle with the Mouse King, is supposed to be narrated TO someone - and no one was there! They told it all to themselves, just a little narcissistic reminiscence. I also thought that Julie Kent played the Dew Drop Fairy, but now that I check my program I see that's wrong; unless maybe that dancer was the missing one and Ms. Kent took over for her.
It seemed short to me this year, but maybe that's the sleep deprivation again. I can't imagine what they would have bothered to cut. We were home by 10:30. It plays twice tomorrow and once again on Sunday. See it if you have a chance!
Wednesday, December 01, 2004
IU loses to UNC 70-63
I listened on the radio and followed along on the free peegs board, so I don't have any real insight from watching the players. But here's a few thoughts.
What I know: IU couldn't shoot to save their lives, and I don't think Carolina was much better. So why can't they shoot? The announcers say, "They don't translate what they learn in practice into games". The fans say, "They have a lousy coach." I think it could go either way. Coach Davis' first really good recruits were Marshall Strickland and Bracey Wright, and as one Peegs poster pointed out, neither one is any better as a junior than they were as freshmen. Coach's fault, or players? We won't know until - or perhaps unless - we get to see him coach a few more recruits.
What else I know: I love the freshmen! They're out there hustling and working, and Vaden nailed three three-pointers in the last couple of minutes. That's a great sign. But, so ends the first game against a really tough non-conference stretch. We'll see if the team gels...or perhaps just learns to shoot.
What I know: IU couldn't shoot to save their lives, and I don't think Carolina was much better. So why can't they shoot? The announcers say, "They don't translate what they learn in practice into games". The fans say, "They have a lousy coach." I think it could go either way. Coach Davis' first really good recruits were Marshall Strickland and Bracey Wright, and as one Peegs poster pointed out, neither one is any better as a junior than they were as freshmen. Coach's fault, or players? We won't know until - or perhaps unless - we get to see him coach a few more recruits.
What else I know: I love the freshmen! They're out there hustling and working, and Vaden nailed three three-pointers in the last couple of minutes. That's a great sign. But, so ends the first game against a really tough non-conference stretch. We'll see if the team gels...or perhaps just learns to shoot.
Tuesday, November 30, 2004
IU Basketball
I may get in the paper again tomorrow, with a comment about the Indiana basketball team. I said they would be better than last year, but not as good as next year. Here's the thing about the team: we are just now getting to the point where the last pieces of fallout from the Knight firing are manifesting. The seniors from this year - and make no mistake, it's a bad senior class - are the group that would have been recruited primarily after the firing, but before Coach Davis was given the job permanently. I don't think Adolph Rupp could have done much of a recruiting job under those circumstances. I'm hearing quite a bit of rumbling about how this might be Davis' last year, but I don't buy it. With the two Auburn transfers that will play next year, with a couple of good recruits, with maybe a couple of starting forwards taller than 6'3", I think the program might be able to get back on its feet.
Now, the Davis philosophy towards recruiting is a lot different than Knight's. We've moved from the real recruiting of student-athletes to going after the NBA talent that all the Kentuckys and Arizonas like to have. I really miss watching a smart kid with not much athleticism, like Jarrod Odle, going up against some bozo with no interest in anything but the NBA draft, like Joel Przybilla, and taking him to school. We won't see any more of that.
Well, we must move with the times. Indiana, our Indiana, Indiana, we're all for you!
Now, the Davis philosophy towards recruiting is a lot different than Knight's. We've moved from the real recruiting of student-athletes to going after the NBA talent that all the Kentuckys and Arizonas like to have. I really miss watching a smart kid with not much athleticism, like Jarrod Odle, going up against some bozo with no interest in anything but the NBA draft, like Joel Przybilla, and taking him to school. We won't see any more of that.
Well, we must move with the times. Indiana, our Indiana, Indiana, we're all for you!
Saturday, November 13, 2004
Letter to the Editor
I love it - after telling I-69 opponents not to vote for Libertarians, the newspaper - and I assume Kurt Van der Dussen again; I wish they would admit it! - now claims that every single opponent of the highway must have voted for them. Here's what I wrote to the editor in response:
After a long battle, it seems fairly clear that the issue of I-69 has resulted in a victory for big business interests over consumers, and the highway will be built. Those who continue to fight on must surely console themselves with the adage that the only cause worth fighting for is a lost one.
But the Herald-Times' position on this issue has moved beyond "supportive" to "obsessive" and maybe even as far as "flaky." Almost the only mention of the highway in the last month has been on the editorial page, first by telling highway opponents not to vote for a tiny third party, and later, bizarrely, by claiming that the tiny third party's tiny vote totals must have represented all the opponents. For my part, I suspect that many voters found the arguments in the first editorial compelling, although judging from the second the H-T must not have thought so.
Still, those who are against the highway can do nothing less than thank the Herald-Times for keeping the issue in the public eye. No cause is ever truly lost until it is no longer talked about.
There is a 200-word limit; this is about 190 words. I worked for a while trying to get in some points about the Libertarians, and how the number of people who were even aware of Gividen's anti-highway position was probably pretty small, but I decided to keep on message for this one. (I can write one letter per month, maybe next time!)
After a long battle, it seems fairly clear that the issue of I-69 has resulted in a victory for big business interests over consumers, and the highway will be built. Those who continue to fight on must surely console themselves with the adage that the only cause worth fighting for is a lost one.
But the Herald-Times' position on this issue has moved beyond "supportive" to "obsessive" and maybe even as far as "flaky." Almost the only mention of the highway in the last month has been on the editorial page, first by telling highway opponents not to vote for a tiny third party, and later, bizarrely, by claiming that the tiny third party's tiny vote totals must have represented all the opponents. For my part, I suspect that many voters found the arguments in the first editorial compelling, although judging from the second the H-T must not have thought so.
Still, those who are against the highway can do nothing less than thank the Herald-Times for keeping the issue in the public eye. No cause is ever truly lost until it is no longer talked about.
There is a 200-word limit; this is about 190 words. I worked for a while trying to get in some points about the Libertarians, and how the number of people who were even aware of Gividen's anti-highway position was probably pretty small, but I decided to keep on message for this one. (I can write one letter per month, maybe next time!)
Subscribe to:
Posts (Atom)