I can give you:
- Great Functionality
- A great delivery date
- Exceptional quality
I never could be very scientific about it, I would tend to lean on some common sense, or the old, Whack a Mole mentality. If you cut the date, either you are going to shortcut the function or the quality. Lets make sure we all understand that it's the date that counts. You have to make the date and have to deliver all the functionality required. How many of you have been involved in this discussion? And of course, what ends up being hit, is the quality. This was especially an interesting parable as the latter part of my career I dealt with High Availability products, you couldn't have poor quality. We managed very well, don't get me wrong, we delivered extremely high quality products. But, this game was part of every release cycle.
As part of my ongoing research, I came across an article written by Ryan Shriver on Technical debt. You can find this article at http://www.gantthead.com/article.cfm?ID=258854
Wow, here it is all laid out. I felt a bit embarrassed to find this term was first identified in the early 90's. Goes to show another one of my favorite quotes, It's what you learn after you know it all that counts.
There are many discussions and definitions here, but as always, pictures talk the loudest:
Technical Debt Chart from Jim Highsmith
Now, looking at this article, many links and recommendations can be found to deal with attributes of troubled development organizations, such as:
- Poor Customer Responsiveness
- Long Delivery Times
- Late Deliveries
- Too Many Defects
- Rising Costs
- Poor Morale