This is a continuation of the earlier posts to enumerate funny software engineering practice:

160) Build a product where there are no applications without involving external software and dependencies and take a hit when any of them in introduce breaking changes
161) Build a product with many types of overrides and the system administrator is left scratching head on how a policy was violated.
162) Build a product where users find ways to share by bypassing the inbuilt mechanisms such as role based access control.
163) Build a product where loopholes are concealed as methods to bypass policy.
164) Build a product that fails to meet compliance rules and have the administrators deploy third party software to fill the shortcomings
165) Build a product that generates so many notifications to clutter up the users’s screens that they can’t get past easily to do their work.
166) Build a product where the ‘select all’ functionality is missing from resource lists.
167) Build a product where the product is overwhelmingly noisy and have administrators grapple with custom rules to modify the execution
168) Build a product without bells and whistles and find that the product goes unnoticed or worse forgotten.
169) Build a product that can generate beautiful reports only to find that product is used more for reports rather than for data accumulation.
170) Build a product that does not allow users to explore broad or deep without administrator privilege and find users dissatisfied.
171) Build a product that does not allow authoring policies and find that the usage of the product is almost a chaos.
172) Build a product that does not allow differentiation to users either with policies authored by the administrator or out of the box and find that 10% of the users may matter more than the remaining 90%.
173) Build a product that does not let frequent users form their own customizations or dashboards and find that the product is pushed behind those that can.
174) Build a product that does not allow hands off operations with alerts and notifications and find that the product is not up for renewal.
175) Build a product that does not show captivating charts and graphs and the users migrate to applications that do.
176) Build a product that does not allow users to track their activities especially on shared resources and have the administrator be flooded with calls for lost or missing resources.
177) Build a product that does not allow operations to be distributed and have the planners complain about capabilities.
178) Build a product that does not protect data at rest or in transit and have all the watchdogs show up at the door.
179) Build a product that fails to meet the industry compliance and government regulations and find that the product cannot be sold in certain regions.
180) Build a product that tries to be ahead of the game in emerging trends and find that a significant legacy from partners still requires older technology integration.

This is a continuation of the earlier posts to enumerate funny software engineering practice:

150) Build a product that requires non commodity parts and hardware and find that customers are trying to pull apart the product to suit their needs.
151) Build a product that throws arcane errors when the users go off the beaten path
152) Build a product that does not guide the user back to the rails when they go off the beaten path
153) Build a product which has all the necessary ingredients for a successful production deployment but find that the secrets used to operate the software are irreplaceable
154) Build a product which has little or no value in terms of data visualization and find the audience looking for alternatives
155) Build a product in parts where one hand makes one part and another makes a different part and both are not coordinated
156) Build a product where the bug count doesn’t seem to come down and find interesting ideas to hide it
157) Build a product with little or no release gates and see the instability reach the customers.
158) Build a product where the fixes go all the way to the customer on the same day but have it repeated until customers make their mind
159) Build a product with breaking changes in published interfaces and the customers complain.
160) Build a product where there are no applications without involving external software and dependencies and take a hit when any of them in introduce breaking changes
161) Build a product with many types of overrides and the system administrator is left scratching head on how a policy was violated.
162) Build a product where users find ways to share by bypassing the inbuilt mechanisms such as role based access control.
163) Build a product where loopholes are concealed as methods to bypass policy.
164) Build a product that fails to meet compliance rules and have the administrators deploy third party software to fill the shortcomings
165) Build a product that generates so many notifications to clutter up the users’s screens that they can’t get past easily to do their work.
166) Build a product where the ‘select all’ functionality is missing from resource lists.
167) Build a product where the product is overwhelmingly noisy and have administrators grapple with custom rules to modify the execution
168) Build a product without bells and whistles and find that the product goes unnoticed or worse forgotten.
169) Build a product that can generate beautiful reports only to find that product is used more for reports rather than for data accumulation.
170) Build a product that does not allow users to explore broad or deep without administrator privilege and find users dissatisfied.

This is a continuation of the earlier posts to enumerate funny software engineering practice:

140) Build a product where the number bug fixes in frequent patches make the customers roll their eyes.
141) Build a product where the product loses data to corruption or loss from disasters bringing on some of the most petulant customers.
142) Build a product where the product does not fully recover from a disaster.
143) Build a product where the data becomes unavailable to users as the system is brought down or performs some task that prevents it from functioning normally.
144) Build a product and find that deployments are increasing data traffic more than they should.
145) Build a product with specific guidance for deployment and see it put to use in manner different from those suggested
146) Build a product with little or no guidance for the choice of deployment model and find the customer’s gravitate towards the easiest one and then try to scale.
147) Build a product with verbose manual and jargon, and find that customers don’t really want to read that.
148) Build a product like a turnkey solution and find that customers who wanted that in the first place now want to customize it.
149) Build a product with automation packaged via scripts and see its adoption grow astronomically.
150) Build a product that requires non commodity parts and hardware and find that customers are trying to pull apart the product to suit their needs.
151) Build a product that throws arcane errors when the users go off the beaten path
152) Build a product that does not guide the user back to the rails when they go off the beaten path
153) Build a product which has all the necessary ingredients for a successful production deployment but find that the secrets used to operate the software are irreplaceable
154) Build a product which has little or no value in terms of data visualization and find the audience looking for alternatives
155) Build a product in parts where one hand makes one part and another makes a different part and both are not coordinated
156) Build a product where the bug count doesn’t seem to come down and find interesting ideas to hide it
157) Build a product with little or no release gates and see the instability reach the customers.
158) Build a product where the fixes go all the way to the customer on the same day but have it repeated until customers make their mind
159) Build a product with breaking changes in published interfaces and the customers complain.
160) Build a product where there are no applications without involving external software and dependencies and take a hit when any of them in introduce breaking changes

This is a continuation of the earlier posts to enumerate funny software engineering practice:



120) Build a product that takes a lot of effort involved in explaining workarounds when a feature could be added.
121) Build a product where the cost of servicing overwhelms the amortized cost of purchase.
122) Build a product where the customers are enticed to subscription model or cloud tenancy only to discover the total cost to be significantly high for developmental activities
123) Build a product where the customers have to deal with two problems simultaneously: on-premise as well as cloud encumbrances
124) Build a product that requires subscription to services and use the legal language in the contract to extort payments
125) Build a product that requires processing power that is only available on desktops.
126) Build a product that is not elastic I’m storage, compute and networking only to be surprised by crowd peak traffic
127) Build a product that has little or no configuration option for sources of input prompting dedicated instances for different use cases
128) Build a product that reveals hidden bugs after warranty period
129) Build a product where the maker funds white hat discovery of vulnerabilities which prompt the customer to upgrade
130) Build a product with changing goals for v1 while the market tide would have lifted any v1 for immediate business need and with a compelling v2 to establish business.
131) Build a product with that has terms of license written in a way that brings more revenue from the same product over time or use.
132) Build a product with so much emphasis on performance that it becomes a nice product in the magic quadrant
133) Build a product with limited or no expansion possibilities for emerging trends and find the technical debt to be rather costly in the next release
134) Build a product with exacting demands for deployment and find the users running away to competitors.
135) Build a product with little or no configuration for toggling features and find that the majority of the functionality is locked down because there is no granularity
136) Build a product with no dedicated management console/portal and find a section of the audience spurned away.
137) Build a product that requires work for integration and find that there are bugs in standalone mode that would have been detected sooner.
138) Build a product which shows errors in a non-deterministic manner and find costs soaring for investigations
139) Build a product where a single bug fix post release as a patch is either too costly or hard to enforce.
140) Build a product where the number bug fixes in frequent patches make the customers roll their eyes.

This is a continuation of the earlier posts to enumerate funny software engineering practice:


110) Build a product that starts to sound discrepant in the ads as releases slip.
111) Build a product that does not uninstall clean
112) Build a product that leaves artifacts even when the customer does not want it
113) Build a product that makes it annoying for the customers to switch out components
114) Build a product that improves security with a trade-off on convenience.
115) Build a product that provides inadequate segregation of user activities or secrets letting others to see the actions taken.
116) Build a product that provides that behaves well in development but fail in production because of deficiencies in system resources.
117) Build a product that is considered golden only to find that the customer has been using an incorrect version
118) Build a product that takes a sweeping approach of solving problems by updating versions while not sufficiently resolving special cases.
119) Build a product that takes does not have sufficient levers to resolve small customer cases.
120) Build a product that takes a lot of effort involved in explaining workarounds when a feature could be added.
121) Build a product where the cost of servicing overwhelms the amortized cost of purchase.
122) Build a product where the customers are enticed to subscription model or cloud tenancy only to discover the total cost to be significantly high for developmental activities
123) Build a product where the customers have to deal with two problems simultaneously: on-premise as well as cloud encumbrances
124) Build a product that requires subscription to services and use the legal language in the contract to extort payments
125) Build a product that requires processing power that is only available on desktops.
126) Build a product that is not elastic I’m storage, compute and networking only to be surprised by crowd peak traffic
127) Build a product that has little or no configuration option for sources of input prompting dedicated instances for different use cases
128) Build a product that reveals hidden bugs after warranty period
129) Build a product where the maker funds white hat discovery of vulnerabilities which prompt the customer to upgrade
130) Build a product with changing goals for v1 while the market tide would have lifted any v1 for immediate business need and with a compelling v2 to establish business.

The benefits of Async stream readers in cache for stream storage:
The cache essentially projects portions of the stream so that the entire stream does not have to scanned from begin to end repeatedly. This mode of operation is different from finding popular stream segments across stream readers.
The cache may use a queue to hold contiguous segments from a stream.
The choice of queue is extremely important for peak throughput. The use of a lock free data structure as opposed to an ArrayBlockingQueue can do away with lock contention. The queues work satisfactorily until they are full. Garbage free Async stream readers have the best response time.
The benefits here are similar to LogAppenders except that they are on write path whole these are in read path.
Asynchronous read together with lock free access and skip level access boost performance. The cache may encounter significant size for each segment and a writer that transfers a segment over the network may take time in the order of hundreds of milliseconds. Instead, having a continuous background import for adjustable window of steam segments tremendously improves the load on the stream store while responding to seek requests on segments

Please refer to the discussion on caching context for stream managers with:

https://1drv.ms/w/s!Ashlm-Nw-wnWvBXkU9jz_Z2EXWLp

and  implementation where it is applicable with: https://github.com/ravibeta/JavaSamples/tree/master/logging

We were discussing the cache usage for stream access:

When the segments in the stream have skip level access by say 2,4,8 adjacent nodes, the cache can access the segments via skip levels and prefetch those that will be read. Skip level access on streams means that we are able to perform as fast as random access over sequential streams.

The cache may use indexes on locations to augment the deficiency of storing record locations in the stream store. This index is merely a translation of the sequential segment number from the stream store in terms of the leaps of the contiguous segments we need to make. And the best way to do that for that particular segment. Given a segment it’s sequential number from the start may be internal to the stream store. However, if that number is available from the stream store to be  mapped with the segment whenever it is cached, then the translation of the location to the segment in terms of skip-level access is straightforward for example the number 63 from start, will require as many multiples of 8 less than target, same with multiples of 4 starting from the position left with the previous step, then multiples of 2 such that they are maximized in that order so that the overall count is least. This computation benefits in bringing ranges based on numbers alone rather than range indexes based on say BTree

Without the location available from the stream store some persistence is needed for the lookup of the segment number for the corresponding segment and usually involves an iteration of all the segments from the store. A hash of the segment may be sufficient for these lookups.

The hierarchical representation of stream segments may be facilitated with other data structures but they tend to centralize all operations. The purpose of skip level access is faster access on the same sequential access so that no other data structures are necessary

Another approach is to maintain the segment numbers on both sides. For example, the cache may have clients that read from the start of the stream up to a targeted segment. The stream store may perform repeated scans as it serialized the client’s accesses to the stream. The cache has the opportunity to bypass the stream store and alleviate the workload on the stream store by providing the segments that are most popular between accesses. As each client presents a target segment number and the stream store presents the segment numbers from the same or different stream, the cache has the opportunity to come up with segment numbers based on relevance via skip level access and priority via its eviction policy. The cache therefore becomes an intelligent agent that does away with redundant scans of streams by the store.

The overlapping interval range between segment numbers is decided by the cache which it uses with skip level access to fetch the segments. Efficient representation of such a range of segments is easy with the same logic as demonstrated for a targeted segment number. In this case, the same algorithm is repeated for begin and end of targeted range and the interval is represented in terms of the skip level access between the start and the end.