/Kent Beck

Slow Deployment Causes Meetings tl;dr: “If you want more changes to get through, you need to expand the far end of the hose, to increase deployment capacity. You can do this the hard way, by reducing the deployment cycle and dealing with the ensuing chaos, or the harder way, by increasing the number of changes per deployment (better tests, better monitoring, better isolation between elements, better social relationships on the team). But don’t try to reduce overhead. That’ll just lead inevitably to a series of meetings on how to reduce meetings. At least that will keep you from trying to ship too much code, though.”

featured in #556


The Life-Changing Magic Of Tidying Up Code tl;dr: “Tidying up works through a series of small, safe steps. In fact, Rule #1 is If it’s hard, don’t do it. I used to do crossword puzzles at night. If I got stuck and went to sleep, the next night those same clues were often easy. Instead of stressing about the big effects I want to create, I am better off just stopping when I encounter resistance.” Kent shares his approach. 

featured in #551


Scope Management 101 tl;dr: (1) Plan incrementally. The team, every week, must be prepared to decide what to do that week. Some planning processes are so painful, or require the sign-off of such overworked people, that contemplating planning weekly causes sweat to bead on foreheads. Learn how to plan lightly as to tactics & resolutely as to goals. (2) Deliver incrementally. The team must be prepared to support production while developing. This in turn requires rock solid reliable tidying & prioritizing the fixing & preventing of defects.

featured in #549


The Impossibility Of Making An Elite Engineer tl;dr: “While all elite engineers face these contradictions, there are as many paths through them as there are engineers.” Kent discusses the pattern he’s seen elite engineers take on with the following: (1) Longevity and diversity of projects. (2) Success and failure. (3) Mentored and self-directed. (4) Urgency and slack. 

featured in #549


The Impossibility Of Making An Elite Engineer tl;dr: “While all elite engineers face these contradictions, there are as many paths through them as there are engineers.” Kent discusses the pattern he’s seen elite engineers take on with the following: (1) Longevity and diversity of projects. (2) Success and failure. (3) Mentored and self-directed. (4) Urgency and slack. 

featured in #548


Ad Hoc Infrastructure tl;dr: “My intention in this note is to reclaim the phrase ad hoc from those who use it as a pejorative, especially as applied to infrastructure. Instead, building infrastructure ad hoc is the safest, most efficient strategy. It carefully balances the risks inherent in creating infrastructure, stages investment, and realizes economies of scale.”

featured in #546


Enthusiasm: Managing Our Most Precious Resource tl;dr: “The enthusiasm-enhancing way to allocate people to tasks is to let the people allocate themselves. They have context, in the form of accountability and purpose and approximate proportions, but to preserve enthusiasm they must make their own decision. And a fired up engineer is five times (for some value of five) as valuable as that same engineer just putting in hours.”

featured in #543


Humans >> Data tl;dr: Kent discusses his stance on measuring developer productivity: “Looking at numbers is one way to pay attention, but it’s a limited, biased, & temporary way. There is no perfectly balanced set of metrics that will “drive” better behavior. As soon as such a set is introduced, clever folks will begin to subvert the numbers to their own benefit, they aren’t trying to make things worse for their colleagues, users, & investors — that’s just how it works out.” He discusses the value of managing humans over data. 

featured in #540


Responsible Slack tl;dr: “If you are preparing a schedule, build in slack. If you are depending on a schedule, identify the slack before passing on the commitment. If you are reviewing a schedule, ask where the slack lives. If there isn’t any, ask what happens if an appropriate amount of slack is added. If the consequences of slack aren’t acceptable, either cut scope or get over it.”

featured in #536


Standups: Individual → Teammate tl;dr: Kent discusses his reasoning behind standups. “Treating standup meetings as a technical solution to a technical problem — we need to communicate this many bits of information to this many people as efficiently as possible — misses the real point. We’re people. With needs. The better those needs are met, the better we can meet the needs of others.”  

featured in #530