I still remember a project (I was the eng director and one of my team leads did this) where my team lead for a new dev project was given a group of near-shore S

I still remember a project (I was the eng director and one of my team leads did this) where my team lead for a new dev project was given a group of near-shore SWEs + offshore SQA who were new to both the language & RDBMS of choice, and also didn't have any business domain experience. He decided that was exactly the time to implement TDD, and he took it upon himself to write 100% test coverage based on the approved specs, and literally just instructed the team to write code to pass the tests. They used daily stand-ups to answer questions, and weekly reviews to assess themes & progress. It was slow going, but it was a luxurious experience for the developers, many of whom were using pair programming at the time and now found themselves on a project where they had a committed & dedicated senior staffer to actively review their work and coach them through the project (and new tools learnings). I had never allowed a project to be run like that before, but it was one where we had a fairly flexible timeline as long as periodic deliverables were achieved, so I used it as a kind of science project to see how something that extreme would fare. The result was that 1) the devs were exceptionally happy, 2) the TL was mostly happy, except with some of the extra forced work he created for himself as the bottleneck, 3) the project took longer than expected, and 4) the code was SOOOOO readable but also very inefficient. We realized during the project that forcing unit tests for literally everything was also forcing a breaking up of methods & functions into much smaller discrete pieces than would have been optimal from both performance & extensibility perspectives. It wasn't the last TDD project we ran, but we were far more flexible after that. I had one other "science project" while managing that team, too. It was one where we decided to create an architect role (it was the hotness at that time), and let them design everything from the beginning, after which the dev team would run with it using their typical agile/sprint methodology. We ended up with the most spaghetti code of abstraction upon abstraction, factories for all sorts of things, and a codebase that became almost unsupportable from the time it was launched, necessitating v2.0 be a near complete rewrite of the business logic and a lot of the data interfaces. The lessons I learned from those projects was that it's important to have experienced folks on every dev team, and that creating a general standard that allows for flexibility in specific architectural/technical decisions will result in higher quality software, faster, than if one is too prescriptive (either in process or in architecture/design patterns). I also learned that there's no such thing as too much SQA, but that's for a different story.