Moving Fast
Being able to build things quickly is a valuable trait when building software; it permits a team to deliver new features to customers in rapid succession. This, in turn, keeps customers happy; new features means new toys to play with and new things they can do with their data – and that’s exciting.
Building a feature, no matter how small, has a distinct life-cycle and each time you bring on board a new feature it affects the other parts of your system. It is obvious to most engineers that building a feature takes time; this is the most immediately visible portion of the lifecycle to a developer. The hours they spend in front of the computer programming or at a whiteboard designing a feature has a very tangible time cost and it’s easy to see.
However, just because building a feature is straightforward does not mean that the maintenance cost or operational burden is zero. This is a hard one to predict as a developer; because you’re not in the future (yet), future you can’t tell current you what a bad idea your current design is.
As hindsight is 20/20 the only thing that keeps us from repeating the same mistakes is that we have (hopefully) learned from our past mistakes and strive to avoid them. especially deprecating a feature has an implied cost.
Do not confuse motion with progress
Just because you can move fast doesn’t always mean you should. Moving fast, in the right direction, with the right amount of forethought, can be incredibly empowering. Having tools that provide continuous deployment so that you can move forward in an automated fashion without needing to involve a half-dozen engineers to kick off deployments, manually execute scripts, babysit servers, etc. is incredibly cool.