This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
270) Build a product where the end users trust the product only to be told by hackers and researchers that it is not good enough
271) Build a product where the base line edition tantalizes the developers and the pricey edition purchase is delayed.
272) Build a product where the price of the top line spurns away some of the potential buyers
273) Build a product where the full-service solution it provides makes the customers feel like pampered.
274) Build a product where the revenue generation comes from end-user licenses sold rather than pay per use or vice versa and the company makes more money than the customers are aware
275) Build a product where the key-secrets need to be rotated but cannot be kept safe externally
276) Build a product that requires elaborate setup but find little utilization of most of the components
277) Build a product that advertises as a plug and play but doesn’t work with half the platforms
278) Build a product where the error code and error message leave the customer longing for divine intervention
279) Build a product where the mashup of technologies makes the product clunky to operate
280) Build a product where the state is stored in some form of file system or database only to find that they can be compromised in most deployments.
281) Build a product that bills incorrectly for the resources used.
282) Build a product that eavesdrops even when you are not anticipating
283) Build a product that hides sinister motives behind purported automation
284) Build a product that showcases attractive charts and graphs that never occur
285) Build a product that has fine grained automations leaving the developers delighted to build their own but at the expense of the organization.
286) Build a product that has apis for everything but they keep going through changes
287) Build a product that adds more work for the owners where the cost for the total ownership is swept under the open source tag
288) Build a product where the emphasis is on cloud friendliness but never bothers to state the assumption of being a tenant in the cloud comes with subscription cost
289) Build a product that is like an appliance sold to end-users, customers and their datacenters with little or no visibility to the business except on the budget
290) Build a product that attracts so much attention for its flaws that it becomes a baseline for the next version.