Core Values for Web Development Teams

As a webdev team, we have several core values that help guide our decisions day-to-day. Here are a few examples:

Tests or it didn’t happen

A past refrain in internet culture when someone told an outlandish story is, “Pics or it didn’t happen.” We say the same thing here except for tests. Test provide 1) runnable documentation of business rules, 2) a great practical way to ensure devs ponder and cover edge cases, and 3) a guard against regression. We all know this though. Ask any developer anywhere if they think tests are good and necessary and they’ll say, “of course!” Then, ask them if they have greater than 90% test coverage on their projects. Most of them will balk at that. Here, however, we enforce it via automation, which touches on another of our core values, “automate all the things.”

Automate all the things (especially rules)

This is how you do much with few people and few errors. Automate build pipelines, testing runs, deployments, license checks, everything. Spending time up-front to set up a CICD script will save you countless hours of tedium. More importantly, it will boost your speed to market a.k.a value delivery (see “It doesn’t count until it’s released”).

Rules deserve special mention here. Development teams usually come up with rules around things like test coverage percentages, code style/formatting, branch naming patterns, and more. Developers are often under pressure and, being human, are wont to cut corners sometimes. It is natural. However, keeping compliance and quality consistent over time requires constant enforcement of the team rule. Enforcing these rules manually is like herding cats and is doomed to failure. Instead, automate these rules. Use linters, code formatters, coverage thresholds, SCM push rules, and others to make this enforcement automatic, constant, and unaware of any “fires” giving the humans, including the tech leads, stress enough to want to cheat. Rules: if they’re not automated, they’re not enforced.

It doesn’t count until it’s released

When we build features and push them to develop,the issue is closed, and the developer considers it “done”. They’ve created new value in the product. However,like potential energy, created value is not doing anything productive until it is delivered to a user. And, of course, delivering value to users is the name of the game in the software business. Merges to develop and sprint demos are not the goal. Releases are the goal.

Deleted code is tested code

Old, stale code can be the source of bugs and security vulnerabilities. Get rid of dead code, and if you can refactor 50 lines down to 5, do it. In the quest for code coverage, deleted code is tested code i.e. you get that code coverage for free. If you happen to need to refer to that code later, find it in your git history. There’s no need to keep it in the file commented-out “for reference”.

Work should be “edged”

With advanced in communication technology, we can read emails on the go. This gave rise to so-called “edgeless work” where you’re never really off. We don’t like that. We work hard during our work time and play hard during our play time. Our team respects people’s fun time, family time, exercise time, …, off time. Sure, some developers like to code as their hobby. That is, of course, up to them. But they should be able to work on their own projects during their own time.

Write code for humans, not computers

Computers are fast, and we have code minifiers anyway. Code that is a bit more verbose with longer, more descriptive variable names will help you and other developers return later to maintain that area of the codebase more quickly and with less stress, and fewer new bugs. Remember, head-scratching time costs money too.

We don’t have 1 team of 7, we have 7 1-person teams

We strive to train all the team mates to do all the things: dev, QA, ops, scrum master, release manager, etc. This is so mitigate key-person risk and to ensure that anyone can go on vacation without being bothered because there are multiple people that can perform any one task.

The only way to “have time” is to “take time”.

This is great quote from the Matrix movies. We understand that if left to their own devices, product managers would have the dev teams work only on business projects from the roadmap and not so much on internal projects like process automation, refactoring for maintainability, and the like. Many dev teams intend to get to those when they “have time”. Instead we choose to “take time” each sprint to tackle a “balanced diet” of issues covering business projects, internal projects, bug fixes, refactorings, and automated testing. This would never happen without conscientiously adding these other types of issues to each sprint backlog.

Coding time is sacred

Coders are paid to code, and it is difficult to get back into the zone once distracted. All developers are encouraged to protect their coding time from extraneous meetings and other distractions. If it is becoming a problem for the developer, it behooves them to alert the manager who’s job it is to help protect the developers’ time.

We may decrease grade, but we’ll never decrease the quality.

Sometimes there are external pressures and deadlines we cannot avoid. In these cases, we may have to reduce the scope of our work to fit within the time box. This is fine. Releasing features at a reduced “grade” may be necessary from time to time. However, although we reduce the grade of the feature set, we will not reduce the quality or test coverage.

Too much of a good thing is bad

How long should a feature request write up be? As long as it needs to be. If the developers, QA, etc. understand the intent of the feature, there is no need for the developer/manager/product owner to spend the time on writing out a novella in the issue description field. Some people look down on “incomplete issue cards”. We look down on wasted time and effort.

No matter how far you go down the wrong road, turn back.

Things evolve, lessons get learned, technologies fluctuate. We do not do things a certain way because they’ve always been done a certain way. We are always open to improving and refining our team processes and technologies.

There are more that will be added later. The point is, core values need to help team makes make decisions during the work day. Else, they are empty bumper-sticker slogans like “integrity” and “teamwork”.