2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- December 23, 2015
- Rants
“Continuous attention to technical excellence and good design enhances agility,” is one of the principles of the Agile Manifesto. In retrospect, at their ten-year reunion, at least some of the original authors of the Agile Manifesto felt they didn’t state this strongly enough.
I believe technical excellence doesn’t just enhance agility, it enables it. Cobbling code together in iterations the way most developers write code in a traditional development environment, with little attention to technical excellence, can incur so much technical debt that development grinds to a halt. I’ve seen many teams get into this situation, not right away, but by their fourth or fifth year into development things slow way down.
What is technical excellence? Given the state of our industry and the low success rates reported by study after study, I’d say that most developers don’t know what technical excellence is. This isn’t their fault. We haven’t been taught these things in school and we don’t generally agree on a core set of standards and practices.
So asking teams to just figure it out and self-organize can often set a team up to fail. But this is what Scrum says and many ScrumMasters are under the illusion that developers can just figure this stuff out, even though much of technical excellence is in direct opposition to what they were taught in school.
Whenever I get to teach for one of my clients on the East Coast, who hires a lot of entry level developers, I can always see some of my newly graduated students chuckle in the corner when I tell them that excessive “what” comments (comments that explain what the code is doing) can be bad because the code itself should express what it’s doing. They’re surprised. They say they were told by their professors that as long as every line of code has a comment explaining it, even if the code is obvious (like “x++;”), then it doesn’t matter what the code says. But professional developers know this to be a bad practice.
When I ask developers, even senior developers, what the SOLID principles are or what methodologies they follow, I often get blank stares. These ideas should be top-of-mind and considered with every line of code we write. I’m not talking about volumes of information, just a few dozen core principles and practices. But these things aren’t universally known in our field. So asking developers to “just figure it out” may not work as well as management might expect and that’s the case on many of the Scrum teams I’ve observed.
Instead, give them the resources to be successful. Build a library of useful books (there are many). Bring in a class. Hire a consultant. Find someone who’s been there and done that so you can learn from their mistakes without having to “reinvent the wheel.” It’s true that this is what I do for a living but I’m not just plugging my services. There are plenty of other sources to get a team headed for technical excellence. One good and free option is to keep reading this blog as I cover several aspects of technical excellence in my posts.
Previous Post: « Be Anthropomorphic
Next Post: How to Define a Successful Software Product »