Skip to content

Hypowork

Dennis Lee edited this page Aug 23, 2024 · 1 revision

Introduction

Recall that I don't use traditional frameworks, hence I always end up using my own framework, i.e. options board, or BHAG framework. There are no categories or buckets within my framework.

Using the analogy of decision trees or clustering, the boundaries of my categories are not well-defined, but each category is a self-discovery process that encapsulates each evolving risk, while the reward may fluctuate randomly.

Hypowork Digest

This Hypothesis framework will be driven by a short written thesis, in the form of a newsletter, namely Hypowork Digest.

The main reason that I don't use a blog is because I could write about several ideas that are short and disconnected, while a blog typically is written around several connected ideas. In other words, a newsletter is a collection of tiny blog snippets.

  • Create a cluster based on a self-discovery process inspired by some literature
    • Create each mini-cluster (hypothesis) based on FOUR (4) possible branches
      • Integrate user story
      • Integrate bloat
      • Shape user story
      • Shape bloat
    • Rank all your stories in decreasing satisfaction
      1. Shape user story
      2. Integrate user story
      3. Shape bloat
      4. Integrate bloat
  • Shape or write your cluster based on a self-discovery process
    • Minimal Intentional Product (MIP) ensures that satisfaction improves with minimal risk.
      1. Shape user story
      2. Integrate user story
    • Full Stack Product (FSP) ensures that the complexity does not increase significantly in proportion to the reward. 3. [ ] Shape bloat 4. [ ] Integrate bloat

Objectives

Let's break it down to friendly and digestable points.

  • There is no well-defined category in each digest, as each category is a self-discovery process that depends on the collection of written hypothesis.
  • Develop each hypothesis around one idea, but it may reference other ideas within the same digest or previous digests.
  • Rank hypotheses that will improve satisfaction, in other words by risk
    • Incorrect True (IT)
    • Correct True (CT)
    • Incorrect False (CF)
    • Correct False (CF)
  • You can further sub-rank each group by complexity from lowest to highest.
  • Suggest one or more methodologies, including tests, for each hypothesis.
  • The hypothesis may be enhanced, though not required, by including an open source repository as a base of the suggested methodology.

This method helps to create a Git-like system for our ideas, rather than using a random access method of bookmarks, Inkdrop notes, PDFs, etc.

Shift to Hypothesor

All my career, I've been known as a Programmer, Developer, Engineer, Manager, etc. However, my real calling is to be a Hypothesor.

My real work starts when I develop a hypothesis.

Step 1 - Develop a hypothesis based on a literature

A hypothesis may be a correct true (CT), correct false (CF), incorrect true (IT), or incorrect false (IF). For our purpose, a hypothesis may be a existing viable feature, existing bloat, non-existant viable feature, non-existant bloat.

Example

  • Allow user to practice "live" trading in real-time is a non-existant viable feature (IT).
  • View paper trade summary and account summary in real-time is a non-existant bloat (IF).
  • Record order details in a custom table is a non-existant viable feature (IT).

An incorrect true (IT) is the most satisfying intangible reward for a hypothesor, because it has uncovered a true that was incorrectly labeled as false.

A correct false (CF) is the least satisfying intangible reward because it is merely a confirmation of a correctly labeled false.

Step 2 - Rank hypotheses

These are ranked hypotheses in decreasing satisfaction:

  1. Non-existant viable feature (IT)
  2. Existing viable feature (CT)
  3. Non-existant bloat (IF)
  4. Existing bloat (CF)

Step 3 - Don't significantly increase complexity

A Minimum Viable Product (MVP) consists of the first two ranked hypotheses:

  1. Non-existant viable feature (IT)
  2. Existing viable feature (CT)

Based on our previous example:

  • Allow user to practice "live" trading in real-time (IT)
  • Record order details in a custom table (IT)

Here is the tricky part for each additional hypotheses that are ranked in the bottom two, we need to ensure that the complexity does not increase significantly in proportion to the reward.

Again, from our previous example:

  • View paper trade summary and account summary in real-time (IF)
  • Allow users to enable multiple EAs from different brokers (IF)

Clone this wiki locally