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

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
161) Build a product with many types of overrides and the system administrator is left scratching head on how a policy was violated.
162) Build a product where users find ways to share by bypassing the inbuilt mechanisms such as role based access control.
163) Build a product where loopholes are concealed as methods to bypass policy.
164) Build a product that fails to meet compliance rules and have the administrators deploy third party software to fill the shortcomings
165) Build a product that generates so many notifications to clutter up the users’s screens that they can’t get past easily to do their work.
166) Build a product where the ‘select all’ functionality is missing from resource lists.
167) Build a product where the product is overwhelmingly noisy and have administrators grapple with custom rules to modify the execution
168) Build a product without bells and whistles and find that the product goes unnoticed or worse forgotten.
169) Build a product that can generate beautiful reports only to find that product is used more for reports rather than for data accumulation.
170) Build a product that does not allow users to explore broad or deep without administrator privilege and find users dissatisfied.