Interactive ASP.NET

In this story, there are three “groups”. The vendor, who is the development team, the end users, and IT for the users. IT is the sponsor – i.e. they have the money for the project.  The vendor does a pretty good job of documenting their requests for information. The end users don’t always do such a good job of responding in a timely manner. This

Nate sent me the following link . Take a peek because it’s hilarious. Was this created to mock enterprise companies or to mock Agile? I can’t even tell. I hate to admit it, but I think this ‘joke’ is sort of correct. If I had one complaint about Agile it is that it seems too naive at times. The idea seems to be that if you use an Agile methodology you

This post over at The Eternal Universe is a physicist complaining about how he’s not seeking a computer science degree, yet he has to keep learning computer languages just to publish physics papers. He should have read my previous post about the Law of Lossy Requirements . The cheapest way to capture all of the details of an algorithm is in code. English

Okay, the title for this post is misleading, I admit. But I wanted to catch your attention. One irony of software development is that the consulting companies I’ve worked for always want me, as project manager, to have documentation to prove I did every reasonable thing possible to make the project succeed. Is that so bad? Actually, sometimes, yes.

There is an old Far Side comic where a professor is working complex math on a white board. At one point he’s written “and then a miracle occurs” and then successfully finishes his difficult problem. I’ve talked to a lot of programmers that feel software actually tries to do just that. They complain that that no matter how many

In my post on “code is really design” post, I mentioned that I would further address the paradox that software is created in “thoughts units” but the most important people to the success or failure of a project are the sponsor and customer . In this post, I’ll explore that paradox further by discussing Alistair Cockburn’s idea of Software as a cooperative

Lossy Compression In computer science, compression is an indispensible tool. Anyone familiar with .zip files knows what I mean. Interestingly, there are two kids of compression, lossless and lossy. Lossless compression is like .zip compression, you put a file of, say, 100kb in and the end result is a file of, say, 50k. But when you reverse the process

Abstraction vs. Precision in Requirements I used to be an instructor for Rational Software’s RequisitePro software, which included a class called “Requirements College.” This useful class helped teach people how to elicit requirements from their customers. Three things that really stuck with me from the class were, first, the idea

It seems to me that “overtime” is a much talked about subject, both in literature and just around the water cooler, but that people tend to take one of two extreme views on it. The first view is that overtime is immoral unless the development team screwed up. This point of view says, “if I made a mistake, I’ll make good, but

In a previous post I used Robert Glass’ advice from his excellent book, Facts and Fallacies of Software Engineering to come up with what I see as the industries standard advice on how to do good software estimates: To summarize, the standard advice is to: Not make estimates until requirements have been defined Always let the programming team make