Flexible Technology and People - Kent Beck's Software Design Theory

This article is based on the keynote delivered by Kent Beck, a widely recognized software developer, at NDC Porto 2024. It presents eight subjective themes that are crucial in software design. The content re-examines design from multiple perspectives, including the costs of software development, human relationships, economic viewpoints, and the impact of AI. Aimed at a broad audience ranging from beginners to experts and management, it organizes essential concepts such as "design and operation," "team structure," and "investment decisions" to maximize the value generated by software, while exploring concrete tips to broaden future options.

1. The Human Element of Software Design

It is introduced that software development is not just about code quality, but is actually heavily influenced by human relationships. If programmers continue to make decisions in isolation, they may become exhausted by handling every minor fix and maintenance task themselves. However, it is said that by clarifying roles and delegation, and by adjusting while understanding the difficulties faced by others, one can create higher-value software in the long run. It is suggested that mutual respect is necessary to reconcile the opinions of people with different goals within an organization, while effectively balancing short-term feature additions with long-term stability. Adopting this mindset is said to make it easier to solve technical and human challenges simultaneously.

2. The Balance Between Design and Features

Kent Beck states that it is beneficial for software not to be designed on a large scale from the beginning, but to grow its structure in parallel while adding necessary features little by little. This is the image of reinforcing both features (branches and leaves) and design (roots) alternately, just as a tree extends its roots while spreading its branches. To maintain a flexible design that can easily adapt to new requirements, it is considered desirable to oscillate between feature implementation and refactoring, rather than considering the design fully complete at any stage. It seems that there is a constant awareness of the balance challenge: spending too much time on large-scale refactoring fails to meet the demands of the field, while prioritizing only features causes future change costs to balloon.

3. The Essence of Cost: It's All About Change

It is explained that the majority of costs in software development stem from changes and maintenance rather than initial creation. For example, when responding to requirement changes or bug fixes, one may have to re-verify all related parts. It is stated that this cost can be significantly reduced by incorporating measures during the design phase that facilitate future changes. If developers rush only to implement immediate needs, changes often ripple through multiple modules, frequently resulting in unexpected man-hours. Therefore, it is suggested that it is essential to review designs from the perspective of "where and how much flexibility is needed" during code reviews and similar processes.

4. Coupling and Cohesion

Coupling and cohesion, as defined in the book "Structured Design," are introduced as being extremely important in current software development as well. If features are unnecessarily coupled, there is a risk that a single fix will trigger large-scale modifications. On the other hand, a design with high cohesion, where necessary features and elements are grouped together, is said to localize changes and facilitate work. For example, if two functions are always changed at the same time, managing them together in the same file or class makes the scope of change clear. Understanding coupling and cohesion correctly and controlling them consciously seems to be the key to smooth large-scale development and maintenance operations.

5. NPV (Net Present Value) and Optionality

It is introduced that the timing of software investment should be determined based on the economic concept of Net Present Value (NPV). Large early investments are not always the best strategy, and in some cases, continuing small-scale design improvements while timing them appropriately results in a higher ROI. Additionally, the key is identified as controlling the tension between the choice of prioritizing feature additions to drive the development cycle and investing in refactoring to increase options for future changes. Even in situations where the interests of teams focused on individual features clash with those of leads concerned with long-term maintainability, using Net Present Value as a central point of discussion is considered to facilitate mutual understanding.

6. Interruptible Design Process

If you proceed with a full-scale refactoring all at once, there is a risk of failing to meet business-side requests and damaging team relationships. Therefore, it is proposed to break down even large design changes into small steps, ensuring that feature implementation or bug fixes can always be inserted in between. It is also stated that running old and new systems in parallel and switching them gradually to ensure safety is an effective approach. This not only makes it easier to coordinate schedules with the business side when work is interrupted, but it is also suggested that it makes it easier to correctly verify the effects of refactoring because feedback can be obtained while actually performing the switch.

7. Will AI take away programmers' jobs?

With recent advances in AI technology, there are concerns that software development might be automated. However, it is stated that if AI evolves and the cost of programming decreases, the likelihood of new applications and business models emerging increases, which in turn will increase the demand for human engineers. Another point raised is that the act of "programming" specifications for AI itself requires the expertise and judgment of professional developers. It is explained that simply ordering "build an app" does not accurately capture requirements, and since detailed adjustments and decision-making can only be done by humans, the field for highly skilled engineers will actually expand.

8. Design Dilemma: Feature Development or Structural Investment?

Whether to prioritize daily feature releases or invest in design with an eye toward future changes is a point of debate in many projects. Prioritizing features can yield short-term revenue quickly, but as design debt accumulates, the speed of future feature development is likely to decrease. On the other hand, focusing too much on structural investment may cause you to miss market entry opportunities. It is suggested that to resolve this dilemma, one must invest in design as needed while simultaneously continuing small releases to achieve both. In particular, since high optionality has the advantage of being able to respond to major future changes, it is stated that it is important for everyone to understand when and where to invest.

Summary

In software development, it is pointed out that multiple factors—people and organizations, economic perspectives, and the characteristics of the code itself—are linked and influence each other. Even when excellent programmers are gathered, there are many cases where rework and deteriorating relationships arise due to systems where authority and responsibility are misaligned or excessive feature requirements. Conversely, if you choose a process of growing the design while experimenting on a small scale, you can continue to create value even during the process, and it becomes easier to suppress future change costs. Furthermore, even if programming becomes easier due to technological advances such as AI, human creativity and coordination skills remain necessary because the act of clearly communicating design intent and reaching consensus is the core of development. It is suggested that balancing investments in features and structure and building a team structure that can flexibly respond to environmental changes is the key to creating more sustainable business value.

Supplementary Notes

• Coupling: A state where changing one element requires changing another. Because the scope of modification widens, it becomes a cause of high maintenance costs.

• Cohesion: Placing highly related functions or data together in one unit. Changes are easily localized, improving maintainability.

• Net Present Value (NPV): A method for evaluating the profitability of an investment. It is used for investment decisions by discounting future cash flows to their present value.

• Optionality: The concept of maintaining multiple choices in preparation for future uncertainty. In software development, this corresponds to designs that are easy to change.

• Interruptible processes: A method of executing large-scale refactoring or design changes in small, manageable steps. This makes it easier to respond quickly to additions or modifications in business requirements.

• AI and programming demand: As development costs decrease, software will be introduced into areas previously outside the scope of development, potentially expanding the field of activity for engineers in the long term.

* This Note article is produced using mechanical processes to roughly understand global trends and to provide a bird's-eye view of changes over time at a later date.