A variable’s name should correlate to the size of its scope.

The larger the scope, the harder it is to fully understand.

In a tight loop with a scope of one line, a variable’s name can be one letter. This is often an array index or some kind of counter.

As the scope gets larger, the variable name should become a word representing a business object.

When the scope of a variable exceed that of a single method, there definitely becomes a stronger chance of confusion, so the name may need to involve multiple words.

In all cases the variable’s name should be immediately obvious to the reader. And when they see a really long name, that should be a red flag to the reader that this variable may have an extended scope.

Kanban in three easy steps.

There’s not a lot to Kanban, which is one reason it is desirable.

Yes, you should be agile, and that means following the agile principles, and reading the agile manifesto. Past that you will find different agile methodologies, the most infamous one being Scrum. Kanban is much preferred, and a lot easier to implement. To do Kanban, there are three main things you need to do.

First, visualize your workflow. Make this visualization highly visible to everyone. Preferably, this Kanban board would be posted in plain view of the developers working the project. A Kanban board is very easy to create; you take a board and divide it into columns representing the different states of your workflow. Then as issues appear, they enter the first state by appearing as a sticky note on the left column. As work progresses through the other states, it moves across the board, through the different columns.

There are many web-based tools for doing an online Kanban board. In this age of remote work, an online board becomes more necessary.

The second step to good Kanban practice is to limit the amount of work in progress. This means to avoid multi-tasking. A developer should be working one story at a time. If a developer has ten stories open at once, and declares them all to be “in progress”, there will be very little progress. Often a “work in progress limit” is posted above a status column. Before additional post-its can be added to a column in excess of the posted limit, other post-its need to be removed from the column. Either they are promoted to the next step or pushed back to the backlog.

The third step for Kanban is measure and improve throughput. The two most common metrics are lead time (from appearing in the backlog to delivery) and cycle time (from work start to delivery). Lead time is more focused on how long a new idea will sit in the backlog on average, and when it gets too large, the team has too many projects pending. The larger it gets, the more likely there are stories in the backlog that will never, ever get completed.

Cycle time is more focused on the performance of the team doing work in progress. Obviously some stories are bigger than others, and thus cycle time represents an average. Generally, this system works best when most stories are roughly the same size. Try very hard to have extra-large stories, and break them up into smaller stories when you see them.

That’s it, that’s all there is to Kanban. If you can do the above three things, you can do Kanban.

Keep the build clean.

Don’t accept failed tests.

Sometimes there are places where the build never completes successfully, yet people happily move along anyway. “Oh, that test always fails,” one might say. Well what good is a test whose failure is acceptable?  Either fix the problem or remove the test. Clearly it doesn’t represent a real problem.

The build must stay green. When the red lights appear in the build, that needs to be a major call to action – something is wrong and must be fixed!

If having red lights in a build becomes acceptable, some really bad failures will eventually leak into production. Failures that should have been noticed and prevented.

Don’t create God classes.

These monsters try to do too much.

God classes control too many objects and contain far too much logic. They often don’t start out that way. Over time, additional methods and responsibilities are added and it grows and grows.

Watch out for classes that have too many responsibilities or dependencies. Another indicator is when a class is working with too many objects.

These monsters are hard to test, hard to maintain, and hard to document. As they become bigger, it’s hard to tell what’s really in them. Sometimes deprecated code lives on in them, which can get re-used by mistake.

Furthermore, the code is brittle. Because of the high number of dependencies, a god class may have hundreds of reasons to change.

Peel off responsibilities to other classes. It’s much better to have dozens of small classes than to have one classes that’s 10,000 lines long. In the end, it comes down to this: a class should really have one job.

Avoid paralysis by analysis.

It can halt your progress.

Beware of excessive analysis. Obviously analysis is in general a good thing; you need to properly understand the business requirements of the features you are developing. But it is very easy to go overboard with analysis and endlessly discuss the pros and cons of approaches, going back and forth with options. The result is you never actually get to writing code.

Sometimes you simply have to put a stake in the ground, even if it is the wrong stake. You have to start somewhere.

What can help is to get mockups as fast as possible. With this visual aid, decisions come more quickly. Six people imagining things in their head is quite different from seeing a picture, a drawing on a whiteboard, a mockup on a screen. It helps tremendously.

Iterate to a solution. It’s okay if the earliest versions are wrong. They are not the final versions. Sometimes you have to make mistakes in order to determine where you want to go.

Build small pieces. Don’t try to accomplish big-bang waterfall projects. Build a piece here, a piece there. Even if it’s not a working whole, at least you can point at the pieces and use them to drive further decisions.

Beware bikeshedding.

Some decisions don’t get the consideration they deserve.

The more complex a system is, the more people will argue over the trivial details, ignoring the important parts.

Some people can’t understand the complex parts and thus feel obligated to argue about the simpler parts that they understand, so they feel like they are making a contribution. They are not. Don’t do this.

Imagine for example a committee considering the approval of a nuclear power plant. The committee doesn’t understand most of it, other than it will provide power to the city. Part of the project involves the construction of a bike shed on the side of the facility for the use of the workers. The general contractor has provided multiple options for the color the bike shed will be painted. Suddenly, the committee is full of many opinions and a heated discussion ensues.

The approval of the plant gets almost no discussion, but the committee argues for hours about a bike shed. This kind of craziness happens far more than you would think.

Avoid premature optimization.

There’s a time and a place for this and it’s not at the beginning.

Before you spend time optimizing code, make sure it would be worth it. If the program is already fast enough, then any time spent optimizing is wasted time that would be better spent building new features. Furthermore, you run the risk of introducing new bugs and adding code complexity.

So before optimizing it is important to measure performance and do some analysis. A task that takes 120 ms to complete is no big deal – unless that task needs to run thousands of time an hour.

You should prefer simplicity over efficiency until you have performance problems. Simple code is so much easier to maintain and expand. Optimization techniques involve complex algorithms, multiple levels of caching, and other tricks. The problem with clever code is that the more “interesting” it gets, the more of a maintenance headache it becomes.

That said, don’t write code that results in N+1 queries to the database. It’s not that hard to write queries correctly. And when the performance of the system becomes a problem, go ahead and optimize.

Observe single test cases in your IDE.

It’s a powerful tool, extremely useful in examining code coverage.

As you are reviewing code, run single test cases and observe the code coverage within the IDE. Most modern IDEs can do this. The IDE shows which lines are and are not covered by the test case. On a multi-screen setup, you can have the tests in one window and the code in another. This is a fun way to review code and see what methods get called by each test.

Do not introduce extra logic for tests.

All logic should serve a business purpose.

There’s a fun phrase, I believe it came from DHH, “test damaged development”. It occurs when a developer finds that in order satisfy his tests, he has to introduce some new logic to the code that doesn’t serve any practical business purpose. When this occurs, it is a bad thing.

Getting TDD right takes a lot of practice and this is one of the traps that some people fall into. Try to avoid it.

When you find yourself adding unnecessary logic, it’s a good time to pause and bring in a fresh set of eyes. Maybe there’s a better way of doing things. Adding code for coding’s sake is not good.

An object should not have more than one trigger.

The trigger should have one job.

If you have multiple triggers on an object, it can be confusing to determine which trigger will fire first. This can lead to unexpected and surprising results, and we all hate surprises when our code runs.

Multiple triggers may also duplicate effects or cause other bugs.

Instead, have the trigger kick off one job, and then have that job call everything else in the order you desire. This leads to a much more predictable outcome.