I love this story. It offers an important reminder about how our industry really works. Whenever a practice becomes established as a "best practice", such as a

I love this story. It offers an important reminder about how our industry really works. Whenever a practice becomes established as a "best practice", such as automated testing, then the next question that arises is "Why isn't everyone doing this to the max?" And folks that don't follow best practice generally feel guilty and keep quiet. But those who follow fashions in tech tend to underestimate the opportunity costs of doing so. This is the moral of the above story, and it is a good one: "Hopefully you are horrified by all things we didn't do that are now considered best practices. No reproducible builds, lack of automated testing, creating and then repeatedly sidestepping technical debt. For a long time, that is how I told these stories: as horror stories that came complete with hand gesticulations to emphasize the "can you believe I had to do that?" nature of it all. Here's the thing though: we were making money. We were growing and supporting ourselves." I spent this winter working for a startup that had the opposite problem of most startups. The CTO was a serious Pythonista, and he wanted to ensure that all the code was written was of high quality. He wanted to avoid the build up of technical debt. There were 9 programmers on the team, using Python on the backend and AngularJS on the frontend. And he felt they could invent a new way forward, in terms of combining Python and Angular. And so the team was reinventing the whole Python stack: they had their own serialization libraries, their own database libraries, their own web server, their own authentication system. Adding each new feature lead to very long meetings in which people were encouraged to be thoughtful -- everyone was suppose to think about the long term consequences of whatever design was chosen. In some ways, it was a careful style, but it had a cost: the 9 developers spent more than 50% of their time on infrastructure questions that had already been solved elsewhere. In terms of meeting the real needs of this small startup, the startup might has well have had a team of 4 developers -- the money paid to 5 of the developers was, in a sense, an act of charity being offered to the Python community. We've all ready endless stories about startups that cut corners, ran up technical debt, and eventually succeeded. We read much less often about startups that doing everything perfectly and then become successful. And that suggests that, for startups, cutting corners is the more adaptive path.