This is a continuation of the earlier posts to enumerate funny software engineering practice:



120) Build a product that takes a lot of effort involved in explaining workarounds when a feature could be added.
121) Build a product where the cost of servicing overwhelms the amortized cost of purchase.
122) Build a product where the customers are enticed to subscription model or cloud tenancy only to discover the total cost to be significantly high for developmental activities
123) Build a product where the customers have to deal with two problems simultaneously: on-premise as well as cloud encumbrances
124) Build a product that requires subscription to services and use the legal language in the contract to extort payments
125) Build a product that requires processing power that is only available on desktops.
126) Build a product that is not elastic I’m storage, compute and networking only to be surprised by crowd peak traffic
127) Build a product that has little or no configuration option for sources of input prompting dedicated instances for different use cases
128) Build a product that reveals hidden bugs after warranty period
129) Build a product where the maker funds white hat discovery of vulnerabilities which prompt the customer to upgrade
130) Build a product with changing goals for v1 while the market tide would have lifted any v1 for immediate business need and with a compelling v2 to establish business.
131) Build a product with that has terms of license written in a way that brings more revenue from the same product over time or use.
132) Build a product with so much emphasis on performance that it becomes a nice product in the magic quadrant
133) Build a product with limited or no expansion possibilities for emerging trends and find the technical debt to be rather costly in the next release
134) Build a product with exacting demands for deployment and find the users running away to competitors.
135) Build a product with little or no configuration for toggling features and find that the majority of the functionality is locked down because there is no granularity
136) Build a product with no dedicated management console/portal and find a section of the audience spurned away.
137) Build a product that requires work for integration and find that there are bugs in standalone mode that would have been detected sooner.
138) Build a product which shows errors in a non-deterministic manner and find costs soaring for investigations
139) Build a product where a single bug fix post release as a patch is either too costly or hard to enforce.
140) Build a product where the number bug fixes in frequent patches make the customers roll their eyes.