After seeing how our careful and thoughtful design changes over time, it should be obvious that some designs will not survive implementation or later maintenance. It should also make you wonder how to do a better job on design. Looking Back on your Design In the future, some of your great decisions will look naive.… Read More »
When people look at what they want to call Legacy Code, they don’t see a coherent system. They see an implementation that they can’t read. They see a design that is not simple/elegant enough. They see a pile of patches instead of a clean architecture. They wonder how any competent programmer could have made such… Read More »
One of my managers many years ago was in a meeting where someone from sales was disparaging our legacy code and he made a comment that has stayed with me for decades: “Legacy? Oh you mean the code that pays our paychecks?” The legacy system pays our paychecks Most code that hangs around long enough… Read More »
Most companies with a software development staff have legacy code that they need to maintain because it runs their business. Even companies that don’t do software as their main business may have internal tools and such that they need to maintain. Many software developers and even product and management would prefer to have new, shiny… Read More »
I have heard this comment in almost every company where I have worked. Without fail, this response occurs when someone on the technical staff suggests adding a practice accepted in other parts of the industry. Some variations are Early in my career, it was used to justify not using version control (yeah, I’ve been at… Read More »
Several years ago I gave a talk at work with the same title as this post. For a while, recordings of these lunch talks were available internally in the company. Over several years, I’ve had people either thank me for the original talk or reference things I said in the talk. Despite the fact that… Read More »
In the last post (Coding Style: Terse vs Verbose), I laid out some of the arguments for and against a verbose coding style and a terse coding style. Although, I didn’t delve deeply into what I meant by these styles, I hoped the details were less important than the general feel. However, by the end… Read More »
One coding style issues that causes many arguments is the distinction between the Terse/Elegant/Succinct style and the Verbose/Legible/Debuggable style. As usual, each side explains that their style is the only rational choice and that the other approach is obviously wrong. First, let’s look at the two styles to see what they say. In order to… Read More »
My wife is a really good writer and she once gave me a great piece of advice for some documentation I was working on: Know Your Audience. This has helped me to write better documentation. Over the years, I have come to realize that the same advice applies when writing code. Who is the Audience… Read More »
In the comments on a recent Google+ post, a discussion erupted about comments in source code. As usual, there were two groups that argued relatively vehemently. The More Comments camp was best represented by the suggestion that a good program should have as many lines of comments as lines of code. The Clear Code Needs… Read More »