You've outined why you would write contracts and a lot of examples with guide rails etc. I would imagine that a big project in a language without contract support would need some kind of automated system to check coverage of contracts on the code. Any ideas or pointers on a standardized and parseable syntax for the comments to write the contracts in? What about stealing some of the syntax from a language with contracts like D, Ada, or even the C++ proposal for contracts?
In my experience, the big improvement for a team is going from treating methods/procedures/functions as a convenient named group of code to treating them as little bits of machinery that are expected to work in a certain way (ie according to the contract). A team that thinks this way can use the tools they have to manage the contracts -- things like their own brains and simple unit tests. It's not that tooling is a bad idea -- far from it -- it's that lack of tooling shouldn't discourage a team from trying contracts. And adding machine-checkable contracts is yet another hurdle to convince your co-workers about.
@@georgehfairbanks I just worry without some "contract" (haha) that's enforcing it to some degree I'll just get soft buy in no one will actually do them without constant work of the adopters going over everything. I.e. the same problems with code comments in general since they are out of date and with no real quality checks.
Try Keeling's essay on ADR adoption. www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/. The critical thing is to get the team thinking about design, thinking of themselves as designers. No static analysis can force them to write good contracts.
