House of Cards Style

When you need software to come together super quickly, but you don’t need it to remain together for a long time, or care if it withstands a lot, you can use the light, low-density house of cards style to build it.

You restrict the development to pure glue. If there is any computation that isn’t glue, you do a search for some existing component, download it, and glue it into the overall. The primary development activity is just gluing in as many pieces as you can, as fast as you can.

You configure as little as possible; you change as little as possible. The most important part of it is to avoid any deep or serious thinking. Don’t get curious. If getting some new piece into the code requires understanding how it works, you toss it and move on quickly to the next piece. Fast, low-thought, hacking. Try not to understand the components, don’t consider anything other than all too obvious errors, and don’t worry about any long-term issues. Just throw it all together.

House of Cards only works if the code remains small, so it is suitable for PoC, Demos, or tiny, short-term projects. But they literally collapse like a house of cards if you try to make them any larger.

House of Cards is pure throwaway work. It is far more expensive to evolve or refactor these types of efforts into real systems than to just throw them away and write it all again. Generally, the components don’t fit well or work well with each other, the interface is haphazard -- either really simple or really ugly -- and while it has an incredible number of features, any reasonable user workflow within it is too convoluted to be used regularly.

The work isn’t really wasted if you throw it away, as you did learn a few things from throwing it together, and you get a better sense of the solution space, but the code itself is totally disposable.

The point is to spin something up really quickly to see if it is viable, much like a little clay model of a car design or a little prototype of a machine, before committing to the long and expensive work of doing it for real. The output is a toy and should never be relied on for any critical efforts. Systems need to be engineered as ‘systems’ that hold together and are resilient, that is, a totally different set of skills than just gluing things to each other.

Another example of programming style is:

https://theprogrammersparadox.blogspot.com/2023/04/waterloo-style.html