Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 (Category Architecture)
Interesting. speech Kent Beck, who once not only participated in the signing of the Agile Manifesto, but was the first signatory among respected gentlemen ... as he walked first in the alphabet. In this talk, Kent, creator of the XP methodology (eXtreme Programming) He talks about his extreme approaches to design and briefly about the book "Tidy First?" told earlier. If you briefly summarize his story in this talk, you get the following:
- It all starts with motivation – we have the order. 3 billionth (~ 95 years). If you think about running out of time, there is a motivation not to waste it.
- And in the development of software there are many such useless things, for example, the author trolls the topic with documentation:)
- Once upon a time, the author participated in a panel discussion at a confe with luminaries Edward Yourdon, Larry L. Constantine, who wrote the book.Structured Design" Kent read this book and decided to write an updated version.
- So there was "Tidy First?" where Kent talks about how to clean up the code. This will allow the developer to improve their workplace and simplify the work.
- There's an idea for the second book, "Tidy Together?", in which Kent plans to talk about how engineers work together in teams, and the third book will talk about the relationship between technology and business.
- The main idea of the author is the importance of design to change the behavior of the system. Software consists of functions and structure. A business thinks about functions, and a structure is a backbone for these functions.
- If we only rivet features, the structure is underinvested - we create technical debt, which complicates the introduction of new features in the future. 8 ) The goal of the right approach is to balance investments in function and structure. (The author gives an example of drinking duplicate functionality)
- Kent talks a lot about the social effects of design, trust and responsibility, and the different incentives and interests of different stakeholders. It's usually called sociotechnical system.
- Kent talks a lot about the limitations of documentation, such as that it becomes obsolete faster than it is updated, etc. But it is not clear what alternative he proposes.
- Kent says that in software development, the total cost of ownership comes largely from the cost of maintaining and modifying what is written, rather than the initial investment in writing code. By the way, this thesis is often forgotten now when assessing the effects of writing LLM code by assistants, considering only the ease of initial code generation:)
- But not all changes cost the same - usually small changes are inexpensive, but many small changes can accumulate and turn into larger ones that can cost as a significant part of the system. In the terminal case, this large change results in the version being banned. 1.0 and create a new project from scratch
- To reduce the cost of changes that will definitely be, you need to understand the cost structure - this will help prepare software for evolution as business requirements change.
- Kent talks about coupling and that initially coupling between components meant that changes in one element may require changes in others. And then the definition of Edward Yourdon, Larry L. Constantine began to mutate and lost its original meaning.
- When developing software, you need to take into account the cost of connections and the cost of their absence. It is important to make trade-offs between the cost of change and its consequences. The space of compromise helps to assess the feasibility of changes.
- Evaluate these tradeoffs better by understanding economic factors such as NPV and the cost of money over time, risk assessment, and so on. For example, investing in a structure creates opportunities for future change, which gives us the option to implement cheap changes in the future.
- Separately, limitations give engineers the space and incentive to make good decisions.)
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture