Transcript and more thoughts about the topic below…
Transcript
Boss and Dev are shaking hands, apparently after a job interview
Boss: We hire only the best. Rock stars. Ninjas.
Boss: Elite squads. Top of the tops. And then we tell them exactly what to do, keep them 100% busy and give them zero freedom.
Dev and another person are sitting in front of the same computer.
Boss: Pair programming? Waste of time!
Dev is looking at a presentation that shows the "Red-Green-Refactor" loop of test-driven development.
Boss: We tried TDD before. It doesn't work here.
Boss: All refactoring must be prioritized by the P.O.
Dev and antoher person are drawing whiteboard diagrams.
Boss: Don't change the architect's software design!
Dev is sitting in front of a computer, programming.
Boss: For loop? Did you just use a for loop?
Boss (looking directly into the "camera"): That's our culture. We. Are. The Enterprise
A Lack of Trust
So, that organization only hires the best developers (or at least they say so). But than it does not trust them to do their job.
But that last example, with the for loop, is ridiculous, right? Yes it is. Completely over-exaggerated, right? No!
The last example is there to show you how ridiculous all the other example are, too. Let’s walk through them.
Pair programming… Is it a waste of time? Only the people who do the work can decide that. It definitely looks slower from the outside. But it is faster at least under some circumstances, and it can even be faster on average.
If a company trusts its employees to do great work, it should also trust them to decide when to do pair programming (or even ensemble programming) and when not.
(But: Doing pair programming right—i.e. being effective while doing it—is not easy. You’ll probably need some practice.)
Test-Driven Development… doesn’t work here? I have heared that a couple of times, but I have never personally seen a company where it would not have yielded some benefit with some training and a little bit of practice (But I have not worked in every company yet—If you are certain that TDD does not work at your projects, drop me an email at business@davidtanzer.net, I would love to learn more). And when I teach TDD trainings, attendees often tell me that what they learned during the training was quite different than what they thought TDD would be like.
And again, only the people doing the work can decide whether they would be more effective doing TDD or not doing it.
Prioritizing refactoring… Refactoring is an integral part of software development. We try something, it works, but what we did to implement the solution will impede our future progress. We clean up a little so that we can maintain our pace.
There might be situations where delaying refactoring to finish something else is the better decision. But the product owner—a business person—cannot decide that. Given enough information about due-dates, deadlines, business decisions and priorities, the people doing the work, the developers, are best qualified to make that decision.
Changing the software architecture… Software architecture is primarily a job to be done, not a badge of honor. If there is only a single person or a small group who is allowed to do architecture work, your organization has not yet arrived in the 21st century.
Your organization may have dedicated software architects for a variety of reasons, but when the people doing the work do not have a say in architecture decisions, your software architecture will always be less than optimal.
A for loop… OK, that’s just plain ridiculous. But there are similar decisions that companies often make for their employees, like the editor they are allowed to use.
All those points boil down to a lack of trust. Some organizations (not all!) do not trust their employees to do the right thing for the company. They add checks and balances, and over time they start to fight bureaucracy with more bureaucracy. And some of them do not even see how much this is slowing them down.
