Over the course of a decades-long career in software, I have seen more and more of the typical stack commodified and turned into boring reliable off-the-shelf components. And that’s good, because it means you can just pick a language. Pick a library/framework. Pick a message bus. Pick a version control system. Pick a code host. Pick a CI/CD system. Pick a deployment target. And this has been a good thing.
To extend the author’s point: when you innovate on one of these commodity components, you stop being whatever you were before. Were you a widget retailer? Well, now you’re a widget retailer and a web framework developer. Or a widget retailer and a CI/CD developer. And unless you are one of a handful of gigantic companies that can afford to staff an entire team or department to do that, you almost certainly do not have the resources to be effective at both of those, so at least one of them’s going to suffer, and probably both.
If I were to nitpick, I’d worry that the message - while correct in general - can easily be misinterpreted to apply more broadly than it actually does. In particular, the brief reference to “setting up the perfect CI pipeline” rubs me the wrong way. The definition of “perfect” makes a big difference here. The post is definitely correct that it’s possible - and maybe even common - to over engineer a particular CI pipeline. But one should be wary of encouraging the opposing - and possibly even more common - failure mode, of failing to set up adequate CI.
Author here. In using the word “perfect” I wanted to make the point that aspiring for perfection, in areas other than the original product you are building, is a distraction that should be avoided. Of course there’s an argument to be made that underinvesting in tooling will slow down progress, but that’s kicking down and open door at this point? :)
Over the course of a decades-long career in software, I have seen more and more of the typical stack commodified and turned into boring reliable off-the-shelf components. And that’s good, because it means you can just pick a language. Pick a library/framework. Pick a message bus. Pick a version control system. Pick a code host. Pick a CI/CD system. Pick a deployment target. And this has been a good thing.
To extend the author’s point: when you innovate on one of these commodity components, you stop being whatever you were before. Were you a widget retailer? Well, now you’re a widget retailer and a web framework developer. Or a widget retailer and a CI/CD developer. And unless you are one of a handful of gigantic companies that can afford to staff an entire team or department to do that, you almost certainly do not have the resources to be effective at both of those, so at least one of them’s going to suffer, and probably both.
It’s a nice post, and contains much wisdom.
If I were to nitpick, I’d worry that the message - while correct in general - can easily be misinterpreted to apply more broadly than it actually does. In particular, the brief reference to “setting up the perfect CI pipeline” rubs me the wrong way. The definition of “perfect” makes a big difference here. The post is definitely correct that it’s possible - and maybe even common - to over engineer a particular CI pipeline. But one should be wary of encouraging the opposing - and possibly even more common - failure mode, of failing to set up adequate CI.
Author here. In using the word “perfect” I wanted to make the point that aspiring for perfection, in areas other than the original product you are building, is a distraction that should be avoided. Of course there’s an argument to be made that underinvesting in tooling will slow down progress, but that’s kicking down and open door at this point? :)