This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice :
230) Build a product where the defects flow to the core of the product from any surface area because it is easier to consult the expert than to do what it takes to resolve the defect upfront
231) Build a product where the core is shielded by layers upon layers and defects in the core lead to workarounds and complexity in outer layers
232) Build a product where the clients can’t keep up with the breaking changes in the server both before and after release
233) Build a product where there are proprietary protocols between components and find that the protocol grows in complexity as opposed to following open, published and popular protocols
234) Build a product where the components fail silently or worse lie when they fail.
235) Build a product where the callers have no way to figure out whether the callee did the task
236) Build a product where the caller does not allow differentiation of callees and find that there is no way to put an expedient fix specific to certain callee.
237) Build a product where there is no protection of boundary such as between layers or external endpoints and find all kinds of security vulnerabilities afterwards
238) Build a product that is well thought through and find the solution to be too elegant and simple to describe.
239) Build a product that provides no mechanism for callers to inject tracers and find that the callers have to rely on communications with the experts
240) Build a product where the communication to explain how the product works consumes bulk of the time that could have otherwise been spent on test and development.
241) Build a product where the manual for the product is bulky and can become a headrest
242) Build a product where the user interface real estate is all cluttered up and there is no room to display anything new.
243) Build a product where users register through a third-party identity provider and cannot login to the product if there is an outage
244) Build a product where the home page is a mashup of different websites and the user has to squint at a small portion of the screen
245) Build a product where the forms are so big and large they are never completed in one sitting
246) Build a product that seems to have one form after another to fill on every page.
247) Build a product that shows ads or campaigns that distract the user from their workflows
248) Build a product that makes recommendations even when you want it to stop.
249) Build a product that chronicles every order and makes it creepy to anticipate your next order
250) Build a product that looks simple but when you click the advanced options, it becomes overwhelming.
230) Build a product where the defects flow to the core of the product from any surface area because it is easier to consult the expert than to do what it takes to resolve the defect upfront
231) Build a product where the core is shielded by layers upon layers and defects in the core lead to workarounds and complexity in outer layers
232) Build a product where the clients can’t keep up with the breaking changes in the server both before and after release
233) Build a product where there are proprietary protocols between components and find that the protocol grows in complexity as opposed to following open, published and popular protocols
234) Build a product where the components fail silently or worse lie when they fail.
235) Build a product where the callers have no way to figure out whether the callee did the task
236) Build a product where the caller does not allow differentiation of callees and find that there is no way to put an expedient fix specific to certain callee.
237) Build a product where there is no protection of boundary such as between layers or external endpoints and find all kinds of security vulnerabilities afterwards
238) Build a product that is well thought through and find the solution to be too elegant and simple to describe.
239) Build a product that provides no mechanism for callers to inject tracers and find that the callers have to rely on communications with the experts
240) Build a product where the communication to explain how the product works consumes bulk of the time that could have otherwise been spent on test and development.
241) Build a product where the manual for the product is bulky and can become a headrest
242) Build a product where the user interface real estate is all cluttered up and there is no room to display anything new.
243) Build a product where users register through a third-party identity provider and cannot login to the product if there is an outage
244) Build a product where the home page is a mashup of different websites and the user has to squint at a small portion of the screen
245) Build a product where the forms are so big and large they are never completed in one sitting
246) Build a product that seems to have one form after another to fill on every page.
247) Build a product that shows ads or campaigns that distract the user from their workflows
248) Build a product that makes recommendations even when you want it to stop.
249) Build a product that chronicles every order and makes it creepy to anticipate your next order
250) Build a product that looks simple but when you click the advanced options, it becomes overwhelming.
No comments:
Post a Comment