The article is intended to point out a lot of the "classic" mistakes that get made over and over again in software development:
- Lack of visibility into progress, which ends up in surprise when the schedule slips
- Isolationist team members, which ends up with a game of "is this huge chunk of code any good?"
- Over-optimistic scheduling, resulting in slips when reality intrudes
- Feature creep
- Unclear definitions of done
There were a couple things in the article that I noticed and wanted to point out that are also classic mistakes:
- QA is the canary in the coal mine
- Work harder to make up time
Some more classic mistakes in a software project.
QA is the canary in the coal mine.
This one is interesting. Consistently in the story, the first warning that things were not kosher came from QA. That's bad. If you're surprised by what QA tells you, then the dev team is not collectively aware of your code. There's nothing wrong with sending something buggy to QA... as long as you know it's buggy. Surprise says you aren't evaluating (or can't evaluate) your own code. The end result is that it's almost certainly not as good as you think it is.
Work harder to make up time.
In the article, schedule slippages are countered in part by forcing people to work 10 hours a day, then 12 hours a day. After 12 hours, they may be at work, but they're not exactly working. They're checking email, surfing the web, and generally being non-productive. Working harder won't make up time, it'll just wear people down.
A corollary to this is one of my personal guidelines: "don't trust tests done or code checked in after 12 hours straight".
We all make mistakes. Let's just try not to make the same ones over and over again.