Code Simplicity

The Fundamental Philosophy of Debugging

July 17, 2017

Sometimes people have a very hard time debugging. Mostly, these are people who believe that in order to debug a system, you have to think about it instead of looking at it. Let me give you an example of what I mean. Let’s say you have a web server that is silently failing to serve pages to users 5% of…

Refactoring is About Features

May 2, 2017

There’s a point that I made in the book but which I have had to point out to people a few times since then, and so I wanted to emphasize it a bit more. When you clean up code, you are always doing it in the service of the product. Refactoring is essentially an organizational process (not the definition of…

Effective Engineering Productivity

April 4, 2017

Often, people who work on engineering productivity either come into conflict with the developers they are attempting to help, or spend a long time working on some project that ends up not mattering because nobody actually cares about it. This comes about because the problem that you see that a development team has is not necessarily the problem that they…

Measuring Developer Productivity

January 3, 2017

Almost as long as I have been working to make the lives of software engineers better, people have been asking me how to measure developer productivity. How do we tell where there are productivity problems? How do we know if a team is doing worse or better over time? How does a manager explain to senior managers how productive the…

Two is Too Many

December 21, 2015

There is a key rule that I personally operate by when I’m doing incremental development and design, which I call “two is too many.” It’s how I implement the “be only as generic as you need to be” rule from the Three Flaws of Software Design. Essentially, I know exactly how generic my code needs to be by noticing that…

How to Handle Code Complexity in a Software Company

January 6, 2015

Here’s an obvious statement that has some subtle consequences: Only an individual programmer can resolve code complexity. That is, resolving code complexity requires the attention of an individual person on that code. They can certainly use appropriate tools to make the task easier, but ultimately it’s the application of human intelligence, attention, and work that simplifies code. So what? Why…

Test-Driven Development and the Cycle of Observation

May 9, 2014

Today there was an interesting discussion between Kent Beck, Martin Fowler, and David Heinemeier Hansson on the nature and use of Test-Driven Development (TDD), where one writes tests first and then writes code. Each participant in the conversation had different personal preferences for how they write code, which makes sense. However, from each participant’s personal preference you could extract an…

The Purpose of Technology

February 14, 2014

In general, when technology attempts to solve problems of matter, energy, space, or time, it is successful. When it attempts to solve human problems of the mind, communication, ability, etc. it fails or backfires dangerously.…

The Secret of Fast Programming: Stop Thinking

December 10, 2013

When I talk to developers about code complexity, they often say that they want to write simple code, but deadline pressure or underlying issues mean that they just don’t have the time or knowledge necessary to both complete the task and refine it to simplicity. Well, it’s certainly true that putting time pressure on developers tends to lead to them…

Make It Never Come Back

November 19, 2013

When solving a problem in a codebase, you’re not done when the symptoms stop. You’re done when the problem has disappeared and will never come back. It’s very easy to stop solving a problem when it no longer has any visible symptoms. You’ve fixed the bug, nobody is complaining, and there seem to be other pressing issues. So why continue…