On Software Teams

It’s been about half a year since I threw out my My Programming Manifesto, and I’ve started to collect some things that I missed the first time around.  As always, you should be reading this as “..while there is value in the items on the right, *I, Jeremy D. Miller, sole author of the Shade Tree Developer (who is not acting as an agent of my employer in this article)* value the items on the left more.”  It’s also the case that you only have so much time and resources to complete any given project and we all want to play that time and resources against activities that create more value and minimize the time we spend on lower value added activities.  Part of my formulation below is the belief that the stuff on the left provides more bang for the buck than the stuff on the right.  In a few cases I also think the things on the left provide a more pleasant work environment than the things on the right, and that formulation simply cannot be disregarded.  Happy developers are productive developers.

Also, this isn’t even remotely complete.  This just represents some areas that I’m seeing in clients and otherwise where I think the balance between the two opposing choices are being tipped the wrong way.  Overall, let me just say that I’m an optimist in terms of people and their behavior.  Yes, I’m as snobbish as any alpha geek wannabe and I’m prone to thinking that most developers out there are bad, but I also think those same people could be much better if given a better environment.  I also see a lot of good people being held back by bad environments.  Raw talent and effort just isn’t everything.

I tried and tried to come up with pithy subtitles, but just couldn’t do it. 


Internalized Discipline over Externally Enforced Discipline

I got in a bit of an argument the other day with one of the project managers at my client (which ended with a mutually acceptable compromise).  They use Jira from Atlassian for project management and tracking.  Great right?  Atlassian is one of the most visible Agile software companies in the world.  I was objecting to their very complicated directed workflow that they enforced inside of Jira.  My point was that if you wanted Jira to accurately reflect the current status, dump the directed workflow to make the tool easier to update without jumping through the process hoops.  I also stated that I didn’t think they derived any value out of the directed workflow.  The response I got was that the developers wouldn’t test their code at all without the “quality gates” enforced by Jira.  Yet another trip down “the developers can’t be trusted (but I can).”  That last statement is what would concern me the most.

Quality gates are a very common tool in software development processes to enforce quality by making the people on the project demonstrate some sort of compliance to a standard or process before the project is allowed to proceed.  I’m not sure that I’d say that quality gates are necessarily a bad thing at all, but by themselves, quality gates are absolutely worthless in promoting software quality.  The quality gates happen too late in the project and are far too often conducted by people who are not qualified to judge the real quality.  Instead, it’s often an exercise in checking off the adherence to a defined process. 

In my experience, software quality is something that happens as a result of a team’s day to day behavior, not from externally enforced strictures.  How well you unit test the code.  How diligent the developers are about producing well structured code.  How the team refines the design as they work.  How conscientious the testers are about testing the behavior of the system.  How well the analysts can capture and guide the evolution of the requirements.  How the team strives to constantly fine tune their processes as the project proceeds.  These are the things that make for software quality.  The internal discipline and approach of the team performing the work every single day is more important that externally applied governance.  You don’t get quality with enforcement and reviews, you get it by making quality a daily exercise. 

Back to the idea of what activities pay off more.  Quality gates and external discipline doesn’t happen at the time that code is crafted, requirements are gathered, and tests executed.  It comes after the fact.  That externally enforced discipline isn’t around when things are actually getting done.  Even if the quality gate finds problems, it’s awfully late in the game.  Those quality gates still take up time and resources to do, even if they go flawlessly.  Why not redirect that time towards better testing or more code reviews? 

Quality should be the responsibility of the team doing the work, because they’re the only people who can make it happen.  One of my most deeply held beliefs about software development is that people should have the power over the way that they work, and then adequately take responsibility for that work.  The team doing the work is most likely the folks best qualified to know what they do and do not need to do. 

But Jeremy, that might be fine for you, but I can’t trust my developers to just do the right thing.  I need governance.  First, what are you doing to change their behavior?  Secondly, why did you hire them in the first place if they can’t be trusted, or can you tighten up the hiring process.  Three, is that really the case?  I’ve heard this line about not being able to trust the developers far too many times.  Why, or how, is the manager responsible, but the developers aren’t? 

As far as tools go, I’m a hold out.  I think these kinds of tools are only justified in distributed teams and even then, they better be easy to use and not cause any friction.  I think that I can create far more project transparency while only using crude project management artifacts like story cards, but upping the communication and collaboration of the team.  I think these tools are often perfume over smelly team mechanics.


Coaching over Enforcement

Too many times in my career I’ve seen situations where a team is created that doesn’t contain the adequate skills and experience to execute the project that they’re given, but there’s a quality body of some kind ready to eviscerate them for not complying to some sort of standard.  I’ve seen plenty of “Quality Assurance” teams that came into project retrospectives loaded for bear, but were sight unseen during the project’s execution.  It’s far more useful in the long run to roll up your sleeves and help your teammates do things well than it is to be the big guy up top who ensures that the other people are doing things well.

My career goal for the near future onwards is to become the sort of person who can help everyone else around him to be better.  To compare it to basketball, I want to be more like Magic Johnson circa 1988 rather than a younger Michael Jordan — even though I started the other way around.  Same thing with coaches.  I played a lot of sports when I was younger, thinner, and had intact ACL’s.  The coaches that I remember fondly are the patient ones who were great teachers.  The yellers and screamers I could do without.


Collaboration over Direction

In the following two discussions, which would you rather be a part of?

  1. This is what we’re going to do.  Use the Supervising Controller pattern here
  2. What I’m thinking is this.  I think we should use the Supervising Controller pattern for this screen because…

Most people want some form of autonomy, and many people are perfectly capable of thinking for themselves.  Giving a person exact direction is often tantamount to turning off their brain and removing free will from their work.  I’ve led teams on and off for 7 years now.  I’ve noticed a very severe trend in how developers react to the direction I give them.  If I give them very detailed instructions, down to the class and method level with UML diagrams, they try to follow those marching orders verbatim, often to very poor results.  On the other hand, when we go up to a whiteboard together and sketch out a design together, the results are far, far better.  In some part I think it’s because they understand the design better for having taken part in its formulation, but mostly because they don’t stop thinking.

It’s not just the touchy, feel-y aspect of it either.  People work better when they understand the context, reasoning, and goals behind a course of action.  I call this “understanding the why.”  When you understand the why behind your technical direction, you’re much better able to make decisions and follow that direction.

Another thing that simply cannot be avoided.  People can’t just pick up a task cold and run with it.  There’s always some bootstrapping involved before someone understands a task well enough to proceed.  Tomorrow I’m starting work on a financial report I know nothing about in a totally different architecture and codebase than what I’ve been working on (I will be positive about the opportunity to flex my legacy code slaying muscles instead of whining, I swear).  I’m not going to develop at the same speed I do in my own Jeremy friendly codebase.  I also wasn’t a part of the formulation of this little side adventure, so I’m effectively starting from scratch tomorrow. 

I think you can cut down on that ramp up time considerably by working more collaboratively between project/product management and the developers.  Nobody should ever be surprised by their work assignments.  Whether it be through iteration kickoffs, project planning, or simply discussions leading up to a task, a developer should never, ever see an unfamiliar task assignment pop up in their TODO list.  Yet another reason why I don’t like project management tools that try to take the place of human interaction.

Testers too for that matter.  Dumping new features on unsuspecting testers is one of the worst things that we developers can do to the testers.  It takes time to develop an effective test plan, and we need to accommodate this in our planning.  Get the testers involved as early as possible to ease the turnover from development to testing.  You can’t ship until the testers are done with their part (assuming that you’re on one of those advanced teams that actually includes testers), so it behooves you to make their job as easy as possible.  Besides, a tester can’t just test what you tell them to test.  They need to exercise their tester superpowers and find those pesky edge cases that you didn’t.

I don’t want to work on either side of “direction” from above.  To me, working in a collaborative environment is much more rewarding than having to be the guy at the top that makes every decision for the minions below.  It’s tiring and unrewarding to be “the guy.”  It used to be an ego boost to be the One Truck Guy, but I’ve had a chance since to work with strong developers in a collaborative setting.  It’s a much more enjoyable experience than being “the” guy.  I’m old enough now to realize that not every idea I have in regards to a design is necessarily right or the best solution.  I want feedback on my ideas.  I enjoy interaction.  “Ok, whatever you say” or “I trust you” is nice, but it’s more rewarding to have a real discussion.  Besides, I just don’t quite know what to make of a developer that isn’t opinionated.  Wait Jeremy, they’re just being pragmatic and open minded.  No they’re not, they’re just being wishy washy.

Anybody that worked with me five years ago would be laughing their butts off at the idea that I’m for more collaborative team structures rather than a hierarchy with me at the top.  People do change.  Or, you know, at least try to.

Other Stuff

I’ve tackled subjects related to teamwork before and I think it’s just as important if not more than the technology used or your individual habits.

  1. Call me a Utopian, but I want my teams flat and my team members broad
  2. Self Organizing Teams are Superior to Command n’ Control Teams
  3. Once Upon a Team
  4. The Anti Team
  5. On Process and Practices
  6. Want productivity? Try some team continuity (and a side of empowerment too) – I miss this team.
  7. The Will to be Good
  8. Learning Lessons — Can You Make Mistakes at Work?
  9. Indelible Proof of a Healthy Team

There’s more coming, someday, but I really wanted to click the “Publish” button at some point this evening.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://nervoustych.com/blog/ Jim Burger

    Great post Jeremy, I agree with you 100%

    I couldn’t help but expand on a few points: http://tinyurl.com/2fqdwe

  • Anonymous

    average of 17 words per sentence …