Interactive ASP.NET

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...

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...

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...

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...

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...

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...

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...

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...

In a previous post I talked about the blame game . I suggested that “the blame game” is a necessary part of software failures so it shouldn't be treated with as much fear and loathing it usually receives. By understanding the human need to pin down blame (and the general inability for human...

The Story So Far Let’s return to the primary concern with Software. We’ve talked about how most software projects either fail altogether or run significantly over budget . Along with that thought, we considered the statistics that show that the development team itself plays little role in...

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. – George Patten This sounds like good advice doesn’t it? It is, actually, but we need to understand it correctly. The first thing we need to notice is that there is no objective difference...

Do you make a keep a budget with your home finances? Maybe I should ask “should you make and keep a budget with your home finances?” If you are the average American it's likely that you answered “no” to the first and “yes” to the second. Why do we not do things we...

I want to discuss the need for blame on software projects. “Ug! The blame game! I hate that!” I hear you groan. But it's an all too familiar game for all of us. We all know that software (or all human endeavors actually) end with what we call “the blame game” where we all point...

Trying to estimate software projects is difficult to say the least. But sometimes, it’s just impossible. I just finished resolving a problem on my project that I spent the last two days working on. The task was to issue a Purchase Order (PO) to a vendor using the SAP interface available to me. ...

In a previous post I mentioned Robert Glass’ “fact” that estimates are made at the beginning of the project before the problem is even defined, thus the estimate is invalid from the get go. While I don’t disagree with Glass, I do believe he is under estimating (pun intended!) why we human’s prefer estimates...