Saturday, October 5, 2019

This is a continuation of the previous post to enumerate funny software engineering practice:

Build a product to suit the performance goal for a privileged set at the expense of that for others.



Build a product that scales out to high workload but with more faults than before.





Build a product that users do not know worked in certain ways.







Build a product where users are quick to assume something but the product does another thing







Build a product where the defects are hidden in the form of caveats and workarounds


Build a product that scales out to high workload but with more faults than before.

Build a product that is oblivious to market needs as the release cycle grows to years

Build a product that trades-off compute in favor of storage but leaves the onus of moving data to users

Build a product that trades-off storage for compute but never get exercised in routine activities

Build a product that requires proprietary protocol, format or content and have the ecosystem scratch their heads for integration

Build a product that does not work well with others because it does not provide a bridge or a connector

Build a product that is eager to monopolize the market rather than leaving space for better solutions to thrive without sacrificing the competence of the product.

Build a product that is measured by its revenue rather than the mindshare.

Build a product without embracing developers with attractive software developer kits or community editions

Build a product without embracing enticing developers with easy install lite editions for their developmental work

Build a product that does not allow a forum for ideas to be exchanged about the project and find that the home-grown ideas are not appealing enough.


No comments:

Post a Comment