> Difficulty of implementation should never be a deciding factor in whether or not to address the needs of the users.
Really?
Never ?
I've got to disagree with this.
All possible changes that one might make to a codebase should be evaluated in terms or ROI (return on investment).
If a 1 day project creates X value, and a 3 day project creates 5 X value, then the latter project delivers more bang for the buck, and that's where resources should be allocated.
To ignore the amount of work that a task takes is to blind oneself and discard rationality.
Sure, the generalized statement is a bit iffy, but in this case, the number of users, ease of implementation, and utility of the feature make the lack of constants inexcusable. Bon's argument sounds pretty silly.
Explain to me why we should be stuck with one standards group's idea of how to organize style information, when an app-layer implementation of the same idea imposes no cost to end users, adds flexibility, and doesn't force the whole web to rush to standardize an idea that sees less than 1% adoption among all web apps today?
In your example you are deciding between delivering two different valuable improvements, which is fine. Bos' is deciding to do nothing just because the one solution presented to him might be hard. That's inexcusable.
Comments
> Difficulty of implementation should never be a deciding factor in whether or not to address the needs of the users.
Really?
Never ?
I've got to disagree with this.
All possible changes that one might make to a codebase should be evaluated in terms or ROI (return on investment).
If a 1 day project creates X value, and a 3 day project creates 5 X value, then the latter project delivers more bang for the buck, and that's where resources should be allocated.
To ignore the amount of work that a task takes is to blind oneself and discard rationality.
That may be true for a particular solution. If a solution doesn't make sense in ROI, then the solution should be rejected.
However, if the customers have a specific pain point, our jobs are to alleviate that pain, not sit around and say, "It's too hard."
Sure, the generalized statement is a bit iffy, but in this case, the number of users, ease of implementation, and utility of the feature make the lack of constants inexcusable. Bon's argument sounds pretty silly.
Explain to me why we should be stuck with one standards group's idea of how to organize style information, when an app-layer implementation of the same idea imposes no cost to end users, adds flexibility, and doesn't force the whole web to rush to standardize an idea that sees less than 1% adoption among all web apps today?
In your example you are deciding between delivering two different valuable improvements, which is fine. Bos' is deciding to do nothing just because the one solution presented to him might be hard. That's inexcusable.