CI/CD, deploying fast, changing things easily and getting them into production within minutes is well within reach of most teams these days. I'm not saying it's an inexpensive exercise to get there for a long-deployed, monolithic application.. but it can be done in most cases I find; and when it is you have more options.
You can hard code things and kill most of the complexities this author talks about. It's a great feeling.
Up front cost in terms of automation is often linear. The opportunity cost of automating and simplifying is far more than linear.
The foremost principal of #leanstartup is Small Batches IMO. Keeping everything small (functions, reusability, work items, features, complexities, etc, etc) means you do things fast and often. You automate when repetition becomes painful and you understand the pain well (and not before).
These days I have a `Config` object which contains a static tree of config params. Sure these change occasionally, but not that often. It's more for reusability than 'configuration'. It's a source of truth for common values. Only a few of these values are deserialised from a config file, env variable or replaced by a deployment tool.
Mainline dev (Github Flow) means I can make a change, deploy it to an integrated environment quickly (single digit minutes) with all the build and tests passing, check it in the staging env, and click a button to put it into Prod (seconds usually). With the up front investment of automation making this possible, I can avoid a heap of non-linear complexity in my architecture and code. It's the only way to fly.
> CI/CD, deploying fast, changing things easily and getting them into production within minutes is well within reach of most teams these days.
Someone else who's living in the as-a-service bubble. Meanwhile, embedded systems, OS-level components, desktop apps, and compliance-heavy industries continue to exist.
> It's the only way to fly.
Yeah... no. Even on projects where I have fast CI/CD, the best complexity killer is taking a step back, thinking about the problem space and weighing the options before settling on an implementation.
You can hard code things and kill most of the complexities this author talks about. It's a great feeling.
Up front cost in terms of automation is often linear. The opportunity cost of automating and simplifying is far more than linear.
The foremost principal of #leanstartup is Small Batches IMO. Keeping everything small (functions, reusability, work items, features, complexities, etc, etc) means you do things fast and often. You automate when repetition becomes painful and you understand the pain well (and not before).
These days I have a `Config` object which contains a static tree of config params. Sure these change occasionally, but not that often. It's more for reusability than 'configuration'. It's a source of truth for common values. Only a few of these values are deserialised from a config file, env variable or replaced by a deployment tool.
Mainline dev (Github Flow) means I can make a change, deploy it to an integrated environment quickly (single digit minutes) with all the build and tests passing, check it in the staging env, and click a button to put it into Prod (seconds usually). With the up front investment of automation making this possible, I can avoid a heap of non-linear complexity in my architecture and code. It's the only way to fly.