Joshua Schachter of del.icio.us: “Things to look out for when building a large application”

NASA: Object Oriented Data Technology: is a project run at NASA’s Jet Propulsion Laboratory. OODT makes data discovery, query optimization, information correlation, and format conversion a snap.. Interesting presentation to watch: Better Web App Development – Django, Rails, Turbo Gears, Zope and J2EE.

Database War Stories #6: O’Reilly Research, previously Second Life, Bloglines and Memeorandum, Flickr, NASA World Wind, and Craigslist.

A behind the curtain look at the data backends of some well known services:

Part 1: Second Life

Part 2: bloglines and memeorandum

Part 3: Flickr

Part 4: NASA World Wind

Part 5: craigslist

Psyc+Tech: Don’t draw diagrams of wrong practices:

The Waterfall model is originally invented by Winston W. Royce in 1970. He wrote a scientific article that contained his personal views on software development. In the first half of the article, he discusses a process that he calls “grandiose”. He even drew a figure of the model, and another showing why it doesn’t work (because the requirements always change). This model is the waterfall. He used it as an example of a process that simply does not work. In the latter half of the article he describes an iterative process that he deems much better.

OK, so why do people still advocate the waterfall? If you look at the scientific articles on software engineering that discuss the waterfall, they all cite Royce’s article. In other words, they’re saying something like “The waterfall is a proven method (Royce, 1970).” So they base their claims on an article that actually says the opposite: that the model does not work.

This is how science (unfortunately) often works – researchers just cite something, because everyone else does so as well, and don’t really read the publications that they refer to. So eventually an often cited claim becomes “fact”.

I would argue that Waterfall methodologies can work, however just like Agile, it depends on the project, the team, and the environment. As always, pick the right tool for the job. A development methology is just another tool. Just another means to an end.

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.