Stacey Vetzal designed and has presented our 8-week program since 2015, and it has evolved to be a concise, inexpensive, and helpful way for organizations to infuse or recover a sustainable culture of professionalism that steadily and proudly delivers value.
The program is delivered weekly and in-person by Stacey at your development facility. It tours through the Four Rules of Simple Design, with touch-points through introducing automated testing to a legacy code-base, how testing informs design, how reducing coupling and improving cohesion produces more malleable code, and refactoring techniques to make those improvements. Developers can apply these techniques immediately to improve quality and bring the agility that clients demand.
The program is suitable for any developer skill level and typically runs with no more than 12 attendees at a time.
8 Full Day Visits, Once Per Week
The program employs three modes of learning every week:
- 1 hour of instructor-led presentation, with live code demonstrations, where the instructor steps the team through key practices
- 1 hour of group practice, a small programming challenge facilitated by the instructor to ensure every individual remains engaged
- 2 or 3 strategic one-on-one coaching sessions with select staff to
- strategize on tactics
- reinforce learning
- build team supports
- glean practical examples from the team’s own codebase for the next session
- distill organizational recommendations
- 15-30m management synchronization builds alignment with organizational goals and builds a collaborative stage between the needs of the organization and the needs of the software teams
To kick off the program, there’s a survey to gain a baseline understanding of the members of the team. After every session, there’s a refresh questionnaire/test to gauge understanding and a “temperature check” to gauge changes in behaviour.
What’s In It For The Business
What’s in it for the developers is easy, we spend time working with them to raise the level of their programming skills, which will improve their ability to locally optimize their work, but too much of that will run counter to the organization’s goals. Dr. Eliyahu M. Goldratt wrote extensively in the 80s and 90s about his Theory of Constraints, in which he presented the idea that optimizing only local efficiencies (like your dev team) would de-optimize the overall system (that is your business). His theory was born of his observations in manufacturing but since applied to many business realms including product management (Critical Chain).
Instead, the true benefit of this series comes from setting up the conditions for better collaboration between business units and building an understanding of the system(s) in which your software development operations are participants.
Session 1 – What is Testing?
Adequate testing is fundamental to releasing quality software, but what constitutes proper testing? What does it mean that your code is “tested”? In this session, we discuss automated as well as exploratory testing techniques. We will talk about what unit testing means, what integration testing means, and what acceptance testing means, and how to automate all three.
Automated testing is the single most important factor in getting changes and features into the hands of your users as soon as possible.
Session 2 – Test-Driven and Iterative Design
What does test-driven design mean? See how testing can influence and inform your software architecture, and improve its design. In this session, we demonstrate and discuss the test-first “red, green, refactor” cycle, and show you how to ensure you’re never more than a couple minutes away from a fully functional code-base.
Session 3 – What does Express Intent mean?
Code quality goes deeper than passing business requirements and tests. The best-maintained roads are useless without street signs. Like a map, good code is easy to follow. When you jump in to add a feature or fix a problem, good code is critical to getting that done promptly.
Good code expresses its intent. The language you use, the way it reads to everyone on your team, should clearly and uniformly indicate what it is doing.
Session 4 – Fundamental Design Patterns
As code evolves, patterns emerge. This idea is what inspired the book Design Patterns by Gamma et al. in 1995, the first published work of formalized patterns. The challenge, however, is in recognizing that while it’s important to know the patterns when you see them, it is also important not to apply them prematurely to your code. In this session, we will explore some basic patterns, and examine how they may translate to the programming language of your choice.
The challenge, however, is in recognizing that while it’s important to know the patterns when you see them, it is also important not to apply them prematurely to your code. Don’t commit to a pattern until the “Last Responsible Moment”, because an inappropriate abstraction will cost you dearly over time.
In this session, we will explore some basic patterns, and examine how they may translate to the programming language of your choice.
Session 5 – What does No Duplication mean?
The obvious result of duplication comes from “copy-paste,” but this is not the only cause of duplication in our code. In this session, we explore the kinds of problems caused by duplication, and how it slows us down.
No duplication, or “Don’t Repeat Yourself” has subtleties that should be explored. As mentioned in Session 4, hastily choosing the wrong abstraction will cost you dearly, so when does your team agree to suffer duplication?
Session 6 – Understanding Coupling and Cohesion
When someone says their codebase is messy, it’s usually here where things are blurry. How do you sharpen the lines between the different areas of your system, and what’s the benefit?
Testing is probably your first victim when it comes to tightly coupled code, and that is why we talk about the importance of testing and the designs it will encourage in Session 1.
However coupling and cohesion impact at many different levels, from the unit-level, to how you package and deploy your systems.
Session 7 – Small What?
The last core rule of simple design is to make things small, but what does “small” mean? How do you measure it? How do you apply it?
As human beings, we have the capacity to comfortably hold between 5 and 9 things in our heads as we reason through a situation. Limiting the number of things you have to juggle to complete your task at hand has a direct impact on your effectiveness in completing that task.
When the team disagrees on what should be small, you can see that tension in your code, and it adds to the friction developers have as they touch new and unfamiliar areas of the system.
Session 8 – Principles of Good Software Design – S.O.L.I.D.
A quick overview of the S.O.L.I.D. principles in software development as outlined by Robert C Martin. In this session, we explore these principles and how they relate to the Four Rules of Simple Design.
Teaching from the Four Rules of Simple Design sets you up to better understand the motivation behind the prescriptive practices of SOLID. It helps you understand the trade-offs you are making when you choose to favour one SOLID principle over another when they are in conflict.