How boring should your team's codebases be
There&#x27;s never a simple answer to this.<p>Here&#x27;s some of the things we encounter:<p>* A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them.<p>* Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don&#x27;t force this down people&#x27;s throats, but they&#x27;re always thinking about what they can apply in the future. That&#x27;s not to say they can&#x27;t be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you&#x27;re just ticking down a clock in a lot of cases.<p>* Complex code can be a hindrance to onboarding new developers. Boring code can be a hindrance to onboarding new features.<p>* You often end up in a situation where you&#x27;re reinventing the wheel and you&#x27;re spending increasing amounts of development time on keeping the wheel round. At some point you&#x27;ve got to consider a ready-made solution to your problem or consider hiring more people to deal with it.<p>* Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high.<p>Creating a company off the back of a flavour-of-the-month tech stack isn&#x27;t a good idea. But I can&#x27;t see how any large software company can scale without having a bit of spice somewhere.