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


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.

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.

Build a product that leaves out the details of the use cases which the customers would find most relevant to their needs and find out afterwards how much cost it would have saved.

Build a product that does not explain what it cannot do but keep finding that they try it  anyway. .

Build a product with little or no support for administrators to configure against inappropriate usages.

The Kubernetes Event generation, filtering and propagation considerations for component owners and destination architect:
1) A Kubernetes Label is what makes a regular K8s (short for Kubernetes) event a Selected event.  This label is not something that the Selected team can do without. It is their criteria in their configmap with saying “matchOn” with a name. They cannot create alternate criteria that says matchOn level = critical or events with remedies.  This is a label that they need the event generators to decide and add-on. Therefore, we must work with some of their limitations here. At the same time the event promotion rules is a good idea and having a set for criteria for the rules is helpful to anyone. If the criteria is specific to a component or to Selected, then its best to put it in their corresponding ConfigMap.
2) 1) does not mean we have to generate Selected events only. In fact, we should generate K8S events because with or without the criteria for Selected, this only improves the diagnostics of the component and it is something that only the component owners know best.
3) The advice for the component owner has been generate more K8s events. However, the Kubernetes also raised K8s events for almost all resources. Therefore, there should not be any overlap between the events raised by the Kubernetes by default and those from the component
4) In the past, we have discussed a layered approach to publishing K8s events, promoting K8s events to Selected events which in turn gets notified to Special events . There has been speculation about how Selected picks these events or should be doing so in the future. I suggest that picking and promoting events based on matchOn and rules is something that any layer can do. Therefore, it is better to separate the event generation from the event propagation. These operations are not the dedicated responsibility of any single component or layer but something that can be performed by each if they choose as such.
5) The event generation has also been different from different components but anything to do with the operational aspect is welcome. The difference has been to justify emitting events to authoring the resources with states so that Kubernetes automatically emits the events.
6) In some cases, the native K8s events don’t have enough information or message. They could be enhanced with identifiers and names that may assist SRS and other consumers by finding everything in the event itself.
7) The most important aspect for any specific component has been 5) and 6) above because it handles requests for all service instances and service bindings which are dynamic during the lifetime of the product and the source for most troubleshooting tickets.
8) As the service catalog does not capture the context in which these instances and bindings are created, we have an opportunity to improve these from this component.
9) Lastly, I want to add that the handlers of Special events are concerned about having few events rather than a flood of events. Unlike other products which don’t have infrastructure like Kubernetes, events can be numerous. Therefore, this restriction for number of events must be removed from both special events handlers and user interface otherwise the customers will not benefit as much from these events.

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.