-
There's a myth that feature work slows down over time as codebases become more complex. However, good engineering practices can support long-lived codebases effectively. Any framework or infra will claim to improve feature velocity, but this rarely seems to happen, why?Permalink On twitter.com
Mood +8 🙂
-
I argue the problem is organizational rather than technical. As any product acquires users there is a fear of breaking or losing such users due to changes in the code. Put simply, the problem isn't that running A/B tests is slow, it's that you now have to run A/B tests at all.Permalink On twitter.com
Mood -9 🙁
-
This "fear of breaking" manifests in many ways, from logging and error reporting to performance monitoring and unit testing. This is often good for the user (and developer) in many ways but also feels like a stagnating system to the developers who work on it.Permalink On twitter.com
Mood +1 🙂
-
Ultimately the change comes when the organization realizes it has something to lose, often reflected when the team drops the "startup mindset". Startups inherently have nothing to lose and don't care about making an occasional bad decision as long as they are successful overall.Permalink On twitter.com
Mood -2 🙁
-
And that's not necessarily a bad thing. This transition is often reflective of the maturity of the product and what users really want out of it. However, developers often mistake this situation as a failure of the tools they used. "We used to be so much more productive."Permalink On twitter.com
Mood -6 🙁
-
The sad reality is that no tool will solve this organizational problem. Tools can help but "switching to X will reduce the burden on us so we can return to our old velocity" is just wishful thinking. A development team can't move faster than the organization they are a part of.On twitter.com
Mood -4 🙁