3 ms·

> If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. Thats the crux of the problem. Dif

> If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. Thats the crux of the problem. Different people have different definitions of flexible. How are you defining it?

rhizome 8y ago
Well obviously it's going to be in their code style document(s) given to every programmer during onboarding.
BurningFrog 8y ago
In this context it means that it's easy to make changes. As in add new functionality.
- mlthoughts2018 8y ago
  But you can’t make it equally easy to add in every type of functionality. For any type of extensibility design you bake in, some other types of extensibility now become harder. So “making it flexible” hinges entirely on whether or not you can correctly forecast exactly which types of flexibility you’ll need. But this is no easier, and often harder, than predicting how end user requirements might change in the first place!
  - BurningFrog 8y ago
    What it means in practice is no extensibility baked in at all. Rather it is very modular design, that is very simple, bordering on dumb. This is all very much easier said than done. "Simple ain't easy".
mlthoughts2018 8y ago
Exactly. The same “end user” problems recursively repeats. You just think of other (or future) developers as the end users, and those actual user requirements you can’t predict, that ends up meaning you also cannot predict what the developers flexibility requirements will be either. You end up “making your codebase flexible” in all the wrong ways by introducing abstractions, interfaces, and extensibility designs that end up being the wrong tool for the job once the future requirements are known. There may still be a simplistic, high level where you can have certainty about how to factor code. E.g. separating front-end and back-end, using tests as scaffolding for helping verify deployments and facilitate changing code, using a few simple tricks here and there to reduce boilerplate or make sections of code reusable. It’s totally fine to pursue these optimizations, especially if they are part of a healthy backlog process to prioritize them. But the problem creeps in when principal developers or “philosophizing architects” take it as a goal unto itself and begin trying to mandate it all the time, especially with the anti-pattern where huge architecture discussions become synonymous with routine “just get something done that works and refactor later” code reviews.

rhizome 8y ago

Well obviously it's going to be in their code style document(s) given to every programmer during onboarding.

BurningFrog 8y ago

In this context it means that it's easy to make changes. As in add new functionality.

mlthoughts2018 8y ago
But you can’t make it equally easy to add in every type of functionality. For any type of extensibility design you bake in, some other types of extensibility now become harder. So “making it flexible” hinges entirely on whether or not you can correctly forecast exactly which types of flexibility you’ll need. But this is no easier, and often harder, than predicting how end user requirements might change in the first place!
- BurningFrog 8y ago
  What it means in practice is no extensibility baked in at all. Rather it is very modular design, that is very simple, bordering on dumb. This is all very much easier said than done. "Simple ain't easy".

mlthoughts2018 8y ago

Exactly. The same “end user” problems recursively repeats. You just think of other (or future) developers as the end users, and those actual user requirements you can’t predict, that ends up meaning you also cannot predict what the developers flexibility requirements will be either. You end up “making your codebase flexible” in all the wrong ways by introducing abstractions, interfaces, and extensibility designs that end up being the wrong tool for the job once the future requirements are known. There may still be a simplistic, high level where you can have certainty about how to factor code. E.g. separating front-end and back-end, using tests as scaffolding for helping verify deployments and facilitate changing code, using a few simple tricks here and there to reduce boilerplate or make sections of code reusable. It’s totally fine to pursue these optimizations, especially if they are part of a healthy backlog process to prioritize them. But the problem creeps in when principal developers or “philosophizing architects” take it as a goal unto itself and begin trying to mandate it all the time, especially with the anti-pattern where huge architecture discussions become synonymous with routine “just get something done that works and refactor later” code reviews.