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

Build a product to suit the performance goal for a privileged set at the expense of that for others.



Build a product that scales out to high workload but with more faults than before.





Build a product that users do not know worked in certain ways.







Build a product where users are quick to assume something but the product does another thing







Build a product where the defects are hidden in the form of caveats and workarounds


Build a product that scales out to high workload but with more faults than before.

Build a product that is oblivious to market needs as the release cycle grows to years

Build a product that trades-off compute in favor of storage but leaves the onus of moving data to users

Build a product that trades-off storage for compute but never get exercised in routine activities

Build a product that requires proprietary protocol, format or content and have the ecosystem scratch their heads for integration

Build a product that does not work well with others because it does not provide a bridge or a connector

Build a product that is eager to monopolize the market rather than leaving space for better solutions to thrive without sacrificing the competence of the product.

Build a product that is measured by its revenue rather than the mindshare.

Build a product without embracing developers with attractive software developer kits or community editions

Build a product without embracing enticing developers with easy install lite editions for their developmental work

Build a product that does not allow a forum for ideas to be exchanged about the project and find that the home-grown ideas are not appealing enough.

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


Build a product that makes certain users cringe on usability while others don’t



Build a product that requires users to read up on jargons or maneuvers

Build a product where the defects are hidden in the form of caveats and workarounds

Build a product where there is a lot of documentation for workarounds

Build a product where the workarounds are touted as hidden features

Build a product where the users see a spinner wheel every now and then and can’t progress.

Build a product that constantly fails product management but makes promises for the next version

Build a product without any examples for customers to write their own scripts.

Build a product without automation

Build a product with little or no knowledge base or escalation path forcing customers to find help

Build a product with high performance but use it for general purpose

Build a product to suit the performance goal for a privileged set at the expense of that for others.

Build a product that scales out to high workload but with more faults than before.

Build a product that users do not know worked in certain ways.



Build a product where users are quick to assume something but the product does another thing



Build a product where the defects are hidden in the form of caveats and workarounds

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

Build a product that is chatty over the wire driving up costs and failure points.

Build a product that requires its own maintenance chores and components instead of relying on infrastructure

Build a product that requires repeated packing and unpacking of persisted data between its layers

Build a product with redundant parts or techniques to achieve functionality causing discrepancy

Build a product with inconsistency across user interface requiring user to learn different methods

Build a product with significantly poor usability in its user interface.

Build a product that makes users go round and round in circles on the user interface.

Build a product that makes it easy for information disclosure to unintended guests

Build a product that makes users wait on a page forever

Build a product that presents stale information or does not the load the latest state

Build a product that requires users to search for information on the pages

Build a product that makes certain users cringe on usability while others don’t

Build a product that requires users to read up on jargons or maneuvers

Build a product that users do not know worked in certain ways.

Build a product where users are quick to assume something but the product does another thing

Build a product where the defects are hidden in the form of caveats and workarounds

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

Build a product with heavy investments on User Interface and see the target date inevitably moved out.

Build a product with a campaign and have technical debt incurred to keep the architecture sound.

Build a product that causes data loss or unavailability on updates and upgrades.

Build a product that serves a million customers but gets poor reputation when a hacker finds a vulnerability

Build a product that takes man-months to ship out the door only to be told that the features are not baked enough.

Build a product that makes customer pay by signing up for services they didn’t know or want.

Build a product that is over stated or misrepresented to the customer

Build a product that requires significant storage sprawl or cost.

Build a product that requires heavy investments in compute or cloud resource acquisition

Build a product that is chatty over the wire driving up costs and failure points.

Build a product that requires its own maintenance chores and components instead of relying on infrastructure

Build a product that requires repeated packing and unpacking of persisted data between its layers

Build a product with redundant parts or techniques to achieve functionality causing discrepancy

Build a product with inconsistency across user interface requiring user to learn different methods

Build a product with significantly poor usability in its user interface.

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

Build a product without compatibility features that require significant re-investment in downstream systems.

Build a product without automation capabilities and have customers try to reinvent the wheel.

Build a product with the focus on development and leaving the test on the other side of the wall.

Build a product that forces consumers to adopt a technology stack or a cloud vendor so that the subscriptions may accrue income for the maker

Build a product that works weird on the handheld devices

Build a product that does not customize user experience or carry over their profile.

Build a product that makes the user repeatedly sign-in on the same device

Build a product that makes users jump through login interface for each and every site they visit

Build a product that breaks on different browsers or clients with no workarounds for functionality.

Build a product with a base that opens as many vulnerabilities as a swiss cheese.

Build a product with a base that takes many dependencies and breaks when any one of them does

Build a product as a platform over all participating vendor technologies to improve customer experience but be blamed when the defects originate actually from vendors.

Build a product as a platform with plugins but the customer always sees a mix of code rather than a homogeneous consistent product.

Build a product on open source only to incur way more cost than anticipated.

Build a product with heavy investments on User Interface and see the target date inevitably moved out.

Build a product with a campaign and have technical debt incurred to keep the architecture sound.

Build a product that causes data loss or unavailability on updates and upgrades.

Build a product that serves a million customers but gets poor reputation when a hacker finds a vulnerability

Build a product that takes man-months to ship out the door only to be told that the features are not baked enough.

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

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

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

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

Build a product with a revision that makes partner’s integration investments a total loss.

Build a product without compatibility features that require significant re-investment in downstream systems.

Build a product without automation capabilities and have customers try to reinvent the wheel.

Build a product with the focus on development and leaving the test on the other side of the wall.

Build a product that forces consumers to adopt a technology stack or a cloud vendor so that the subscriptions may accrue income for the maker

Build a product that works weird on the handheld devices

Build a product that does not customize user experience or carry over their profile.

Build a product that makes the user repeatedly sign-in on the same device

Build a product that makes users jump through login interface for each and every site they visit

Build a product that breaks on different browsers or clients with no workarounds for functionality.

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.