Posts

Showing posts from February, 2026

Working in Groups: Compromises or Contributions?

Some time ago, on a social media platform, during a discussion about technology, a pundit posted a piece arguing that teamwork was a horrible idea.   The Compromise Theory: His thesis is that an individual can have a great idea. When other people get involved, they have differing ideas. To settle the differences, the group has to make compromises.  Every compromise is a degradation of the original idea's purity. By definition, he said, every compromise is a second-best choice.  Eventually, the idea is so diluted and compromised that it is hardly worth implementing. The Contribution Theory: Cross-functional, diverse teams are well-documented and understood. They make better decisions, make rapid progress, and approach a problem from more angles.  The thesis here is that "two heads are better than one" for problem-solving, and that the work of an individual (rather than being perfect and pure) is likely to have more flaws and a narrower vision than the work of sev...

The Big Release Downward Spiral

The riskiness of a release is proportionate to the number of potentially untested paths in the new code. If there are a thousand new possible paths and we've only tested 4, then it's a significant risk to the installed base. If there are two, and we've tested both, then it's not risky at all. The larger a release (the more stockpiled functionality) and the less complete the characterisation via tests (automatic and manual), the more a company must grow bureaucracy and processes around releasing. The harder it becomes to push a release through all the bureaucratic gates, the more work gets stockpiled before release. This is the self-eating mechanism that CD dismantles. When a release may be only a couple of lines of code, the risk comes down. When it's one function, reached in only one way, then it's a limited set of paths. Saving up for a big release stockpiles pain and risk.