Software design

Software design is the internal quality of the design of software and the properties that make the software easier to understand and change in the future, specifically focusing on maintainability. It emphasizes(but is not limited to) object-oriented technology due to its prevalence in modern software development, addressing design quality at the class and package level, including aspects such as source code organization, class identification, interface use, design patterns, and the application of design guidelines [1].

An agile team thrives on change. The team invests little upfront; therefore, it is not vested in an aging initial design. Rather, they keep the design of the system as clean and simple as possible, and back it up with lots of unit tests and acceptance tests. This keeps the design flexible and easy to change. The team takes advantage of that flexibility to continuously improve the design so that each iteration ends with a system whose design is as appropriate as it can be for the requirements in that iteration [2].

Relates to

• design principles
  • SOLID
  • Law of Demeter
  • DRY
  • Design by contract

Blogs

• What is Connascence? - connascence.io
• About Connascence - codesai.com
• Rules of Simple Design
  • BeckDesignRules
    • same as the four simple design rules
      1. passes the tests
      2. reveals intention
      3. no duplication
      4. few elements
  • Xp Simplicity Rules
  • The Four Elements of Simple Design

Youtube videos

• Understanding Coupling and Cohesion
• CppCon 2017: Jon Cohen “A Type, by Any Other Name”
• ETE 2012 - Jim Weirich - Connascence Examined
• YOW! 2012 Jim Weirich - Connascence Examined #YOW
• LA RubyConf 2009 - The Building Blocks of Modularity
• A Philosophy of Software Desig - John Ousterhout - Talks at Google - decomposition is the key, maybe this is also related with Parnas paper.
  • tactical vs strategic approach
  • interesting approach on the history behind facebook and their lack of looking at technical approach led them to a path that they had to change the way they thought about moving fast. Instead of moving fast and break things, move quickly with solid infrastructure to back it up. And it goes to unit tests and docs.
  • In the book overflow podcast the author joined the hosts to discuss the book content.
    • huge fan of testing he tries to do unit tests, not much in the book
    • test write development not much, he writes the code like white box. Debugging the system instead of designing the system, it leads to bad design - it works to bad design. The hosts says that this is easy to implement the tatical tornado that was mentioned in the google talks. TDD didn’t feel right to him, pet peveet is a nightmare at google.
    • design twice
    • critique of the book
      • are comment really miss leading? Is this a real thing that we have observed? This is one of the key points in the book that comments can be a layer of abstraction
      • the author is also spending a lot of time in the linux kernel
    • the author suggests that the clean code is not that well in design, that the book has too small without comments, which is interesting at least for me listening the podcast that most of the statements done are based on students experience and teacing classes? I wonder if there is the same result with people from industry.
  • kent beck in tidy first
• Youtube playlist - this is a general playlist that contains a few videos with the related content that I am sharing here.

Papers

• Is designing software different from designing other things?
• Comparación de herramientas de Detección de Design Smells
• How the practice of TDD influences class design in object-oriented systems: Patterns of unit tests feedback

References

1. [1]J. Stevenson and M. Wood, “Recognising object-oriented software design quality: a practitioner-based questionnaire survey,” Software Quality Journal, vol. 26, pp. 321–365, 2018.
2. [2]R. C. Martin, Agile software development: principles, patterns, and practices. Prentice Hall PTR, 2003.