Business requirements define an N dimensional object that must be implemented via code.
You can often obtain a high resolution view of this object via detailed analysis of production.
As an example (how knowing something about your customer allows you to tune in or change a constraint to be more favorable)
At the extreme, “knowing” your customer’s usage patterns to an extreme extent can lead to pretty extreme optimizations, but you may lose some flexibility in implementation.
When business requirements are poorly defined, or when implementation is too general, you can easily over implement (When you under implement, typically you get a bug report.)
Over specification or fuzzy specification
but over implementation - you don’t get anyone complaining, you get a limited form of Hyrum’s law.
Many people think that the act of specification is the primary job of software engineering in the future, the implementation of the software itself is rapidly dropping, and what is left is figuring out how to help define and specify, in other words, take some fuzzy business requirements, clarify them, and come up with a very detailed specification that fulfills those business requirements.
AI will always have a tough time doing that (for now), because it can be a very fuzzy task to understand what the business requirements actually are.
So let’s get into some concrete examples
- Naive Example no probabilistic data structures involved
- LRU Cache
- Sketching algorithms / Streaming Algorithms (top K, concurrency tracking, etc…)