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

140) Build a product where the number bug fixes in frequent patches make the customers roll their eyes.
141) Build a product where the product loses data to corruption or loss from disasters bringing on some of the most petulant customers.
142) Build a product where the product does not fully recover from a disaster.
143) Build a product where the data becomes unavailable to users as the system is brought down or performs some task that prevents it from functioning normally.
144) Build a product and find that deployments are increasing data traffic more than they should.
145) Build a product with specific guidance for deployment and see it put to use in manner different from those suggested
146) Build a product with little or no guidance for the choice of deployment model and find the customer’s gravitate towards the easiest one and then try to scale.
147) Build a product with verbose manual and jargon, and find that customers don’t really want to read that.
148) Build a product like a turnkey solution and find that customers who wanted that in the first place now want to customize it.
149) Build a product with automation packaged via scripts and see its adoption grow astronomically.
150) Build a product that requires non commodity parts and hardware and find that customers are trying to pull apart the product to suit their needs.
151) Build a product that throws arcane errors when the users go off the beaten path
152) Build a product that does not guide the user back to the rails when they go off the beaten path
153) Build a product which has all the necessary ingredients for a successful production deployment but find that the secrets used to operate the software are irreplaceable
154) Build a product which has little or no value in terms of data visualization and find the audience looking for alternatives
155) Build a product in parts where one hand makes one part and another makes a different part and both are not coordinated
156) Build a product where the bug count doesn’t seem to come down and find interesting ideas to hide it
157) Build a product with little or no release gates and see the instability reach the customers.
158) Build a product where the fixes go all the way to the customer on the same day but have it repeated until customers make their mind
159) Build a product with breaking changes in published interfaces and the customers complain.
160) Build a product where there are no applications without involving external software and dependencies and take a hit when any of them in introduce breaking changes