I’ve been writing software long enough to have developed a few opinions. Many of the practices and patterns that I have encountered have been great! Some have taken me down a dark, winding path. Here are a few that I find more bittersweet.
Test-Driven Development (TDD)
I am a huge proponent of TDD. It has saved my bacon a number of times, and has surely saved me hundreds of hours of troubleshooting and re-factoring.
What I Love About It
- My boss and team members like the higher test coverage
- Easier to communicate test cases and test plan ideas to QA
- Better idea about work remaining to complete a feature
- Greater confidence in re-factoring, since I know my tests will catch most bugs I might introduce
What I Hate About It
- It takes a lot of discipline. I regularly need to kick myself to keep up with it.
- The farther I fall behind, the harder it is to catch up again.
- It doesn’t catch everything, i.e. it is only as good as my ability to write tests.
Inversion of Control (IoC) Containers
I have seen Dependency Inversion done well, and I have seen it done very, very poorly. IoC containers are by far the most common tool I have seen used for DI. Maybe that’s because of my predominately OO background. I’ll have to think about that a little more.
What I Love About It
- Adding class dependencies is much easier (especially with constructor injection)
- Helps facilitate TDD, since a class can be tested even if implementations of dependencies is incomplete.
- Simplifies unit tests and makes it easier to isolate and mock objects.
What I Hate About It
- There are too many to choose from, all with their own strengths and weaknesses
- Not all frameworks support IoC containers, which limits your ability to implement DI (think ASP.NET Webforms)
- Often confused with the problem they were meant to solve (Dependency Inversion). This leads to a misunderstanding of the concept.
Lean/Kanban
There are as many different processes as there are programmers. Kanban (more than most) embraces this diversity.
What I Love About It
- Greater visibility of active and upcoming work
- I waste very little time trying to figure out what to do next
- Makes it easier to communicate progress to superiors and investors
What I Hate About It
- One “weed” in the group (if not removed or managed well) can disrupt the entire process pretty quickly.
- Most kanban evangelists are anti-scrum. This seems to circumvent dialog about the benefits of scrum.
- It is gravely misunderstood by most project managers and executives, which limits the team’s ability to implement it properly.
Kiss and Make-up
As you may have noticed, most of my complaints stem from the human factor. I have found it frequently frustrating that I cannot get everyone “on board” with something I think is worthwhile, but that is a topic worth exploring some other time.
Regardless of my frustrations, I have no intention of abandoning these practices. I have used their names more often in praise than in curses.
How about you? Do you share my frustrations with these programming practices? Did I miss some that love you and drive you nuts at the same time?
Tell me more about Project Managers having problems grasping Kanban concepts – I’ve never used it beyond a dev team.
The most common issue I have encountered is that Project Managers still want to hold on to the so-called “traditional” PMO rules.
I’m not a PM, so I’m commenting on this from my observations from the outside, but it seems that some things about Kanban are counter-intuitive or illogical when viewed from a traditional PMO background. For example, when an engineer I know had approached the PM and tried to explain that estimating work is irrelevant in the long-run, the PM couldn’t seem to reconcile that in their own mind, and didn’t want to give up those concrete numbers so they could build their timelines, even though the Kanban approach of measuring cycle time is more reliable than having an engineer make a guess about the future.
This has improved significantly, even in the year since I wrote this post. Most of the PMs that I have worked with recently are at least open to more agile approaches, even if implementation is lacking.
I’m not just trying to pick on PMs, either. I have worked with my share of engineers that can’t seem to wrap their brains around it.
On a related side-note, here’s a great talk from a Lean conference in Boston a couple years ago. It contrasts traditional project management with lean:
Thanks, Patrick!
Comments are closed.