Whilst the article is unashamedly a plug for their book, it does highlight deficiencies that seem to be prevalent in the corporate world, where commercial constraints often put pressure on a project team to deliver "the product", causing other deliverables - in particular things like documentation, testing, architecture, etc - to be given less weight than they perhaps otherwise should. The practices and patterns that should be applied across the project getting subverted by the commercial "realities".
In the article, they detail five principles for successfully delivering a project, namely:
- Tell the truth all the time
- Trust the team
- Review everything, test everything
- All developers are created equal
- The fastest way through the project is to do it right
These, particularly the latter, should be championed much more. Time and again, I've found I've had to argue in favour of a bit more complexity and cost for a feature in order to future proof it or provide a foundation for future work, against the drive to deliver "just what's needed as soon as possible and as cheaply as possible".
Inevitably, if the product in question is going to have a future beyond its first release, then thinking about that future, and the possible changes or extensions to its functionality, and putting foundations in place to support that future give long-term cost benefits that far outweigh the short-term savings that a "sub-optimal" solution would bring.
The article can be found here: