3 ms·
> even when removing features is more efficient Efficient in what sense ? > Our conclusion is that people systematically overlook subtraction; it’s not that s
by nzach 2y ago
> even when removing features is more efficient
Efficient in what sense ?
> Our conclusion is that people systematically overlook subtraction; it’s not that subtraction is always better
My personal experience agrees with these findings, but I think they missed something more important. People try to change things because they want to see something new in the real world. But from ideas to real world impact there is always at least one level of 'approving' you will have to go through. And adding things will generally have less risk associated.
Besides that, I think our education system doesn't train us to remove things. Everything we learn is incrementally built upon what was already there. So our default mode of thought is to add things.
Now imagine we have 2 developers, one how always solves problems by adding something new and another one that always refactor things to keep things efficient.
My guess is that by only adding things you will end up delivering more features with less bugs. Sure your code will be slower and at some point it will become impossibly complex to manage, but it takes quite a long to time to get to this point.
After writing this message I've realized that 'making things easy to delete' is a pretty important feature.
- em-bee 2y agoPeople try to change things because they want to see something new in the real world my personal feeling on this is rather, removing someone elses code is like dismissing their work. and generally i don't want to do that. if it is not clearly a bug, then i'd hesitate. someone wants this feature. taking it away would not be nice to them. it may be similar to the problem of design by committee. everyone wants to get their favorite features in, and we are more concerned about our relationship to our colleagues than the end result. here, we can solve this in a way to make everyone happy, but without stopping to ask if removing that mis-feature would actually make anyone unhappy. thinking further, i think this is also a problem with personal ownership of code or features instead of team ownership. this feature is owned by X, i can't remove it without his permission, or without a discussion in a meeting. leaving it in and working around it is the path of least resistance