DEV Community

CodingBlocks

The Pragmatic Programmer – How to Build Pragmatic Teams

We learn how to apply the concepts of The Pragmatic Programmer to teams while Michael uses his advertisement voice, Joe has a list, and Allen doesn’t want anyone up in his Wheaties.

In case you’re using your podcast player to read these show notes, you can find this episode’s full show notes and join the conversation at https://www.codingblocks.net/episode114.

Sponsors

Survey Says …

Anonymous Vote
Sign in with Wordpress
What's your favorite type of swag?
  • Stickers, because they make my laptop go faster.
  • Shirts, because I wear them pretty often and they make me look pretty.
  • Water bottles. Gotta stay hydrated. And then run to the bathroom inbetween talks.
  • Coffee cups. Coding requires coffee.
  • Hats, because everyone has a bad hair day every now and then.
  • Socks. Everyone loves super cute socks. Except Florida man.
  • Bags, because they cost the most.
  • Pens/notebooks, in case I need to write something down super quick!
vote

News

Building Pragmatic Teams

  • The methods learned so far from this book can be applied to teams in addition to the individual.
  • By working on a “pragmatic team”, the advantages of practicing the methods of the book are multiplied many times over.
  • However, these methods are only a starting point. Pragmatic teams will evolve, adapt, and refine these practices to best fit their environment.

No Broken Windows

  • Everyone on the team should care about quality.
  • Pragmatic teams can not accept broken windows.
  • Quality needs to come from every team member.

Boiled Frogs

  • It is easy for an individual to overlook the overall big picture environment while in the heat of a project’s development. It’s even easier for teams.
    • Team members can easily assume that someone else is addressing a bug, or that some environmental change was OK’d.
    • Keep in mind, environment changes don’t necessarily have to mean hardware or configuration. It could mean, bringing in a new technology for example.
  • Everyone should be on the lookout for changes to the environment.
    • The authors suggest appointing a chief water tester to monitor scope creep, timelines, and environments … anything that wasn’t originally agreed upon.
  • Keep metrics on new requirements.
  • Pragmatic teams shouldn’t reject new feature requests outright.
    • Instead, be aware when and that they occur.
    • Otherwise, you might be the one boiling.

Communicate

  • Pragmatic teams need to communicate clearly to the everyone else as one voice.
  • The worst teams are those that bad tempered or difficult to get information from.
    • Their meetings have no structure. No one wants to talk.
    • Their documentation is awful. No two documents have the same format and each use different terminology, i.e. no ubiquitous language.
  • Great teams have a personality.
    • You look forward to meeting with them because they are organized.
    • Their presentations are well-prepared.
    • Their documentation is consistent. Current. Accurate. Concise.
    • All members of the team use the same ubiquitous language and speak with one voice.
      • Externally. Internally, they have lively debates, where strong opinions are expressed.
        • Good developers are passionate developers.
  • The simple marketing trick to communicate as one: generate a brand.
    • Create a team name and logo.
    • When communicating with others, use the name/logo.
      • It builds an identity for your team to build on.
      • As well as something memorable for others to associate your work with.

Don’t Repeat Yourself

  • Duplication is wasted effort.
  • This duplicated effort can create maintenance headaches.
  • Good communication between teams can help reduce duplication.
  • A project librarian can coordinate documentation and repositories.
    • Other’s can go to the librarian when they’re looking for something.
    • And the librarian can spot duplication when they’ve been given something new.
  • However, if the project is too big for one librarian, appoint a few people as the primary contacts for various functional areas of the project.
  • And don’t forget the value of online user groups, mailing lists, forums, wikis, etc. for archiving questions/answers, and discussions.

Orthogonality

  • Traditional teams are organized such that individuals are assigned roles based on their job function.
    • The Rational Unified Process: An Introduction (Amazon) identifies 27 different roles within a project!
  • Roles have an implicit hierarchy: the closer the role is to the user, the more senior the role.
  • Some development environments have strict divisions of responsibility.
    • You might not be able to talk to the testers or the chief architect, for example.
    • To make matters worse, some organizations might have different sub-teams report to different management chains.
  • Don’t fall victim to thinking that the various tasks for a project can happen in isolation, because they can’t.
  • Analysis, design, coding, testing – These are all different perspectives of the same problem.
  • Developers that are two or three levels removed from the user will likely not be aware of how their code is used and therefore not able to make informed decisions while developing it.
Tip 60
  • Organize Around Functionality, Not Job Functions.

Team Division

  • The authors prefer to split teams up by functionality.
  • Each (small) team should be responsible for a small aspect of the overall system.
  • And each team is responsible to each other.
  • Commitments change with each project and so do the people per team.
  • Splitting the teams up by functionality doesn’t need to translate to use cases though.
    • The DB can count as a team. The help subsystem can count as a team.
  • Look for largely self-contained groups of people.
    • This is similar to how we’d break up code into modules.
      • Use the same techniques, such as by contract, decoupling, and orthogonality.
      • By doing so, we help isolate the entire team from changes outside it.
  • When done properly, this can reduce interactions, reduce time scales, increase quality, and reduce bugs.
  • Developers will be more committed.
  • Teams will feel more ownership because they know they alone are responsible for their part.
  • But this approach will only work with responsible developers and strong project management.

Two heads

  • Each project has two heads: one technical and other other administrative.
  • The technical head is responsible for the development style, assigns responsibilities, and arbitrates discussions.
    • All that while always keeping an eye on the big picture, removing unnecessary commonality among teams to maintain high orthogonality.
  • This person is the lead architect.
  • The administrative head is the project manager.
    • They schedule necessary resources, monitor and report on progress to the stakeholders, and might also act as the PR representative when communicating outside of the teams.

Additional Resources for Larger Teams

  • Librarian – Indexes and stores code and documentation.
  • A tool builder – Someone that provides the tools, environments, and support.

Automation

  • The best way to ensure consistency and accuracy is to automate everything that can be automated.
    • That bash script, makefile, etc. isn’t going to change itself. Typically.
    • And it can be versioned.
  • Automation is an essential element of a Pragmatic Team.
  • Appoint one or more people as the tool builders to build and deploy tools that automate the project’s boring parts.

Know When to Stop Adding Paint

  • Pragmatic teams give each member the opportunity to shine.
  • They provide team members with enough structure to support them and ensure the project delivers against those requirements.
  • And then resist the urge to add more paint.

Resources We Like

Tip of the Week

  • Git tips:
    • Undo your last commit: git reset HEAD~ (Stack Overflow)
    • Undo all of your current changes and reset the environment back to the last commit: git reset --hard HEAD
    • Remove all untracked files: git clean -f
      • Remove untracked directories, too: git clean -f -d
  • Joe’s reasons to use Kotlin (in no particular order):
  • Overview of Microsoft Authentication Library (MSAL) (docs.microsoft.com)

Episode source