From “Software is too expensive to build cheaply…” comes the good news that Microsoft is extending its Visual Studio handout program.

C# isn’t bad. No really! I think I’m going to download one of these and get back to experimenting (in my copius free time of course).

I think in some environments, for some products, using XP and other Agile methodologies make sense. Read “The New Methodology” by Martin Fowler for why. However, some promote it as some kind of silver bullet. A panacea. Shelley Powers raises some good points to think about:

…what the makers behind the Manifesto are promoting is incremental releases–the continuous state of beta that we see at Flickr, Google, Yahoo, and other sites. Yup, that’s where it came from folks: agile programming.

The principle isn’t bad: release small, release often, and don’t get stuck in analysis paralysis. However, the problem with the concept is that many applications can’t be released small, and beta is only cool in certain small circles. Most of us don’t want the systems we’re dependent on to be in a permanent state of change, of beta. I don’t want my income taxes managed by beta software. I don’t the hospital lab’s work to be managed through beta software. I certainly don’t want NORAD to use “Radar by Google”.

The release early, release often doesn’t solve the problems of managing larger and critical need software applications. As for applications that have followed this approach, such as Gmail and others of that nature, we’re already seeing a great deal of pushback against features appearing and disappearing without warning, and applications failing, and cute little plumbers popping up saying, “Ooops! Something broke”. It’s wearing thin; it’s no longer so fun.

Dare Obasanjo: The Two Webs:

This is an interesting distinction and one that makes me re-evaluate my reasons for being interested in RESTful web services. I see two main arguments for using RESTful approaches to building distributed applications on the Web. The first is that it is simpler than other approaches to building distributed applications that the software industry has cooked up. The second is that it has been proven to scale on the Web.

The second reason is where it gets interesting. Once you start reading articles on building RESTful web services such as Joe Gregorio’s How to Create a REST Protocol and Dispatching in a REST Protocol Application you realize that how REST advocates talk about how one should build RESTful applications is actually different from how the Web works. Few web applications support HTTP methods other than GET and POST, few web applications send out the correct MIME types when sending data to clients, many Web applications use cookies for storing application state instead of allowing hypermedia to be the engine of application state (i.e. keeping the state in the URL) and in a suprisingly large number of cases the markup in documents being transmitted is invalid or malformed in some ways. However the Web still works. 

REST is an attempt to formalize the workings of the Web ex post facto. However it describes an ideal of how the Web works and in many cases the reality of the Web deviates significantly from what advocates of RESTful approaches preach. The question is whether this disconnect invalidates the teachings of REST. I think the answer is no.