The Biggest Challenge for Growing Applications
As an application grows and becomes successful, its most significant challenge is adapting to change. Grouping methods into classes is crucial, but getting them right in the early stages of a project is challenging. It’s important to remember that you will never know less than you know at the beginning of the project. The design of your application will determine your ability to make changes in the future. Changes should not have unexpected side effects, and small changes in requirements should only need minor changes in the code. The easiest way to make changes is to add code that is easy to change and reuse existing code. If your application succeeds, many of your decisions today must be changed later. It is the need for change that makes a design matter.
Object-oriented design code only matters once we need to change the code base. Making a design more flexible than the immediate change wastes valuable time. The question isn’t whether programmers are doing design or not. The question is, are you going to regret your design choices later? Thus, any new change should move the system towards a more straightforward design.
Despite the importance of grouping methods into classes, getting it right early in your project takes time. If your application succeeds, many of your decisions today must be changed later. When that day comes, your application’s design will determine your ability to make those changes. The easiest way to change is to add easy code to change with no unexpected side effects. Small changes in requirements should only need minor code changes, and existing code should be easy to reuse. The cost of any change should be proportional to the benefits it achieves. The consequences of change should be evident in the code that is changing and in remote code relies upon it. Usable existing code should be functional in new and unexpected contexts. The code itself should encourage those who change it to perpetuate these qualities.
If an application lives long enough, its biggest problem will be dealing with change. A design that does the wrong thing might produce great metrics but may still be costly to change. Design is more about flexibility than aesthetics. We should apply a good design that could be more pleasing to us, based on their business relevancy. Refactoring provides insights into a problem. The Design Stamina Hypothesis compares a team’s productivity with and without design work. Investing more time in design early on may be beneficial to ensure a clear understanding of the app’s purpose. Yet, the flaw in this hypothesis is that it assumes developers know when to stop designing and start building. In reality, developers focus on finishing projects instead of considering future changes. The Design Stamina Hypothesis should focus on setting clear goals for when to focus on design. It’s important to note that developers are designing, and the cost of quality should be considered.
[¹]: Practical Object-Oriented Design: An Agile Primer Using Ruby
