3 ms·
Overall it's about finding new generalizations and collapse your extensive complexity by new abstraction. For example, you build a Todo-list software (everybod
by tablet 5y ago
Overall it's about finding new generalizations and collapse your extensive complexity by new abstraction.
For example, you build a Todo-list software (everybody does). You have requests from customers "I want to be notified 3 days before due date", "I want to be notified 1 day before due date" and "I don't need notifications".
OK, so you are adding a new setting "[ON/OFF] Notify me [X] days before due date".
Then you get feedback "I want to be notified when someone unassigned me" and "I want to be notified when someone assigns me".
OK. You're adding new setting "[ON/OF] Notify me about changes of my assignments"
Then you receive feedback like "I want to be notified about important tasks assigned to me only".
You say "Fuck it" and implement a notification engine where every user can set up own notification rules.
X notifications settings were collapsed into a new more abstract (but more complex) solution. You have to choose abstractions carefully and be aware that premature abstractization is as bad as premature optimization. This is hard.
- k__ 5y agoWell explained. Thank you!
- corpMaverick 5y agoI really liked the simplicity of your explanation and it makes total sense to me. I checked your blog and you have some interesting articles but most I can't read. I think it is time to start rescuing the insights of software engineering practitioners with several decades experience to go beyond the fads of the day. I feel that some of the old agile ideas/principles are lost in the noise. (e.g Do The Simplest Thing That Could Possibly Work)
- tablet 5y agoThank you :) You can check my articles in English here https://fibery.io/blog/ https://fibery.io/blog/