Interactive ASP.NET

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's to be able to) we are avoiding ignoring this

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 the success and failure of the project in comparison

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 between ‘what’ and ‘how.’

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 know we should do? I suspect the answer is quite simply

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 figures at each other and claim the failure was

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.  It all started when the Purchasing group called to

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 – even known bad ones – over no estimate at

So if we admit that software is really about human intelligence, not tools , then we know that human factors matter the most. Tom Demarco and Lister, in their famous (infamous?) book Peopleware, were the first to make popular the idea that it was people that mattered the most. But I can't shake the sneaking suspicion that they missed something. You

In Robert Glass' excellent book, Fact and Fallacies of Software Engineering , one of his “facts” (I.e. Qualified opinions) if that “Most software estimates are preformed at the beginning of the life cycle... before the requirements are defined and thus before the problem is understood.” He goes on to say that, unlike many of

What matters more to the outcome of a software project? Good tools or good people? Okay, that one is a no brainer, right? We all know people matter more than tools, right? But try this thought experiment. Take an average group of programmers today and set them up in a contest with the brainiest programmers of 1000 years ago. Who wins? No, no, no, that