I just found a great example of the variability of the need of creating maintainable code. Somewhere around 2006, I created a script that posts to the Livejournal community daily_tao a new chapter of the Tao Te Ching every day. Today in 2016, I had a need to look for the script, the second time in maybe the last eight years that I had to look at it. I temporarily wasn't sure of where that script was.

The value of a rapid test suite Developers and codebases The bare minimum required of a developer is "make this change without breaking anything else in the code", and if you've been around software development for any period of time, you know that's harder than it seems. Most of the time that a developer spends on any given codebase is spent on an existing codebase, adding new features on top of existing code.

Elixir, because: I think of Elixir as an idea whose time has come; or rather, a great gathering of ideas. Erlang has solved the problem of distributed computing (and therefore, of concurrency) decades ago, and now concurrency is a very desirable tool, as the amount of data we crunch regularly has increased exponentially. TDD has brought a more functional approach to a lot code, and that is the paradigm Elixir espouses.

What this entry is and is not about This entry talks about estimates in a relatively perfect world. This entry does not talk about problems that teams run into when dealing with estimates in a world where estimates are often misunderstood and where parties try to pile up additional meanings and metrics to estimates. Why talk about estimating at all Estimating work to be done before it is done.

Someone I worked with once said, "The code didn't demonstrate that I hit a wall, just that I understood a wall existed." This colleague had been using the technique of Test-Driven Design (TDD) to methodically get the codebase up to a point where it could be refactorable and, at the same time, to a point where a problem with the current design decisions could surface. He was happy because now that he was up to that point, the future decisions for the refactors were much more clear.