Notes about Kent Beck's substack

These are my notes from the Kent Beck's substack pages. 

Thinkies

All Thinkies are just random Beck's ideas which came with a disclaimer - evaluate them yourself. They just as well might be bad ideas.

Thinkie: Win/Win - well-known. Try to make a decision that is good for everybody.

Thinkie: Survivable? - when you cannot make a decision, think about its reversibility. If you can survive the negative outcome, act in cheapest, fastest way that could generate value. Otherwise mitigate risk.

Thinkie: Your Position - conversation got stuck on resolution, but otherwise seems promising. Try to summarize other party's position in a way they would agree with.

Thinkie: My Perspective - when you have trouble communicating with someone, tell them to look at the problem from your perspective. Sounds quite opposite to the usual advice, but it can help sometimes.

Thinkie: Easy Bit - when stuck on a hard problem, pick an easiest thing which helps and do that. It might unstuck you.

Thinkie: Fun Bit - when stuck on a hard problem, pick a funniest thing and do that. It might unstuck you.

Thinkie: Perfect Setup - when stuck on a problem, list all things which would make the starting situation ideal. Extreme Programming is an example of this pattern.

Thinkie: Hard Problem - when facing a hard problem, list everything you consider part of that problem. Know your enemy.

Thinkie: Put Skin In The Game - try to face the consequences of your decisions. Make Product Owner face their decisions.

Thinkie: Hill Climbing - identify a fitness function for the problem, identify a threshold you are satisfied with, identify the current hill you're climbing, decide whether the top of the hill would meet the threshold, be prepared to switch to a completely different approach if it does not. Reminds me of simulated annealing algorithm.

Thinkie: Analogy - if you have a hard time explaining a situation, use an analogy the targe audience understands.

Separate Idea Generation from Evaluation - don't judge an idea while forming it.

Thinkie: Work Backwards - if you are stuck on a problem trying to more forward. Start at the end and work your way backwards to where you are. This thinkie is the essence of TDD.

Thinkie: Naive Solution - when the team is stuck on a problem trying to product a complicated solution, ask questions like - why is this any harder than naive solution? 

Thinkie: Explore or Extract? - when choosing between doing things the old way or trying the new way, mentally flip a coin and choose. When flipping the chances should not be exactly 50/50, but in favor of solution with higher potential gains.

Thinkie: Latency, Throughput, & Variance - when we are faced with "go faster!" from a manager, it might mean more things. First identify, whether they demand more throughput (more tasks in a month) or less latency (next task faster). These goals are sometimes antagonistic to each other. Then focus on lowering a variance of the goal.

Thinkie: But If You Could... - when stuck thinking something is not possible, ask yourself what if it was possible. What if I could write software without bugs? What if I could deploy more often? Think about what is stopping you and work on that.

Thinkie: Agreements - when in an argument, list all points you agree on. Maybe you'll find there is no argument.

Thinkie: And Then… - you have a decision to evaluate. Ask "and then?". You want to measure developer productivity by lines of code? Ask yourselves what will be the consequences.

Thinkie: One Pass Quickly, One Pass Good - when you have a project with a deadline and fairly independent parts. Scale down each part and deliver something first. Then improve it. The managerial equivalent of Make it run, make it right, make it fast.

Thinkie: Growth Rate, Not Absolute Number - when assessing a trend, look at the growth rate, not the absolute numbers.

Thinkie: Composed Solution - when stuck on a hairy problem, imagine steps needed to tackle it and then consider a solution which has the steps as intermediate results like a compiler.

Thinkie: Scale Down - when stuck on a hard problem, do the thing which brings you closer to the final solution, whatever it is. Maybe it is something you understand well. Maybe something which needs interaction with other team. Maybe something hard to gain confidence. Maybe something which brings more immediate business value.

Thinkie: More General Solution - when stuck on a difficult problem, consider implementing more general solution. It might be easier and it might open up more possibilities for future. Just don't get stuck in a rabbit hole.

Thinkie: Sensitivity Analysis - when you need to tune an operation with many inputs. Pick an input that seems to matter. Vary it (ideally in a model). If it does not help, let it go.

Thinkie: Extrapolate Further - when trying to predict consequences of a trend, try to extrapolate it further than anybody else. If others predict 2 years ahead, then predict 10 years ahead, etc.

Thinkie: Else? - in a situation where a condition has a consequence think of what happens when the condition does not hold. Example is a TCR workflow - test && commit | revert.

Thinkie: Contradiction - a consulting tip - when facing a big, complicated situation in need for improvement, try to find 2 contradictions by the client and gently point out the contradiction.

Thinkie: Incongruence - a consulting tip - when consulting and there is nothing to say, point out discrepancy between what is being said and what is the action.

Thinkie: Just Apply - you have a confusing situation and struggle to make a next step. Take a frame, model or analogy and apply it. Just do it. Ideally in a reversible way. You will learn something from it, even if it is a failure.

Thinkie: Half Wavelength Shift - when you have a multi-step process, try skipping some initial steps. This thinkie is behind TDD.

Thinkie: Self-description - if you have a system which models other systems, try making it model itself. JUnit was test-driven by JUnit. If you have an auction system, try using auctions to pick new features.

Thinkie: Latency Or Throughput? - when we are faced with "go faster!" from a manager, it might mean more things. Identify, whether they demand more throughput (more tasks in a month) or less latency (next task faster).

Thinkie: Reduce Utilization - when you need more to get done, but you are already fully utilized, reduce your utilization. Accept less work for the sprint.

Thinkie: Reduce Variance - when you need more to get done, try reducing variance first, even if it takes more time. That way we can be more responsive. Examples - TDD, tidying.

Thinkie: Grow *Then* Split - when working on a system, first grow it before splitting it to parts. Put production code in the test scope at first. Don't split modules from the beginning. You'll miss opportunity to split after learning something.

Thinkie: Upside/Downside - when having to make a evenly-balanced decision, list the upsides and downsides and if there are no downsides, just do it. Example - Trump realized he cannot win over his non-voters and his voters won't stop voting him, regardless of what he says. So he said whatever he liked to win over the undecided. No downsides.

Thinkie: Envelope Calculation - when you see some numbers data, put them in perspective. Do the math. It might sometimes matter.

Thinkie: Shift Left & Right - when having a process which involves handoffs between roles, think what if the handoff happened sooner or later for given role.

Thinkie: Work/Wait Ratio - when having a process which involves handoffs between roles, draw a diagram of actual waiting included. Then divide.

Thinkie: Separate Observation From Judgement - when getting carried away in a situation, try listing all externally observable facts and then judge the situation.

Thinkie: Special-Cause Versus Common-Cause Variation - if a process fails, find a root cause. Determine if it happens repeatedly or just once. Act accordingly.

Thinkie: Rate-Limiting Resource - during Expand phase of your project, you're nervous about the limits of growth. Think what is the next bottleneck you will face and try to improve that.

Thinkie: Measure What Matters - if your measurements are not bringing any value, try measuring only one thing that really matters to you and try to improve that.

Thinkie: Measure Sooner - you've got nowhere by measuring an end product. Try measuring some intermediate results instead. Just beware that you are risking micro-optimalization this way.

Thinkie: Measure Later - you are measuring a multi-step process and are stuck. Try measuring more end product. E.g. you are measuring programmer productivity. Try measuring profit.

Thinkie: Match the Pipes - if optimizing a multi-step process, find a bottleneck of the pipeline and try to add capacity to it.

Thinkie: Trust the Market - market is acting in an unpredicted way. Ask yourself what would have to be true to market being right and you being wrong? This thinkie just generates ideas for further evaluation.

Thinkie: 1, 10, 100 - when estimating big junk of work, try using 10s of magnitude higher numbers, until you reach too big number and work backwards.

Thinkie: McDonald's - when a group is stalling on decision making, offer a bad solution just for them to accept a better solution.

Thinkie: Parallel Decision - cannot decide between two options? Why not having both? It seems like a slight waste, but generally waste in only fraction of the project lifespan and serves as an insurance.

Thinkie: Defer Decision - don't have enough information to decide? Try deferring the decision for as long as possible.

Thinkie: Force Decision - you have a decision not being made for no good reason. If we have to decide today, what would the decision be?

Thinkie: End To End - if you have a layered project, try going end to end for one tiny feature instead. A vertical slice.

Thinkie: Compared to What? - when you hear a judgement without a context, ask Compared to What? Will it be worse than a status quo?

Thinkie: Tradeoff - when someone is trying to maximize some variable, find the other side of the tradeoff.

Thinkie: Half in Half - if you have a deadline, ask which half they want to see in the half-time. This is Beck's favorite thinkie.

Thinkie: Customer's Voice - when a team is chaotic because of listening to too many input requirements and getting nothing done, dedicate a person for communication to get at least something done.

Thinkie: Dependency Merging - process is blocked by an external entity. Merge with part or whole of the entity. Send a couple of staff there, or invite couple of their staff here.

Thinkie: Break Dependency - when a dependency on another team is slowing you down, consider getting rid of that dependency. Either fix the issue yourself in their code, or implement the dependency on your own.

Thinkie: Project Buffer First - when planning a project with a deadline, start by adding a buffer.

Thinkie: Abundance - you don't have enough time to do things right? What if you did have enough time? What would you do?

Thinkie: Personal Feedback - use the software you are building yourself.

Thinkie: Direct Feedback - you have many communication layers between programmers and end users? What if the programmers spoke directly to end users?

Thinkie: Serialize - when doing multiple projects in parallel, try focusing whole team on doing them in serial instead.

Thinkie: Obviously... - when someone starts a sentence with Obviously..., imagine what if they were wrong? Maybe the thing is no longer true. Maybe it is true only sometimes. Maybe the opposite will be considered creative or even valuable.

Thinkie: Reverse Phrase - when a phrase has two parts, try to reverse them and evaluate the result.

Thinkie: Laughter - when you say an idea and you hear a nervous laughter in response, take that idea seriously.

Thinkie: Can't/Because - if you hear excuses, try to reverse them. E.g. We cannot release often because we would introduce too many bugs. So if we have less bugs, we can release after every change.

Book Chapters and Other Hints

The first step of TDD is a complete (not partial) list of test cases for the desired feature. The list is as complete as possible. You know when you are done because the list is complete. It is a common misunderstanding to make the list just partial.

Refactoring: Constructor <-> Builder - Beck only advocates for Builder, if there are optional parameters involved in Constructor. Otherwise he thinks Constructor is more appropriate. I disagree. The Builder is almost always more readable than Constructor for 3+ parameters.

Refactoring: Boolean Parameter To Switches - if the API has a boolean parameter, refactor to multiple APIs for each variant. If the new API is less usable, refactor back to boolean parameter.

Refactoring: Boolean In Constructor <-> Subclasses - if you have boolean parameter in your constructor, consider creating a subclass for the use-case. 

"Good" Design is a simple design. Heuristics for simple design are in the wiki.

Hinge - for each hard change, first make the change easy (warning: this may be hard), then make the easy change.

TT? Chapter: Fields Object - when having a repeated set of fields in objects, consider grouping them into a separate class. E.g. Period class instead of repeated validFrom and validTo.

TT? Chapter: One Principle, One Technique - when the project is past its fast feedback stage, new features can start coming a little slower. We can invest more in good design. The Safety Principle - almost always choose safety over efficiency. To implement refactoring safely, we implement Parallels Technique - we add a new way along the old way of doing things. Then we gradually remove the old way.

Surprise Factory: Cohesion: Coupling’s B Side - remember Constantine's equivalence? Cost of software is roughly equal to cost of change and that is roughly equal to cost of coupling. When trying to lower coupling seems too hard, try increasing cohesion instead.

The 3X Model - Explore / Expand / Extract. In Explore phase, you are experimenting trying to find a market fit. In Expand mode, you try to survive while scaling up. In Extract mode, you try to reduce costs of living. Software Design is mostly for the Extract phase. If your experiment cannot fail, then you know you are not in the Explore stage anymore.

How to spot sketchy people quickly? Controlling people often say things like "It didn't happen.", "It's not that bad.", "It's your fault anyway."

Tradeoffs - they contain goal, control, response curve and counter response curve. Beck sees them binary - two options only. 

YAGNI. Always try to do the simplest thing that could possibly work.

AI and Software Development

AI is not going to replace us. Business people will state their desires in plain English? I don't think so. This idea is not new. It was called COBOL. CASE. 4GL. CASE. Etc.

Inventions, like efficient steam engine did not mean reduction of consumption of coal, but the opposite. If we make programming cheaper, it will lead to more programming and more need for programmers.

AI might be useful for learning / growing instead of dumbing us down. It is not used this way yet.

All AI demos are about adding new features. What about keeping structure healthy? Without that, we will need to program the whole thing from scratch every time. Two favorite Beck's questions: "What does the structure need to make this following feature easy to implement? How can we get there in tiny safe steps?"

Does AI really shorten the feedback cycle? AI makes bigger and bigger decisions. How do we know they are the right ones? Where is the feedback loop? How can AI help to connect programmers with common interests?


Comments

Popular posts from this blog

Notes about the Clean Architecture book

Notes about the Building Microservices

Notes about A Philosophy of Software Design