Make code re-use easier.

Code that is easier to understand is more likely to be reused.

Okay, everyone is a big fan of reuse. After all, recycling is not only environmentally friendly, it saves money, too! Wait, we’re talking about software here, not aluminum cans. So push the back blue bin…

Alright, starting over:

When you’re writing a nice bit of code that particularly proud of, you, of course, want it to be used by others as well. After all, it’s smart to have a common library and implement certain pieces of logic only once.

Unfortunately, just because you wrote it, doesn’t mean people will want to use it. For your code to be picked up for reuse, it needs to be clean, attractive, and easy to use.

Think about it. You want to work with clean, clear code. So do the people who come after you. So for your code to be reused, it needs to developer-friendly. Easy to read. Easy to understand. Easy to use. It’s what you would want, right?

The medium is the message.

The way you communicate great ideas can be as important as the ideas themselves.

Communication is one of the most important skills often found to be lacking in software engineers and other people in technology. This is not at all surprising; when you’re knee deep in computer code your whole life, you don’t spend a lot of time working on your English language skills. Sure, you might be strong in Java, Ruby, Python, C#, PHP, Kotlin, Swift, R, and Go — but communicating with human beings requires plain English. So from the start when you need to express ideas to other people, you forced to use a tool that isn’t your best skill.

Making matters worse is the medium of choice. The same message can carry much different meaning, and get interpreted much differently when it comes across via various channels. Imagine the same text expressed in an email, hollered across a room, sent via text, printed in a letter, appearing in a video chat, told second hand, shown in a PowerPoint presentation, or left as a block comment. Even though the text in each case may be the same, the receiver of the message is likely to have a different response in each instance.

Thus it is essential to be sympathetic to your listeners. You need to understand how they will receive your message. The way it comes across will color the message itself, possibly in an undesirable way.

When in doubt, use parentheses.

Don’t confuse the “and”/ “or” operators with the “&&”/“||” operators.

In the early years of computing, there was just one “logical and” operator, as it mapped to a machine-language operation that performed a “bitwise and”. Basically, 00000001 AND 00000001 results in 00000001, and since that’s not zero, it’s true.

Later, we used the symbol “&” for “and” and “|” for “or”. And this was fine, for a while.

As people created more sophisticated programming languages, there was a desire to separate “logical and” from “bitwise and”. The “bitwise and” compares the respective bits of two binary strings and results in a new binary string. The “logical and” returns true or false, depending on whether or not one of the expressions being compared is true. This resulted in using “&” for “bitwise and” and “&&” for “logical and”.

There was some confusion about where “logical and” should appear in the order of operations. So in some languages, a compromise was reached, with two “logical and” operators, “&&” and the word “and”. The difference between them is where they occur in the order of operations.

The English versions, “and” and “or”, have lower operator precedence than the assignment operator.

x = y and z means (x = y) and z
x = y && z means x = (y && z)

In the first one, you only do z if the assignment by y to x completes successfully (returns true).

In the second, the value “true” is assigned to x if both y and z are true; otherwise, “false” is assigned to x.

As you can see, these are two totally different actions. Be aware of their use, and if ever in doubt, add parentheses.

Kanban’s Third Rule

Maximize throughput.

With Kanban’s goal to increase the speed with which work flows through your team, you will need to do certain things to maximize the speed of tickets moving across the board.

First of all, you need to track some statistics. After all, you can’t improve what you don’t measure. The most basic measure is the number of tickets moving into production in a given period. Unlike Scrum, you do not timebox effort into forced intervals (sprints). Instead, pick a period that is good for reporting, such as months, and count how many tickets were delivered into the finished state during each period.

One challenge with this is that not all tickets are equal. Some stories require a lot more work than others. In the long run, this typically does not matter, as it all averages out over time. To mitigate this, break up complicated stories into smaller bite-size pieces. Not only will these move faster, but they cause a lot fewer problems for testing and delivery.

Another Kanban statistic is to measure the average lead time. For each ticket, measure how long it took from the time it was added to the backlog to the time it was finished. The average lead time gives people an idea of how long it would take for the team to deliver a new idea into production.

Cycle time is another useful statistic. This measures the time from when work starts (in progress) to final delivery (done). Unlike lead time, it does not count the weeks spent idling in the backlog. Cycle time is more a measure of how fast tickets travel across the board once selected.

To keep track of these, you will need to record timestamps on each ticket for various important dates, including the date the ticket was added to the backlog, the date work started, and the date work finished. If these can be added to a spreadsheet or SQL database, it makes reporting a lot easier.

You can use similar techniques to measure portions of more complex workflows. If your workflow has 23 steps, for example, and you are interested in how the flow moves through steps 6 through 9, you could record timestamps at those steps.

As the team gets better with its processes and automation, the times should start to come down. To get there, the number one goal is to reduce wasted time in the system. Identify activities that waste time and determine the causes. This can be things like poor requirements, poor working conditions, lack of communication, problems with tools, and so on. Be sure to pause and reflect periodically to study these things and come up with ideas on how to reduce the time wasters.

Another thing you need to do is ensure the right amount of resources are available in each step of the workflow to avoid bottlenecks and idleness. These are obvious on the Kanban board, with large clusters of tickets indicating a bottleneck, and empty columns or swimlanes indicating possible idleness.

Kanban’s Second Rule

Limit work in progress.

On the Kanban board, columns that represent work should have “work in progress” limits. With a WIP limit in place, the number of tickets that can move into that status should be limited. Before another ticket can be added to a column at the limit, an existing ticket needs to be moved out of the column.

For example, say you have columns for “primary development”, “code review”, and “QA”. Maybe for this example, you set a WIP limit of 8 to the “code review” column. The intent here is that if there are eight tickets already in code review, then good grief! Don’t do more new development work. Instead, get some code reviews done. Otherwise, tickets may pile up endlessly in the “code review” column.

The whole point of Kanban is to increase the flow. To do this, you need to limit the number of tickets that can be in a particular state that represents work.

In a similar line of thought, you should avoid multitasking. Each person should try to work on only one ticket at a time. Maintain your focus on one thing. Minimize interruptions.

Stop starting and start finishing. Done is so much better than in progress.

Don’t create technical debt as a shortcut. All this does is move a ticket forward by creating a new ticket. Is that really progress?

Break larger stories into smaller ones. When stories are large, it takes them forever to move from one state to the next. Smaller stories move more quickly, are easier to test, and sooner released.

Every work effort must have a ticket, and all active work must be represented on the board. If you don’t do this, your Kanban board doesn’t reflect the true state of the team, and it loses its usefulness.

Follow this advice, and your board will have tickets flowing across it.

Kanban’s First Rule

Visualize the workflow.

The magic of Kanban is the focus on the board. The Kanban agile methodology was inspired by the Toyota Production System. There, a kanban (Japanese for “sign board”) was a ticket that traveled with each component as it made its way through the assembly line. These boards ensured limits to how many items could be on the assembly line and ensured each item completed all of the required steps.

To use Kanban, you need to have a model for your workflow. Kanban works best if you have an environment where there is a never-ending stream of new feature requests, enhancements, and bug reports. Also, it works well for applications that can be updated in production on demand. This profile fits many agile teams well, especially web-based applications.

On the other hand, if you are delivering packaged software, where the quality of the delivered, final media is more important than the time frames, then other, more formal methods may be more appropriate.

To visualize your workflow, you need a large board that is visible to everyone in the development team. Divide the board into columns, with each column representing a state in the workflow. Order the columns left to right in the order of the steps of the development process. For example, you might have steps like “backlog”, “analysis”, “development”, “testing”, and “in production”. If you have a distributed team, this can be problematic, as this works best with a board that everyone can see throughout the day. The most popular substitute is to use an electronic board, so that teams in each city can view the same board.

Every feature, enhancement, bug report, story, or task should be represented on the board with a ticket. This may be a 3×5 card with magnets, or it may be a post-it note, or cards posted on a corkboard with push pins. Each ticket should have a ticket number to tie to your online ticketing system, which brings together various other data elements like pull requests, comments, and approvals. The ticket on the board should have a short name on it so that anyone glancing at the board knows what that ticket represents.

From here, people vary their tickets a lot. Some use different colors to represent the issue type, or the component, or the development team, or the priority. It doesn’t matter; you should use whatever works best for your particular team.

As the ticket proceeds through the workflow, it should be physically moved across the board to the column representing its current state.

More complex boards add swimlanes, which are horizontal rows across the board. Typically a swimlane represents a logical grouping of tickets. You might opt to have separate swimlanes for UI, backend, and API stories. Or maybe the swimlanes represent the Javascript, PHP, and Java teams. Sometimes there is an expedite lane, and this is typically placed at the top of the board. Again, adjust your swimlanes to represent a grouping that works well for your team.

If an issue has a blocker, it is best to note this on the board with an indicator of some sort. Maybe it’s a red card or post-it that is placed over the blocked card. On magnetic whiteboards, you might circle the blocked card. The idea here is to see at a glance which tickets are blocked.

Another handy feature of the board is that when there are clogs in the process, it becomes immediately apparent. For example, if there are two tickets in each state but 15 tickets in the testing status, then this makes it obvious to everyone that you should stop adding new tickets in development and put more people to the task of testing, to clear the clog, and restore the flow.

Kanban is all about optimizing the flow of tickets to production, and the board is the go-to tool to help with this.

Everything can fail.

You can’t always depend on third party services.

A few years ago I had one of the busiest weeks I’d had in a long time, and I wasn’t able to monitor my queue of scheduled blog posts. For weeks I had been scheduling blog posts on Medium, and they had been working just fine. It didn’t occur to me that they would suddenly stop working.

So during my super-busy week I needed my scheduled blog posts to run as normal, posting on my behalf, daily each morning, as always.

But oh, things didn’t work out. As soon as I stopped looking, Medium quit posting my scheduled stories. So my goal of posting a story every day for a year suddenly ended because of undependable technology.

Anyway, the lesson here is that you can’t trust third party systems. They will fail at surprising and unexpected times. Don’t put your faith into them. Always be on the defense. Monitor your systems. Build in redundancy. Check things manually from time to time. You never know when the systems may stop working.

Once bitten, twice shy.

Use automation to prevent bugs from re-occurring.

One of the most frustrating bugs you can see in a production system is one that was fixed previously. A bug that was already fixed once. For various reasons, bugs can reappear. Perhaps some old code gets reverted, or perhaps a developer repeats someone else’s mistake. In any case, people are going to be upset that this bug, which was supposedly fixed, is now back again to haunt the system.

This is why it is important for every bug to get covered by an automatic test. This includes any bugs found through manual testing. If you have a robust suite of automatic tests, it can go a long way towards preventing these bugs from returning.

Never let a manual tester see the same bug twice. Put your robots to work.

Exceed expectations.

Under promise, over deliver.

One of the most disappointing things in project delivery is when you fail to meet expectations. Everyone was hoping for success. The definition of success was set. But the team failed to deliver on all of the goals. They may have worked hard, they may have delivered a ton of product, but since they didn’t meet the expected goal, they are considered to have failed. Everyone is let down.

Many projects are set up to fail in this manner. Stupid, ignorant managers believe in “stretch goals,” believing if they just keep asking for more, they will get more. In the end, all they ever get is a failure to meet impossible expectations. Morale plummets. People leave to find a purpose in life where they can feel like they are achieving something worthwhile. They go to seek jobs where they have a chance to win.

Now let’s compare this to a team that has reasonable, or lower expectations. The team works hard, delivers a lot of product, same as before. The difference here is that the team delivered more than expected. Everyone is pleasantly surprised. People feel amazing. There are celebrations. Confidence builds, and the now encouraged team endeavors to take on the next goal.

It’s a night-and-day difference, and sometimes the biggest difference between the two situations is simply the expectations.

Wouldn’t you rather be awesome?

Thus, one of the most important jobs for a manager is to manage expectations. It can be a very difficult task at times, especially when you have counterparts in the business who aren’t in touch with reality. It also requires you to be able to predict and see the future, which is always fraught with peril, as there are always unforeseen challenges. No one said it would be easy.

Manage your energy.

If you don’t, you will become exhausted.

Spend your energy wisely. You’re only human, and you don’t have infinite energy. If you try to do too many things, you will become exhausted and burn out. As you become more tired, your productivity drops dramatically. Your mental acuity also suffers, making it harder to solve problems. You will make more mistakes.

Thus, it is crucial to get the right things done. This means you have to say “no” to some tasks, intentionally not doing them, so that you may complete the more important tasks.

This is why it is so important to set priorities and goals. When you enter your day with a plan, you have a lot more confidence that you will be spending time on the most important tasks. Start each day, knowing what the most important goals for the day are. Mark them off your list as you accomplish each one.