Sale-Oriented Programming - [Are We There Yet?]


#1

Sometimes I like to cook.
Recipes like, mix salt (2ts) and water (1cup), are really rare (I never met).
Usually it’s a bit more complex.

Sale is also oversimplification.
Booking, recognition, collection is much better model.
Add backlog and bad debt reserves and you have something to live with.

I sense we are too focused on terse representation, and don’t pay enough attention to verbose in our current state [of software development]. .

My rule of thumb (number of elements in scope):

  • 1 (aka root of DAG) - just another tag/label/name, implicit oversimplification
  • 4-8 (aka direct causes/necessities, level -1) - hope it will be sufficient (usually it’s not)
  • 20-35 (aka including level -2, “people who are really serious about software should make their own hardware”)
  • more that 35 - I just can’t handle that

Edna/alda use default/initial values (aka context):
https://oakes.github.io/edna/cljs/edna.examples/intro-2-attributes.html
Nine.

Pedestal call it terse and verbose syntax:
http://pedestal.io/reference/routing-quick-reference#_terse_syntax
Thirteen.

I prefer costs avalanche (aka yak shaving), costs (aka options) superposition, distances/costs to margins of not dying (aka safety) and default values instead of complexity (incidental or/and intrinsic).