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

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.
171) Build a product that does not allow authoring policies and find that the usage of the product is almost a chaos.
172) Build a product that does not allow differentiation to users either with policies authored by the administrator or out of the box and find that 10% of the users may matter more than the remaining 90%.
173) Build a product that does not let frequent users form their own customizations or dashboards and find that the product is pushed behind those that can.
174) Build a product that does not allow hands off operations with alerts and notifications and find that the product is not up for renewal.
175) Build a product that does not show captivating charts and graphs and the users migrate to applications that do.
176) Build a product that does not allow users to track their activities especially on shared resources and have the administrator be flooded with calls for lost or missing resources.
177) Build a product that does not allow operations to be distributed and have the planners complain about capabilities.
178) Build a product that does not protect data at rest or in transit and have all the watchdogs show up at the door.
179) Build a product that fails to meet the industry compliance and government regulations and find that the product cannot be sold in certain regions.
180) Build a product that tries to be ahead of the game in emerging trends and find that a significant legacy from partners still requires older technology integration.