This is a continuation of the previous post to enumerate funny software engineering practice:

25. Build a product that requires different handlers in different roles driving up costs 

26. Build a product that propagates pain and frustration through partners and ecosystem as they grapple with integration 

27. Build a product that requires significant coding for automations and end users driving down adoption 

28. Build a product that generates more support calls to do even the ordinary  

29. Build a product that generates a lot of sprawl in disk and network usage requiring infrastructure 24x7 watch  

30. Build a product that cannot be monitored because it is a black box 

31. Build a product that says one thing but does another thing 

32. Build a product that requires administrator intervention for authorizing each and every end user activity 

33. Build a product that has an overwhelming size for code churn and improving technical debt 

34. Build a product so big that changes in one component takes hours to integrate with other components 

35. Build a product so big that it involves hierarchical permission requests before corresponding changes can be made in another component 

36. Build a product with significant developer productivity but at the cost of business and market requirements. 

37. Build a product to satisfy the technical managers but fail the product management. 

38. Build a product with little or no documentation on those hidden features that only the maker knows 

39. Build a product which cause impedance mismatch between the maker and the buyer in terms of what the product is expected to do 

40. Build a product that breaks existing usage and compatibility in the next revision.