Toms Brain Dump - My Microblog

I had the idea while listening Lean Startup. There is nice reasoning behind it. 

Globalize the production of toys is dumb. Globalizing the production food even dumber. Few understood globalization properly. Mc Donalds did. Globalize technology but produce goods locally. Mc Donalds has machines, recipes, and processes (all technology) which is distributed globally. It gets its workers and ingredients locally. This is how globalization works.

Peter Thiel is arguing, that the cult around Pythagoras and esoteric truths do not exist anymore. This is not true. Learning advanced math AND be able to apply it brings me in a position, where nobody else is. The combination matters. There are many people who know the same math (or specialized algorithms, etc.) and there are many people who have visions and ideas. There are few who have both and nobody who has the same combination.  So there is still an esoteric truth. It is special knowledge AND the ability to apply it to other knowledge. 

Lean has multiple implications on how to build a software company. From Lean Startup to DevOps. A core component is pull. When writing software I often have to decide if I use pull or push (as design type). Actors are push-based. Given Conway's law, should I use pull in my design? 

void check ( string expected , string actual , bool disabled = false ) { auto res = cv :: imread (actual); auto approved = cv :: imread (expected); auto diff = approved - res; auto sum = cv :: sum (diff); if ( sum [ 0 ]+ sum [ 1 ]+ sum [ 2 ] > 0.0001 && !disabled) { show ( "expeced" , approved); show ( "actual" , res); show ( "diff" , diff); cv :: waitKey ( 0 ); exit ( 1 ); } exit ( 0 ); }

From the Lean Startup book, it does not become clear on the first sight how to apply it to B2B. The trick is to change perspective. The customers are not the companies, but the employees. One company is like a customer segment.

I often hear that TDD is interactive. This is true, but I don't hear this fact anywhere: TDD is interactive It is important.

Kent Beck pointed out at his desired test properties, that tests should be: Behavioral - tests should be sensitive to change in the behavior of the code under test. If the behavior changes, the test result should change. Structure-insensitive - tests should not change their result if the structure of the code changes. Making sure, that these properties hold, is very easy. I check that: When I add/remove behavior I must perform changes in the test-files as well When I change the structure, I don't touch the test files These are powerful heuristics.

A Value Proposition has to be: 10 X better than any other substitute  On "Top 10 Pain List" of our Customer Segment Distributable (CLV/CAC > 3)

C++ Visual Debugging via gdbgui pip install gdbgui gdbgui # opens http://127.0.0.1:5000/ gdbserver localhost:9999 ./exectuable arg1 arg2 arg3 # connect to gdbserver, ip localhost:9999, on gui

I want to integrate these books: Zero To One The Leans Startup Crossing the Chasm Extreme Programming Test-Driven Development (I don't know which) Note the falling level.

The future is on where man and machine work together. They augment each other. Machines do not replace people.  Machine Learning has the potential to make a machine smart enough that it reaches the threshold where a human can work with it. There is a threshold. We try to reach it all the time. This is programming. A norman person can not give instructions to the computer. But if a programmer created a program, the person can.  Machine Learning can much more than the imperative stuff we have done so far. But ML is a waste of time when it comes to tasks where it tries to replace humans. 

I got said my whole life - implicitly and explicitly - that it does not matter what I do. But under the power-law, it really does matter what I do. Diversification is not possible. Luck is workable. See "Good To Great" with the story to the south pole. See "Thinking Fast and Slow" to calculate luck. See Zero To One Chapter 7 - 1:30 min.

Should I use Outside In or should I use Inside Out when doing TDD? Both are my answer. I choose a level where I feel comfortable and work downwards via Outside In and upwards via Inside Out. Don't be dogmatic.

Power Law Defines most (every?) Cells. I could come up with multiple items per cell. Write down only the first as it is the only important. Hard to distinguish when looking in the future. But Model lives.

I can work very slow. If I build the right thing I am much faster. 

Single Piece Flow means Single Feature Flow.  What is a batch then?  Use Build-Measure-Learn per piece. Plan via Learn-Measure-Build.  Only on Feature at a time. 

The value of a company is a very high level. Baby steps are a very low level? How do they relate? They have to. Answering this question could reveal deep insight. Note: Baby steps are not restricted to programming. Are they applicable to every activity? Are they the atoms of a company? 

How to enable Baby Steps? I am not sure of the complete list, but it contains: Enable fast cycles Avoid a rigid system Avoid anything rigid, like a bad type system (I make my own type system) ....

A prerequisite for refactoring is the ability to perform baby steps. The same goes for TDD. Is TDD some kind of subset of Refactoring? Is there a big intersection?

The derivatives of a company's success The success of the company is determined by its value. The value is determined by all future cash flows discounted - as money today is more worth than money in the future. Flywheel concept First derivative: How to increase (future) cash flow. Build Measure Learn

Refactoring is an essential -if not the most critical - skill for many reasons. In the context of a startup, especially. The lifetime of a startup is determined by how many pivots are left. To increase this number, I have to accelerate the "build-measure-learn" cycle. Eric Ries in "The Lean Startup" (p 168, bottom): The company pivoted [...]. On the sufaces the pivot seems quite dramatic in that the company changed its position, its name, and its partner strategy. It even jettisosoned a large propotion of the features it had build. But at its core, a suprising amount stayed the same.  First of all, here ist the hedgehog concept again: But at its core, a suprising amount stayed the same. And here ist the part about refactoring: It even jettisosoned a large propotion of the features it had build. But at its core, a suprising amount stayed the same.  The company had factored its work into a structure. That set allowed a set of features in the form of a prod...