What’s the most important thing we get from designing and writing code? It’s a question we don’t ask often enough. Mostly because it’s easy to assume the answer is obvious. Revenue? The business you are working for will often suggest that revenue is the most important thing about code. But, that doesn’t explain why some… Read More »
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 »
Any time you have a long-term data structure, it’s important to have some form of unique identifier used to look up or recognize the structure. It doesn’t matter if the long-term data is a database record, a document in some form of storage, an object, or whatever. If the data lives for a while, you’ll… Read More »
One approach for design trade-off is between Until recently, I tended to treat the second and third as the same. With some more thought, I’ve convinced myself they are not.
I see a lot of development advice that assumes the developer is working on a green field application. Many of the tools that “make a developer’s life easier” are also designed mostly for use in creating new applications. Most of my experience as a professional developer (or whichever title you prefer) has been improving and… Read More »
Over the years I have noticed a habit among some developers that I’ve come to call Aphorism Driven Development. Many best practices are taught and remembered through the use pithy statements. Although these statements are easy to remember, they can’t capture the full context and connotations of the practice in question. If someone never learns… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »