I recently founded the Meetup group Software Architecture & Design Berlin. At the first event I gave a talk myself, in front of 30 people. It was general talk explaining what software architecture and design is.
Here are the slides (additional speaker notes can be found in the options):
Are you aware of the different kinds of errors in software development?
Too often technicians are struggling with logical problems and managers are tinkering with design problems. This article gives an overview of all kinds of errors and problems which occur in software development. It further explains how to identify, distinguish and solve errors on different levels. Continue reading
Need to break the vicious circle?
Cyclic dependencies among Classes are a common issue in software development. They are best resolved at design level. This article explains how to do this. It also provides some intuitive insights into Interfaces and dependencies. Continue reading
Dependencies burden your design
Fixing one bug often causes multiple new bugs. This article explains why by introducing some basics about dependencies. It also briefly introduces parts of UML to visualize these dependencies. Continue reading
Are your classes green with envy?
Methods suffer from Feature Envy, if they use other classes more than their own. This article describes why this is bad design, how to visualize feature envy and how to cure it. Continue reading
Dumb Data Class
This articles describes what’s bad about dumb data holding classes. It describes how to refactor Data Classes. Also Code Smells are introduced briefly, of which Data Class is one. Continue reading
Are your classes Swiss Army Knifes?
Every good software is based on fundamental principles, every developer should know. This article explains the single responsibilities principle using a simple example. It introduces a new diagram to identify responsibilities of a class and a simple refactoring to get rid of multiple responsibilities. Continue reading
Reading Code vs. Reading Diagram
In software development one can highly profit from using graphical representations, instead of reading the code directly. This article uses a simple example, to demonstrate the advantages of diagrams over code. This first part, is about understanding the status quo of an existing software. Continue reading