I can nearly guarantee a feature will be technical debt, when a user has asked for it to meet organizational requirements that have nothing to do with the application's normal usage. When I implement it, I always know it is going to be a thorn in my side. Executives and managers are always coming up with new initiatives and policies. So then the code has to be reworked for non-functional reasons. Or it might just become unused cruft which is supplanted by another new org-overhead feature. And with every core-feature change I make, I must consider the impact to the org-overhead features even though it has no importance to the core use cases.
Users tend to not be able to differentiate between what features they need to accomplish their work and what things are just organizational cruft. So they always ask for (or outright demand) features like this. Nowadays, I try to determine what use case is driving a feature request. If it is not the main purpose of the app, I look for alternative ways to help the user meet those organizational requirements without generating tech debt for me. For example "What if I give you a CSV of the data so you can play with it in Excel?" Or "How about using X product to accomplish that?" Or "Does this really need to integrate with BizTalk?"
Answers like these help the user solve their problem and also avoid writing code that will be a grief to me in the future.
I can nearly guarantee a feature will be technical debt, when a user has asked for it to meet organizational requirements that have nothing to do with the application's normal usage. When I implement it, I always know it is going to be a thorn in my side.
The magical words you hear too often in consulting are "the customer asked for this".
They make you wonder if PMs are doing their job or just saying yes to whatever the customer asks them for :D After a few "yeses" veering off the core product you tend to accumulate a lot of debt already.
Maybe PMs should be UX designers or UX designers should be the ones talking to the customers and let PMs run the day to day of the project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can nearly guarantee a feature will be technical debt, when a user has asked for it to meet organizational requirements that have nothing to do with the application's normal usage. When I implement it, I always know it is going to be a thorn in my side. Executives and managers are always coming up with new initiatives and policies. So then the code has to be reworked for non-functional reasons. Or it might just become unused cruft which is supplanted by another new org-overhead feature. And with every core-feature change I make, I must consider the impact to the org-overhead features even though it has no importance to the core use cases.
Users tend to not be able to differentiate between what features they need to accomplish their work and what things are just organizational cruft. So they always ask for (or outright demand) features like this. Nowadays, I try to determine what use case is driving a feature request. If it is not the main purpose of the app, I look for alternative ways to help the user meet those organizational requirements without generating tech debt for me. For example "What if I give you a CSV of the data so you can play with it in Excel?" Or "How about using X product to accomplish that?" Or "Does this really need to integrate with BizTalk?"
Answers like these help the user solve their problem and also avoid writing code that will be a grief to me in the future.
The magical words you hear too often in consulting are "the customer asked for this".
They make you wonder if PMs are doing their job or just saying yes to whatever the customer asks them for :D After a few "yeses" veering off the core product you tend to accumulate a lot of debt already.
Maybe PMs should be UX designers or UX designers should be the ones talking to the customers and let PMs run the day to day of the project.