#begin
Andrew and David kick this chapter off with the idea of no broken windows. Do you remember what this was about? You don’t leave broken windows in a building because if there’s one broken window and nobody fixes it, people expect its fine and no one will ever fix any broken windows or other damages. This makes the building deteriorate to some dirty shithole.
No Broken Windows
Quality is a team concern, not just an individual concern. Once you find bugs, you should fix them… especially if you have some SLA of some sort. But even if you don’t have an SLA bug need to be fixed because they will probably accumulate over time. So, responsibility must be taken to battle software entropy. David and Andrew mention that some methodologies have the responsibility of quality allocated to some quality officer. They say this is “clearly ridiculous”. Haha I agree. Same goes for SCRUMmaster but don’t get me started on that again. High quality, or properly following the SCRUM rules cannot come for a single person, it’s a team concerns… obviously.
Boiled Frogs
Next up, we’re going to boil us some frogs. Or don’t we? Remember the frog in the pan of water metaphore? People don’t notice the gradual change in their environment and end up being cooked. We don’t want that… pragmatic teams are on top of changes. David and Andrew mention that for teams its even easier to get boiled because people might expect it’s someone else’s responsibility to be on top of things, and then nobody does it. They say we must fight this. Everyone on the team should monitor environmental changes both within the company and outside. For example, when new requirements come in, write them down somewhere so you are able to point out scope creep. Otherwise, you and your team will enjoy the heating water.
Communicate
Next it’s a small section on the fact that developers need to communicate. Well, no shit sherlock! Obviously, software engineering and game development is a team effort. Pragmatic teams are the ones that communicate to the outside world effectively. Communication within a team is often pretty smooth, but once it leaves the confinements of the team things can get messy.
David and Andrew mention that teams should host meetings properly. Let people speak and don’t interrupt. We don’t want messy meetings where everyone is constantly talking and interrupting each other. I think this is less of a problem with the remote work because, if 2 or more people talk at the same time the audio of the stream is not understandable. They also mention that documentation written by a team must follow a certain template. I think this is common sense but ok. I think every company has some basic templates for design documents, requirements, risk analysis etc. If not, you should create some as soon as you can to smoothen up that communication flow. David and Andrew also give a tip that helps teams communicate; its to generate a brand. When a new project starts, create a nice name for it, create a logo us use that on memos and reports. Use that name constantly so it gives your team an identity to build so people can associate the team with it.
Don’t Repeat Yourself
Just as individual pragmatic programmers our teams must follow the try principle. We should not be documenting the same thing twice, we should not writing the same code twice and we should not be archiving identical information in multiple places. David and Andrew mention that some teams appoint a member that acts like a librarian who’s responsible for coordinating documentation and code repositories. This might work for small teams, but as teams grow larger it wont. But people can use this librarian figure to ask for information and also to put the information somewhere. A good librarian is able to spot duplication and thus can archive just the bits that are interesting. But as I mention a bit before, this might not work for large teams. You could simply increase the number of librarians on the team but then, they also need to communicate properly. Luckily with modern chat systems communication can be done fast and asynchronous.
Orthogonality
Next we take another look at a recurring topic in this book, orthogonality. Do you still remember what it means? It means loosely coupled and highly cohesive in a software context. But what about the team context? Well, David and Andrew say that traditionally, in the waterfall era of software development, individuals were assigned specific roles. There are business analysts, designers, architects, programmers, tests and so on. These roles implied some implicit hierarchy. Some might say that architects are more senior than programmers and programmers might be more senior than testers. Or game designers might be more senior than QA folks. I think its a common career path for QA to move into game design at some point, right? But David and Andrew say that this implicit hierarchy can cause communication hurdles as ‘lower’ ranked individuals feel they might not be allowed to talk to ‘higher’ ranking individuals. This leads to a nonorthogonal team where things happen our of sync all the time. When there are multiple people who try to solve a problem from different views, without there being any communication between them, it will lead to trouble. I mean if a business analyst solves a problem from the business perspective, yet and the architect just solves the problem with the latest shiny object distributed architecture and the developer is being pragmatic and writes a simple modular monolith there will be problems down the road.
David and Andrew say that they like splitting teams up into smaller units that are responsible for creating a particular component or functional part of the system. Let these teams organize themselves. Also, each team should have responsibility towards another team in the company to foster good communication. David and Andrew basically described some form of agile or dare I say SCRUM teams here. It also sounds a lot like Jeff Bezos’ two pizza teams, right? Small teams, with a specific responsibility that can move fast.
They also say that teams should be able to communicate following the Law of Demeter. Remember this law? It says we only talk to relatives, not strangers. So in a team sense this means you can talk to your direct consumers and producers but not other teams. I’m not so sure about this one. I really do want to talk to teams I’m not directly dependent upon. David and Andrew say that if some team, way out there, decides to swap their database technology, we should not be impacted. And, although I agree, I do think that let’s say, if some relational database is swapped for a document database, I might rearchitect my data layer to optimize for it. So even though things would not break, it might not be optimal. So, I don’t necessarily agree with this. I think there’s some nuance here.
Something I do agree with is the idea that communication between teams can be done following the design by contract approach. There should be clear responsibility about team deliverables and scope. When contracts are clear, communication between teams can be drastically reduces and they are able to move quickly. David and Andrew also say that teams require at least two heads, one technical and one administrative. In modern teams this is often reflected by some tech lead and maybe an engineering manager. Yeah, I’m not counting the SCRUMmaster as an administrative head since that’s not his role. Of course, people can wear multiple hats but let’s not mingle the responsibilities of multiple titles into one. They also tell us that when teams grow, we might need people like librarians, tool builders, operational support and QA.
Automation
Next we will take another look at automation, but in a team setting. As we need to work together within the team, we also need to make an organization run like a well oiled machine. In the modern day and age this means we need proper CI/CD pipelines that consumers of our software can integrate. Wether these consumers are internal or external to our team or organization. So in a unity context that means you could setup a scoped package registry to host and pull custom packages from. It works pretty nicely. I’ve used verdaccio and artifactory before. Both are great, yet verdacccio is a bit more light weight compared to artifactory. You could also just use straight up git uri’s but in that case it might be a bit more difficult to properly version everything. And, yet another option is to use git submodules which works best when you are working with dependencies that change frequently, and by frequently I mean multiple times a day. With submodules you’ll be able to to changes directly in your dependencies, check out different branches and create a custom dependency tree on your working branch. This however comes at a cost since management of submodules can become really chaotic. Trust me, I’ve been there. When you have a project with 12 submodules, all on custom branches; good luck coordinating a PR to main and getting all of these submodules back to main as well.
But automation does not only mean delivery and deployment. It must also include testing, maybe so static analysis for code smells of security vulnerabilities. You could use SonarCube or if you have some spare money, Ndepend. Just make sure you configure the tooling correctly because they sometimes don’t work nicely with Unity with default settings. For example; any publicly accessible fields for the inspector will be marked as a code smell. Most of the times, the tool will be right, but in some cases there might not be a clean workaround for public field like when you are doing a lot of custom configuration with ScriptableObjects.
And lastly, you might setup some automation for generating documentation using tools like doxygen. It’s pretty easy to do and, if maintained correctly, it can bring a lot value for your communication flow. Doxygen can output in several different formats like html, pdf and even LaTeX. You can then push that documentation really easily to github pages with some actions you will find on the web. If you have not tried it before, give it a go, it’s really simple.
Know When to Stop Adding Paint
Andrew and David finish this section with a reminder that teams are made up of individuals. You should give each individual their chance to shine. Give them just enough structure to self manage. We don’t want to apply subtle control because I’m quote one of my heroes; Erik Meijer: “Subtle control is a form of mental abuse.” Don’t try to control people, empower them! Facilitate a path forward for yourself and your team.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments