4 ms·

I really think it is important to say 'No' and agree with the author but I think you can do this if the product you propose can be extended. I think the framew

I really think it is important to say 'No' and agree with the author but I think you can do this if the product you propose can be extended. I think the framework/product should propose some configurability or some extension points. Then your product can stay pure and people can still adapt it to fit their need. If you propose an API then it can be integrate with other product/tools/developmnent. If it embark scripting ability then the user can modify it's behaviour...

mason55 11y ago
Even still you have to be intelligent about the interfaces because you'll have to support them for approximately the rest of time immemorial.
- cakes 11y ago
  The difference when developing some interfaces like that can be whether you "consume" them yourself or not. Building something without a known user base/use case (where the idea was just 'that sounds cool') and supporting it forever can lead to _different_ design decisions compared to those where you go "Hhmmm...well if we build it this way it is really good/bad and we can use it easier." Whatever you end up with, though, is definitely a "support forever" situation.
- DomreiRoam 11y ago
  True, but you can still use something like features depreciation in java.
127001brewer 11y ago
My impression was don't over-extend a product, such as Evernote or LinkedIn have done, and try to keep your product focused - similar to the Unix philosophy of "Do One Thing and Do It Well".
- dividuum 11y ago
  I'm pretty sure you implied that, but just to be sure, I'd like to point one thing out: Doing one thing well won't help your product if there is no way to use other "things" that do their thing well. It seems like products often suffer from feature creep when there is no common way of interfacing with external products. I haven't used Evernote, but maybe the lack of proper ways to interface with external software on each platform was the main reason for them becoming bloated. Android with the intends system seems like one way of doing that but I feel it might not be powerful enough for most problems. Also you have no good way of guaranteeing the user experience if your surroundings might change in unpredictable ways. So it's not that easy.
- DomreiRoam 11y ago
  Agree 100% . I think also by keeping the perimetre of the product under control; it is easier to understand for the user and the developer, it satisfy the principle of less surprise; it keep the vision and the focus in the long term and in then end make clearer what the product does and what cvalue it brings. I would say my reflection to achieve this would be to define - what is the product perimetre - what architecture/design principle will bring you capabilities and useful abstraction - what are the best interface/extension points for allowing user to extend the usage easily Then hard work, iteration and pivot
- i386 11y ago
  Not always possible. Even in the unix world you need to use multiple single purpose tools to get something useful done and therein friction lies.

mason55 11y ago

Even still you have to be intelligent about the interfaces because you'll have to support them for approximately the rest of time immemorial.

cakes 11y ago
The difference when developing some interfaces like that can be whether you "consume" them yourself or not. Building something without a known user base/use case (where the idea was just 'that sounds cool') and supporting it forever can lead to _different_ design decisions compared to those where you go "Hhmmm...well if we build it this way it is really good/bad and we can use it easier." Whatever you end up with, though, is definitely a "support forever" situation.
DomreiRoam 11y ago
True, but you can still use something like features depreciation in java.

127001brewer 11y ago

My impression was don't over-extend a product, such as Evernote or LinkedIn have done, and try to keep your product focused - similar to the Unix philosophy of "Do One Thing and Do It Well".

dividuum 11y ago
I'm pretty sure you implied that, but just to be sure, I'd like to point one thing out: Doing one thing well won't help your product if there is no way to use other "things" that do their thing well. It seems like products often suffer from feature creep when there is no common way of interfacing with external products. I haven't used Evernote, but maybe the lack of proper ways to interface with external software on each platform was the main reason for them becoming bloated. Android with the intends system seems like one way of doing that but I feel it might not be powerful enough for most problems. Also you have no good way of guaranteeing the user experience if your surroundings might change in unpredictable ways. So it's not that easy.
DomreiRoam 11y ago
Agree 100% . I think also by keeping the perimetre of the product under control; it is easier to understand for the user and the developer, it satisfy the principle of less surprise; it keep the vision and the focus in the long term and in then end make clearer what the product does and what cvalue it brings. I would say my reflection to achieve this would be to define - what is the product perimetre - what architecture/design principle will bring you capabilities and useful abstraction - what are the best interface/extension points for allowing user to extend the usage easily Then hard work, iteration and pivot
i386 11y ago
Not always possible. Even in the unix world you need to use multiple single purpose tools to get something useful done and therein friction lies.