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. 

Humour behind Software engineering practice
This is an outline for a picture book, possibly with caricatures, to illustrate frequently encountered humour in the software engineering industry:
1) Build a Chimera because different parts evolve differently
2) Build a car with the hood first rather than the engine
3) Build a product with dysfunctional parts or with annoying and incredibly funny messages
4) Build a product with clunky parts that break down on the customer site
5) Build a product that forces you to twist your arms as you work with it
6) Build a product that makes you want to buy another from the same maker
7) Build a product that highly priced to justify the cost of development and have enterprise foot the bill
8) Build a product that features emerging trends and showcases quirky development rather than the use cases
9) Build a product that requires more manuals to be written but never read
10) Build a product that requires frequent updates with patches for security
11) Build a product that causes outages from frequent updates
12) Build a product that snoops on user activity or collects and send information to the maker
13) Build a product that won’t play well with others to the detriment of the customer buying the software
14) Build a product that says so much in legal language that the it amounts to extortion
15) Build a product that requires the customer to pay for servicing.
16) Build a product that splashes on the newspapers when a security flaw is found.
17) Build a product that finds a niche space and continues to grow by assimilating other products and results in huge debt towards blending the mix
18) Build a product with hard to find defects or those that involve significant costs and pain
19) Build a product with ambitious goals and then retrofit short term realizations
20) Build a product with poorly defined specification that causes immense code churn between releases causing ripples to the customer
21) Build a product with overly designed specification that goes obsolete by the time it hits the shelf.
22) Build a product that fails to comply with regional and global requirements and enforcements causing trouble for customers to work with each other
23) Build a product that creates a stack and ecosystem dedicated to its own growth and with significant impairment for partners and competitors to collaborate
24) Build a product that impairs interoperability to drive business
Software engineers frequently share images that illustrate their ideas, feelings and mechanisms during their discussions in building the product. Some of these images resonate across the industry but no effort has yet been undertaken to unify a comic them and present it as a comic strip. Surprisingly, there is no dearth of such comic books and illustrations in parenting and those involving kids.