Well perhaps not, but it might be the most important piece of programming advice you hear today.

“Switching gears is grinding gears.”

I’ve been doing this programming thing for quite a while now, and I have come to realize that the biggest thing that saps my productivity is switching gears.

What do I mean by switching gears?

Many different contexts

Switching gears can apply to a variety of different contexts, but it is basically whenever you are working on some task or technology and have to stop what you are doing and either do something else or change the type of thing you are doing.

This is really a bit different than multi-tasking.  Multi-tasking is really trying to do more than one thing at once.  It usually involves a large amount of rapid context switches, but for this post I am more concerned about the general idea of breaking rhythm.

I think it is easier to speak about this subject if we talk about some specific applications of the idea and why they are harmful.

Switching problems

In the Agile world of software development today, we often are required to switch from problem domain to problem domain as many of our iterations contain mixes of different features on different parts of the system and bugs to be fixed.

Have you ever been in the situation where you were just beginning to understand how some area of the code base worked, or how to work with a particular customer on a particular problem space and then had to switch to something else and start all over again?

Even when you switch back to the original context you were working with, if enough time goes by, it becomes new again.  You have to relearn much of what you had learned the last time and just when you begin to hit your groove, the cycle begins again.

This form of switching gears is at the very least frustrating, and at the most a complete demotivator and productivity sapper.

Unfortunately for most developers, this problem is out of your immediate control.  But, take note product owners and project managers, there is a reason why iterations should have a goal.

If you are in the precarious position of being a developer pinned against the ropes, try to make some noise and let your management and product owners know that your team will be much more efficient when you aren’t switching gears all the time.

In my experience, the results of replacing this constant context switching with the synergy of a common goal and related features in a segment of time has an astounding effect on productivity that is hard for any serious businessperson to ignore.  So speak up!

Switching technology

This is the primary reason why I have a distaste for JavaScript.  It is why even in this abundance of web development, I would still rather program a client application.

Switching technology is painful!

This is one of those things that is unavoidable in todays development environment.  If you are a web developer, you are going to be working with HTML, JavaScript, probably some sort of server side language, and most likely some form of SQL.

It really isn’t worth trying to fight this because you are going to be going against the technology grain to do so.  Although, I do suppose this may be one of the reasons for the recent popularity of Node.js.

What we can try to do is to minimize the context switch as much as possible.  We do this by sticking with a particular way of doing things and not chasing after each new technology of JavaScript framework that comes out each week.

I’m not saying to not learn new things.  It is very important to always be learning.

What I am saying, is to try to find some kind of rhythm with the technology stack you are working with and try not to switch that up.

Technology specific training can really help here as well.  I for one, need to learn JQuery better.  The problem is that when I am working on a web based feature, I am not forced to learn JQuery because I am not in that context long enough.

So what do I do instead?

I waste time Googling for answers.  I know that I have a short coming here and I need to just bite the bullet and spend some dedicated time to really thoroughly learn JQuery, because by Googling for little pieces of it at a time, I am not really making much headway and the context switch ends up stealing what I do learn from my memory.

One more aspect of this is the idea of focused teams.  Many software development groups do not like to specialize their developers onto one focus area.  I agree whole-heartily with the idea of non-specialization. 

But!  There is huge benefit to be gained by keeping the same group of developers working on a specific set of technology or part of the code base for a set period of time.  I’ll talk about this a bit more, towards the end of this post, but the basic idea is that it takes time for people to find their groove.

I think it is optimal to break any large team up into smaller technology area focused teams that regularly rotate every 3 months or so.  The idea here is that you give those teams enough time to get good at what they are doing and actually commit what they have learned to memory, but you rotate them often enough that they don’t end up becoming specialists which are unable to see the whole picture.

Switching teams

This one typically isn’t an issue, but it can be depending on the environment that you are working in.

Teams need enough time to go through that forming, storming, and norming set of phases.  If you are constantly interrupting this process by switching around team members, you are never going to get the team to act as an entity of its own.

Teams are generally more efficient than individuals, because they benefit from synergy, when 1 + 1 = more than 2.

But just like a big truck taking some time to get up speed, a team takes time to get going.  Also like a big truck, a team can gain momentum that individual developers seldom can achieve.

A smaller aspect of this is pair programming.  I suppose that many have been successful switching up programming pairs once a day or so, but I suppose that more teams have been successful switching up pairs at longer intervals.

For me, this interval varies.  Sometimes, I feel like I need to stay paired with a teammate for longer than 2 weeks, which is our regular interval, sometimes 2 weeks is fine.  It depends on what you are working on and how much momentum you have.

They key here is to make sure that you are giving teams enough time to take up their own flag and stake their territory.  Teams can take some time to find their common goal.  Self-direction can really help with this.

The groove

Ever tried to turn a flat head screw with a screwdriver, but it doesn’t quite turn, because you can’t seem to get the head of the screwdriver into the groove of the screw?

You twist that screwdriver around a bit until finally it slips into the groove.  Then when you turn the screwdriver the screw turns with it.

As humans, we tend to be like screwdrivers, we have to find our groove.  We all have this adjustment period where we are fumbling through things. 

It is very important to make sure that we aren’t switching gears so often that we are not actually turning any screws once we are in the groove.

Regardless of what kind of context switching you are doing—whether it is problem domain, technology or teams—it is important to make sure that you are not spending 90% of your time finding the groove and only 10% of your time “in the groove.”

Depending on what you are doing and what the context switch is, the proper amount of time before switching contexts is going to vary, but I think it is very important be aware of this phenomenon and plan around it.  If you don’t you are going to end up spinning your wheels, which is unfulfilling to say the least.

I am often asked what my opinion of doing code reviews is.  My answer might surprise you.

I don’t like them.  I prefer not to do them.

What?

Let me be more specific.  I don’t like code reviews that happen after the work is already done.

I do like code reviews that happen continuously as the work is being done.  This is called paired programming.  (This prezi presentation might also be helpful.)

Paired programming = continuous code review?

Yes.  That is exactly what I am saying.

Think about it for a second.  Can you really have a better, more honest and more interactive code review than paired programming provides?  If two developers are working jointly on a portion of code, it is being reviewed as it is being written.

I’m going to divert a bit to talk about some of the common problems that happen in code reviews, then I’m going to talk about how paired programming solves them.

Code review problems

#1.  Not telling the truth

There really is no value in a code review where no one says what they really think is wrong with the code, and instead picks out some little non-offensive thing like a naming convention that wasn’t followed.

All too often, code reviews are dominated by a fear of insulting the person’s code that is being reviewed.  This kind of weak code review provides no benefit.  I would go so far as to say it is reinforcing the practice of writing bad code, because bad code is rubber stamped.

#2.  Ego

To have a successful code review everyone has to check their ego at the door.  This rarely happens.  Code is something that has been creatively designed, not too many people can take a critique of their labor, even fewer of their art.

Without a spirit of humility and openness, code reviews don’t provide any value.  It is one thing to point out a problem, it is another thing to do something about it.

#3.  Wrong focus

One of the most common errors of code reviews is paying attention to formatting, coding style, or naming conventions.  Those topics don’t belong in a code review at all.

Tools can automatically format the code and statically analyze problems with coding style or naming conventions.  It is a complete and total waste of time to have a human reviewer review any of those things.

Seriously, if someone comes into a code review and they haven’t run the auto code formatter on their code, and they haven’t run the static analysis tools and fixed the problems found there, don’t be rude, just tell them nicely that their code is not ready for review.

Side note here: There is often debate on whether we should enforce code formatting,or enforce coding style, or enforce naming conventions.  YES! YES! YES!  Consistency is hugely important!  Code is read more than written, and consistent code is easier to read.  Have this discussion once, put together the automated tools to automatically format the code and automatically check the requirements.

Don’t spend months making up your special coding standards document.  Use some rule sets from any number of static analysis tools and start enforcing them.  Make them part of your build, make check-ins fail for formatting problems, make your IDE auto-format on save.  Deciding the perfect placement of curly brackets and whitespace is not nearly as important as being consistent.  Just pick something and enforce it.

Code reviews should focus on design, structure, and understandability of the code.  Code reviews should never ever ever ever ever ever ever focus on anything that can be automatically checked or enforced… ever!

#4.  Rush & Inconsistency

Teams rarely have or make time for code reviews.  If they do, it is inconsistent and not applied to all code, which causes the value to be lost.  If you have a huge fence around a perimeter, yet a large hole where people can just crawl in, the fence is worthless.

There is no point doing a code review where the code is not reviewed in depth.  Just scanning over the code and picking on a few variable names here and there does no good.  If you’re not prepared to fully immerse yourself into the code being reviewed, and dive deep down into understanding exactly what it is doing, don’t bother.

Paired programming to the rescue

Paired programming is like just-in-time code reviews.  It solves many of these issues by having a common goal and creating a joint ownership in the code.

As you pair up with different members of your team, you are likely to be more honest, be less egotistical, focus on the problem not the conventions, and delve deeply into the code.

It is no secret that my preferred modus operandi is no code review, instead paired programming, with everyone monitoring commits to source control, and can flag something and have a discussion if they see something troubling.

What if paired programming is not an option?

Well, try to make it one.  Paired programming is a great investment.

But, if you are not doing paired programming, you absolutely should be doing code reviews. I might have extolled some of the problem with code reviews, and I advocate paired programming, but let’s not mince words here.

Pair programming is a better way of doing continuous or just-in-time code reviews.  Not doing any form of code reviews is just plain stupid.

If you had a construction team building your house, or your 20 million dollar sky scraper, and they told you that they were not doing engineering reviews of the work that was done, you would probably fire that construction company on the spot.  Building software is several levels of complexity higher than that of most physical construction projects.  If you call yourself an engineer and you are not subjecting your work to regular review, you are just an amateur playing “engineer”.

So, if you must do the old-fashioned code review, here are some tips I found useful:

• Encourage people to be honest by doing some exercises where everyone reviews some code that wasn’t written by anyone on your team.  Encourage people to be as prejudice as possible when reviewing the code.
• Set your expectations.  Code reviews are not an approval process, they are an improvement process.  Make sure the team is aware of this.  Code reviews are a place you take your code to make it better, and to better your skills.  Foster that kind of thinking.
• Automate all of the nit-picky stuff and set coding standards, formatting standards, and style standards.  Decide what they will be together, or have your experienced people do it, but get it done, make conformance non-optional and make it automated.
• Develop consistent standards and practice about doing code reviews.  Set aside enough time to delve deeply into the code.  Set and enforce standards of when and how code is reviewed.
• Lead by example.  Proactively ask members of your team to look at your code and tell you how to improve it.  Ask if this can be done a better way.  Show a genuine interest in feedback and improvement, this attitude will catch on.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.

1. Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
2. Create a common thread for people who are already basically doing what I am suggesting.

Three Pronged Fork

I want to present Kanbanand as a three pronged fork.  In my mind there are 3 distinct areas of a successful Agile process which must be addressed.

• Business and overall encompassing project process.
• Development practices, including standards and best practices.
• Infrastructure: build systems, deployment, source control.

We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.

Process

Rules:

1. Project is broken into stories which are small vertical slices through the system which are prioritized.
2. A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
3. At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
4. The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
5. Teams always pull in work, work is never “pushed” in.
6. Once work has been approved as “done” it can never be “not done”.
7. Find something to measure and measure it.
8. The team is responsible for, and empowered to determine how the team accomplishes its goals.

Values:

• Roughly same sized stories over irregular sized stories.
• Stories specifying what, over stories specifying how.
• Stories that are one sentence over stories that are one page.
• Talking about how to move the board forward over talking about what I did or someone else did.
• Cross functional teams over specialized teams.

Development

Rules:

1. All code is unit tested.
2. Static code analysis tools are used to set code standards, all code must meet those standards.
3. Any code that is done, is completely done.  It is refactored, it is unit tested, it meets the quality standards.
4. Code is never commented out.  Anyone is allowed to delete any commented out code at any time.
5. Determining code is meeting the quality standards must be done in an automated way.
6. No one owns code, anyone can work on any code.
7. Documentation is ONLY created when it will serve a known purpose and has an immediate value.  (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system.  Automated tests document the behavior of the system.)
8. Testing requirements come from the customer, not from the developer.

Values:

• Test driven development over writing unit tests after the code is done.
• Pair programming over working alone.
• Readable code over smaller sized code.
• Doing things right over doing things fast.
• Showing the customer over asking the customer.
• Impromptu discussions at white-boards over scheduled meetings.
• Building tools that will help make completing ten things faster, than completing one thing faster.
• Writing automated tests over manual testing

Infrastructure

Rules:

1. Code is continuously built and integrated as soon as it is checked in.
2. Builds build code, run unit tests, run quality checks, produce deployable bits.
3. Builds fail if any unit test fails, or any quality check fails.
4. Code is only deployed from the exact bits that were produced by the build machine.
5. Code can be deployed to any environment with the push of a button.
6. Production data never goes to any other environment.
7. Developers can always run a local build which is the same as what will be built on the build server.

Values:

• Moving forward to fix problems over rolling back.
• Integrating soon over merging later.
• Quick builds over slow builds.
• Deploying on demand over deploying on a schedule.

Feedback?

That is my first crack at it.  I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful.  I tried to keep the things that involved judgment calls as values.  I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.

Let me know what you think, or if you have any suggestions.  I will update this post as this list evolves.  I am sure there is something I missed or could state in a better way.

Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand.  If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.

There were some really good sessions and good discussions on Agile, Scrum and domain specific languages.

I think events like these are important because they help us to zoom out a little and see what kinds of things other people are doing in our field and what companies around us are interested in high quality software.

Code camps are also a great place to get some experience doing presentations and share what you are working on.  Networking opportunities abound.

I presented two talks this weekend.  I am posting the links to those here.

The first presentation I did was on Pair Programming.

You can find the presentation on Prezi here.

We also did a live pair programming session, which I thought went pretty well.  We ran into some of the issues that often come up with pair programming, like being afraid to tell someone you don’t like their method name.

The second presentation I did was on Creating an Internal DSL for Automated Functional Testing.

You can find the presentation on Slideshare here.

We went over how to go about creating a good automation framework which fills in the gaps between the business language and technical language.

Thanks to everyone who attended.

The best example is one I’ll steal from Uncle Bob.  If you haven’t read this little dialog before, take a moment to do it now.   Paired programming is essentially two developers sharing one keyboard and mouse.  Both developers work together to write the unit tests and code to make them pass.  Often you will switch who has control of the keyboard and mouse.  I intricately tie together this practice with Test Driven Development (TDD), because a large amount of the benefit is in the ability for one developer to say, “Hey let me see the keyboard”, and write a unit test which will make the code fail.

Why paired programming?

There are many benefits some obvious and direct others as a side effect.  When you have two developers looking at the same code, you have two sets of eyes looking at the code as it is being written.  You have a much bigger coverage area of the problem domain, and are less likely to write bugs or miss something.  At the same time you are also having a live code review in the context of the code.  Also you are getting two developers familiar with the same piece of code, rather than “the dude who wrote all the DAO code.”  These benefits alone make paired programming worth it, but there are a few more.  Often one developer would get stuck on a difficult problem where two can easily push through.

Some of the indirect benefits are that when someone works alone they are less likely to be working.  Honestly, in an 8 hour programming day you might get 4 hours of work.  Now a good amount of this is due to distractions, like email, instant messages, random questions, not just slacking off (although some of it is.)  When you have two developers sitting at the same computer, it takes a larger amount of force to cause a distraction.  If someone is sitting at my desk, I am less likely to look at my email or be drawn away from the work I am working on.  You are more likely to get 6 hours or more out of two developers at the same computer with paired programming.

On the job training and cross training is another large benefit.  When you pair up a weak developer with a strong developer you will get the weak developer picking up the good practices of the strong developer.  Pair up two strong developers, they teach each other the little tricks that make them so effective and they both become more effective.  Pair up two weak developers, and you… get a mess for someone to clean up… Don’t do that!  Have a tester who should learn some development, pair them up with a developer or vice versa.  Even a product owner or business person can benefit from paired programming to better understand how the application is being developed.

Does it really work?

In my opinion yes.  I have personally seen the benefits over years of doing development work, practicing paired programming whenever possible.