3 ms·

> The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to

by radlad 4y ago

> The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on. Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? It's easy to go too far in either direction.

hbrn 4y ago
In my experience, most of the software complexity is accidental, i.e. it doesn't directly emerge from customer needs. And even if your framework is to use customer needs as justification for complexity, people will still use something like Kubernetes for an app with 10 monthly users, because it "helps us deliver features faster, have zero-downtime deployments and be scalable". Most (non-product) engineers have a natural inclination to introduce more complexity, and will use mental gymnastics to justify it.
- nerpderp82 4y ago
  The majority of human intellect is used to justify actions they have already taken.
PaulStatezny 4y ago
> Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? With respect, this is clearly a false dichotomy. Creating the "simplest possible system" that solves customer needs is the entire point of this discussion. Avoiding as much complexity as possible brings enormous benefits. (Less bugs, less employee turnover, higher productivity, etc.) Never accept the notion that systems must be "difficult-to-work with" in order to solve customer needs.
- radlad 4y ago
  It would be a false dichotomy, if I meant to say that you must choose one of these paths. I suppose "it's easy to go too far in either direction" was not clear enough. The argument I'm making is that the OP is creating a false dichotomy: that you must reject feature requests, or ruin the system. My point is that there are many, many developers who "relentlessly say no to feature requests that literally destroy the system to add some new feature" when the reality is that they do not want to put in the effort required to add the (meaningful) feature to the system. They are choosing system purity and laziness over delivering customer value, which requires more work in order to keep things simple.
whstl 4y ago
I never really had to make this choice. But I often had to choose between a system that is reasonable and actually solves the needs of customers, versus a system that is complex, made in a hurry and full of badly made features that only some project manager cares about. I know which one I prefer. Just today, for example, I removed several thousand lines of code from a very complex form that no customer ever really used other than for testing. My boss told me "just nuke it". Life goes on.

by radlad 4y ago

hbrn 4y ago

In my experience, most of the software complexity is accidental, i.e. it doesn't directly emerge from customer needs. And even if your framework is to use customer needs as justification for complexity, people will still use something like Kubernetes for an app with 10 monthly users, because it "helps us deliver features faster, have zero-downtime deployments and be scalable". Most (non-product) engineers have a natural inclination to introduce more complexity, and will use mental gymnastics to justify it.

nerpderp82 4y ago
The majority of human intellect is used to justify actions they have already taken.

PaulStatezny 4y ago

> Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? With respect, this is clearly a false dichotomy. Creating the "simplest possible system" that solves customer needs is the entire point of this discussion. Avoiding as much complexity as possible brings enormous benefits. (Less bugs, less employee turnover, higher productivity, etc.) Never accept the notion that systems must be "difficult-to-work with" in order to solve customer needs.

radlad 4y ago
It would be a false dichotomy, if I meant to say that you must choose one of these paths. I suppose "it's easy to go too far in either direction" was not clear enough. The argument I'm making is that the OP is creating a false dichotomy: that you must reject feature requests, or ruin the system. My point is that there are many, many developers who "relentlessly say no to feature requests that literally destroy the system to add some new feature" when the reality is that they do not want to put in the effort required to add the (meaningful) feature to the system. They are choosing system purity and laziness over delivering customer value, which requires more work in order to keep things simple.

whstl 4y ago

I never really had to make this choice. But I often had to choose between a system that is reasonable and actually solves the needs of customers, versus a system that is complex, made in a hurry and full of badly made features that only some project manager cares about. I know which one I prefer. Just today, for example, I removed several thousand lines of code from a very complex form that no customer ever really used other than for testing. My boss told me "just nuke it". Life goes on.