As a reminder; CIRCLES!
This post is going to talk about the Green Circle.
Another reminder is the tight interconnection between all of the components.
I posted about the blue Keyboard Circle a while back. It's time to talk about the Quality Circle.
Quality Circle
The quality circle is what is what I consider the aspects of the day to day development that drive the code quality to where it should be. These are the prime practices.
- Coding Standard
- Collective Ownership
- Continuous Integration
- Sustainable Pace
- System Metaphor
The Quality Circle will span two posts; this post will cover the first two practices.
Coding Standards
These are the most straight forward. The TEAM must decide on a set of standards that are to be followed. This is a fairly dogmatic thing to follow. I've been involved in many standards discussions and I have very strong stances and opinions on a lot of things for a lot of languages. There's some standards I loath, and yet support (C#, you and your I interface prefix... Looking at you!). If there's any resistance to dropping the I, I don't push.
These company/team/project standards exist, in my opinion, for one primary reason: Churn. If a commit changes all tabs to space; then what the hell actually changed? I can't tell; and it's going to make any code-archeology a worthless endeavor. It's going to alter A LOT of lines, without any changes. Tools can hide whitespace; but it's still a change in the commit history. Then it'll be changed back. Dev-A and Dev-B will alternate changing entire files. If they get clever and have it do the whole code base... all the files on every commit. Yea... No.
We do not churn like this. It limits the usefulness of source control, it creates tension and friction. We pick a standard and go with it.
I generally approach coding standards via the following:
- Language
- Existing
- Team
- Personal
Language
To simplify onboarding new team members, use language standards unless there's a good reason not to. Falling back to my I prefix case; it's hungarian notation, which is bad. This is a good reason to deviate from the language standard, but not enough if everyone's not on board. It's program to the interface; we don't care what type of interface, be it an actual interface, or base class... Or a baseclass turning into an interface... The I... anyway - I have my rant on that; I'll save you from it for today.
Deviation from the language norm should be an exception; and I'd advise having it well documented "Why" the deviation is happening.
Existing
One of the biggest things when working on a project is to follow the existing conventions. One of the few things worse than terrible Code Standards are Multiple-Code Standards. Follow what exists even if it's terrible. If you need more explanation; I'll put a fish on my head.
Follow existing standards so that future maintainers do not want to kill you.
Team
This is similar to the existing, but we start to get into preferences. The team should decide on standards and those should be followed. If there's disagreement and no resolution; flip a coin. Just take one of them and declare, "This is out standard now". Having a standard is more important than fighting for your preference. While I'd advocate against a team deciding to deviate from language norms - If that's the team decision; then the team should... No. The team MUST follow it.
Personal
I spent a bit of time thinking about this one. I supported it at first, being able to have little things as long as they don't conflict with what someone else does... and if so then a decision needs to be made. I can't maintain that. You're either doing something different, or everyone is doing it. One of these is acceptable.
This falls into the Collective Ownership; if you have a personal style, then other's won't feel as free to modify the code; It becomes your code. That's going to violate the collective code ownership. It's why unit tests are a CRITICAL part of the Keyboard Circle. There needs to be confidence to work in any code at anytime.
Collective Ownership
Since we've touched on it; let's jump into Collective Ownership. I've found I often narrow the scope of this by saying Collective Code-Ownership but it's far too narrow. This excludes all the other aspects of getting a product out the door. Build, Release, Infrastructure. It's an overall ownership of everything needed for the product to go out the door.
Any member of the should feel comfortable and free to do anything anywhere for the product. If the build system needs a tweak; tweak it. If there's a bug that needs to be fixed; Fix it. If data import needs to be modified; modify it.
To be free to do this, is easy. "You can work on anything". With that we're free to work on anything. The hardest part is to make it comfortable for anyone to work on anything. If there are no tests; it's not an environment anyone can be comfortable working in. Without the code having been TDD'd; TDDing it is going to be much harder, if not impossible. We then get into needing to work with Legacy Code; and that's an adventure of it's own; and not oft a comfortable one.
If I don't know how they data is being imported; how can I feel comfortable that the consumption of the data is going to work? I need to be able to dive in and check it. If there's a required fix; and it needs changes across multiple projects - we can't wait for "the right people" to do it. It needs to get done. I had this recently with a typo. It was part of a JSON data contract. There was an errant character in the source contract that was propagated through the entire system. Four projects had this typo. No one picked up on it. When the typo was discovered; there was a bug filed and since it was blocking final implementation; a mob took the bug; verified it in all systems; and fixed it in all systems. There was no need to assign the bug to 4 different teams. A mob took it, and a mob resolved it. This is Collective Ownership.
The alternate to this story is when a typo in the contract is detected by the data team. They "fix" it... which isn't really fixing. It's breaking the published contract. The rest of the teams were unaware. A couple days were lost down rabbit holes trying to find the bug... all because there wasn't a sense of ownership over any code but "theirs". "Their" code was correct, it's someone else's problem.
Summary
These are important practices that work well with the Keyboard Circle. We'll get into the additional practices in part 2 of the Quality Circle.