Task-Switching is for Computers, not Humans

Computers are much better at multi-tasking than humans are. Why? Because a computer is designed to multitask. When a computer switches from performing one task to another, it saves the entire state of the task being switched out, enabling the computer to literally pick up where it left of when it returns to that task.

Humans aren’t wired that way.

Consider an activity that requires keeping a lot of details in your head along with applying some creative thought; where mental focus and concentration is essential, like programming. Programmers keep a lot in their heads during the act of programming, like how the code will be organized, what data structures are being used, the naming and use of variables, all of which is centered on the act of translating business requirements into detailed instructions for the computer to follow.

What happens when a programmer is pulled of one programming project to work on another project or problem? Valuable productivity is lost. In his book Quality Software Management: Systems Thinking, Gerald Weinberg proposed a rule of thumb to calculate the waste caused by project switching:

The graphic illustrates how switching between only two projects is very costly: You lose 20% of your time! By the time you get to three or four simultaneous projects, you’re losing significant productivity to task-switching.

This is also supported by recent studies written about in a Wall Street Journal article New Studies Show Pitfalls Of Doing Too Much at Once. One study in the Journal of Experimental Psychology points out that people who multitask are less efficient than those who focus on one project at a time, because the brain has to overcome "inhibitions" it imposed on itself to stop doing the first task in order to take on another tasks.

Not only that, but attempting to manage two mental tasks at once reduces the brainpower available for either task, according to a study published in the journal NeuroImage. This was proven by a relatively simple experiment where subjects listened to sentences while comparing two rotating objects. It was found that the ability to process visual input dropped 29% if the subject was trying to listen at the same time.

How does this translate to my day-to-day software management universe? As a software manager, I have my own personal rule that I manage by: If a project is important enough to start, it is important enough to finish. When someone is allocated to a project, they are expected to see that project through to the end; and I resist pulling anyone off of a project at all costs.

Equally important, I regard interrupting programming time as something that I only do as a last resort, when there is a critical issue. Like when another team is dead in the water and someone else has the skills and knowledge available to help un-stick that team, or when a customer is down and I know that one or more individuals can help. As a rule, I do everything I can to make these situations exceptions that occur very infrequently.

I'll wager that virtually everyone agrees that task-switching of programmers is very counter-productive, but all too often the day-to-day practices of management translate into interruptions and disruptions of productivity! We're all human, and it's easy to think, "What is one day out of a schedule slated to last a few months?"

Let's take a look at an example provided by James Shore and Shane Warden in their book The Art of Agile Development. They note that a programming task estimated at 8 hours could take 2-3 calendar days if a programmer gets interrupted.

While the impact of interruptions on an entire project don't seem significant when they occur, keep in mind that projects rarely have one BIG event that someone can point to as THE cause of a target date being missed. The reality is that software projects get into trouble a little at a time, and schedule misses are almost always due to the cumulative effect of lots of little things going wrong over time, like tasks taking longer than estimated. And if you are interrupting programmers, you are disrupting projects!

Programmers meed concentration time – and blocks of it – to be productive. Leave task-switching to computers.

Six Ingredients for a Successful Team

What Makes a Team Successful? I’ve watched different sports teams succeed and fail over the years, and regardless of whether you are talking about high school sports or professional sports, the same key ingredients are present in the teams that are successful. The same holds true in the workplace.

1. A clear goal with a specific focus. Even teams that should be great will fail if they attempt to take on too much. By keeping the focus narrow, and with clear objectives, teams can achieve success. If you truly have a lot of ground to cover, then cover it in small steps, using specific, measurable intermediate goals. Too many software projects in particular fail because they attempt to cover too much ground all in one shot.
   


2. Talent. Without talented players, you can only go so far. Talented people have a gift, the capability to perform, with the potential to reach greater heights than others. On the flip side, there are talented people out there who don’t reach their true potential because they don’t work to develop their potential. They remain on par and competitive with others, but rob themselves because they don’t apply themselves.


3. Dedication. This is displayed by those who are enthusiastic and willing to apply themselves to their chosen sport or profession. They study and learn. This can make the difference between being darn good and being a superstar. Even an average Joe can compete with others that possess greater talent if those with the talent aren’t working to improve their game. Larry Bird was known for dribbling a basketball over every square inch of a court prior to a game. Why? Because he wanted to find the flat spots where the ball didn’t bounce back as quickly; he filed this away and used this knowledge to his advantage to make a steal. His dedication provided him an edge. In the working world, my take is that dedication is displayed by those who have the “I’m responsible for …” attitude versus those who have the “I work at… ” attitude.


4. Practice. Talent and dedication do nothing if you don’t practice what you have learned. As a software developer in years past, I did something that I advocate to this day: Put together your own, small applications to learn things outside of whatever tasks you have going on with your current day-to-day job. This will likely be done on your own time, on your own dime, but it will give you practice and experience that broadens your knowledge and abilities. Focus on understanding developing and honing skills without cutting corners. This means using good approaches to development, not hacks. Practice alone doesn’t make perfect. Perfect practice makes perfect.


5. Coaching. Any team that is successful has a good coach behind it. Coaches motivate, recruit, and set the tone and direction. They get people to understand what they need to do and why they need to do it. They recognize and reward people for a job well done. They call the plays and expect the best from themselves and those on the field. They make the hard choices of benching people or removing them from the team when necessary. It’s about blending the individual talents into a cohesive, unified team, helping everyone to realize their full potential in the context of working collectively as a team. Coaches watch the hand-offs, transitions, communications and interactions between teammates.


6. Playing as a team. The most successful teams are greater than the sum of the parts. Great teams communicate openly and honestly, they understand each others’ strengths and weaknesses, and they push each other to become better. The team score matters the most, but everyone is expected to contribute. Great teams don’t have weak links, and they don’t tolerate laziness. They want talent, but will take someone who is dedicated, hard-working and willing to practice over someone with talent but no drive or lacking in the desire to be a part of the team. The real need for successful teams is to get everyone flowing in the same direction, dividing the effort – with everyone pitching in – to reach a common goal. Personal goals are second to the team’s goal because great teams understand that they can achieve more than a collection of individuals who are out for themselves.

Succeeding with QA Automation

As I mentioned in my last post, a change in the date and venue for our annual user conference was a curve ball in terms of a presentation that I was slated to be a co-presenter for: QA Automation. Instead of co-presenting, I was the sole presenter, tasked with creating and delivering the presentation! I’ll cover the highlights of my presentation, with one caveat. I structured this to talk about some general observations about QA Automation and then conducted an open discussion. I wanted to test my observations and learn from others.

I opened with the following questions:

• What should be automated?


• Can manual testing be eliminated by implementing automated testing?


• Can QA Automation improve productivity?

What should be automated?
The following diagram depicts the areas and focus of testing that can and should be automated.


Can manual testing be eliminated?
We are an Agile/Scrum development shop, and our experience has proven that automating within a sprint is not advantageous. From an efficiency and effectiveness standpoint, features need to be complete before they are automated. Manual testing can and should focus on validating the new features and developing good test plans that can be automated later.

Can QA Automation improve productivity?
There are a few objectives that QA Automation can achieve.

Reducing the “QA bottleneck” that is invariably present at the end of software projects, and also where the squeeze to make deadlines frequently occurs.

My other observation is that automated tests take less effort to run than manual tests, and as a result they are likely to be run often. This alone can increase your confidence in the software.

When I look at QA automation, my philosophy matches my opinion of manual QA, and is that you don’t want to be in the business of “testing your way to quality.” If you feel that you have a large number of defects that are occurring in the system test phase, look for other areas to improve in your software development process. Perhaps you need to improve your requirements definition, or improve on design and code reviews – preventing defects from finding their way into the code in the first place.

QA and Development Role in QA Automation
We have experimented with using traditional QA and Software Developers paired together. This has proven successful, and I think that pairing leverages strengths that both professions bring to the table. The first area that I explored was the subject of unit tests. There are those who state that the developer is the best qualified resource to write unit tests, because the developer knows the code. I don't share this opinion!

Yes, the developer knows the code, and therein is the danger. Most developers that I know aren’t good at testing. One of the reasons for this is that if you know the code, you are likely to be thinking in terms of the “happy path,” – how the code should function – and not in terms of the fringe cases that a good QA tester will consider. Pairing can produce better tests.

I asked about experiences that those in attendance had with Test-Driven Development (TDD), where you start with unit tests that fail and then write code to make the test pass, but no one in the audience had any real-world experience to share.

My take is that TDD is useful, particularly since the book The Art of Agile Development noted that this forces developers to think in terms of interfaces first and implementation details second, providing a design that is more comprehensible. I would advocate the QA could help strengthen the tests here as well, for the same reasons noted above.

Conversely, we’ve found that Development can help QA. They can help QA with things like code organization and source control. Developers naturally have a lot of experience with the design and development of common functions, and can bring practices like design and code reviews to the QA Automation table.

A group discussion yielded some more perspective on this, the main takeaway being the realization that it was possible to get into QA Automation without considering code design and management. And just like any software, you could end up with spaghetti-code that is difficult or impossible to maintain, neutralizing any gains from your investment in QA Automation.

Conclusion
The bottom line for me: QA Automation is an investment, and you need to consider the cost of the tools, training and mentoring, script (or code) organization and management. Target those areas where there will be a need and a return for the automation dollar. Ultimately, you need to answer the following questions related to QA in order to determine if your software is truly “done”:

• How much of the product is being tested through regularly-executed, automated testing?
  
  
• Does manual testing adequately cover the remaining bases, or are there gaps?


• Is your failure rate is known and defensible?

Change and Our Annual User Conference

At the end of August, I attended a user conference as a vendor. This was nothing unusual, since we are always the featured vendor at an annual conference in the fall that was essentially built around our company and product.

This year, however, we made some changes. Change was due, and it wasn’t a question of what, but more of a question of when. For more than one reason, our conference attendance has been declining, and low attendance doesn’t make you feel great as a vendor. There is simply less energy and excitement to get your blood flowing.

For us, conference attendance has been dwindling for GOOD reasons. We develop enterprise-level software for the insurance industry, and we have made tremendous strides in improving the quality of our releases in the last several years. We also do a much better job of addressing critical issues and adding enhancements on behalf of our customer base.

Needless to say, one unfortunate reason that we had higher attendance in years past was because our customer base wanted to beat us up! They felt that they needed to corner us and collectively press us to address our quality issues and their needs. As we’ve improved our delivery and paid more attention to servicing our customers, they have had less to complain about, which in turn reduces the urgency that customers feel about attending a conference.

Over the years we’ve also increased our on-site customer visits and leveraged the Web, conducting Webinars, posting information to a new Community Site that we developed, and generally have been more open and communicative. Our customers understand what we’re working on, what the priorities are, and what our challenges are because we communicate better. They also appreciate our challenges and the work that we do as a result. And again, this gives them less reason to attend a conference.

They also understand and appreciate that we have a certain capacity to continually add new capabilities to our product line. We’re not a large organization, and these days we are sized appropriately in terms of the revenue that we generate. This does place constraints on us, but our customers agree with our overall vision and direction; the big question now is: How fast can we deliver on our vision?

In general, our customers enjoy the time and dialog with us at the annual conference. But it has become very tough for us to fill up an entire conference with compelling new content on an annual basis. At the beginning of the year when we began planning for the conference, we understood that the economy was down, and we expected that our conference attendance to be down as a result both of these factors.

Fortunately, we had another option! We used to be an independent operation, but now that we are a part of a larger company, and it was advantageous all the way around to combine into one conference that represented a larger suite of sister products under one one corporate umbrella.

Of course, this change had some impacts on us. The date for the combined conference was ahead of our usual conference date, so many of us scrambled to prepare presentations and demonstrations. Not that we didn’t scramble in years past – after all, does anyone ever have as much time to prepare as they would like? I found myself scrambling in August, the month when I take a week off to enjoy the short summer that we get in Maine.

My role at these conferences is always as a speaker on one or more topics, and I typically am involved in putting together rolling PowerPoint presentations for our booth. I’ve also done my share of booth-duty in years past, demonstrating products and answering questions.

This year, the change in location and the moving up of the date changed our original planning. I was slated to co-present on QA Automation. As a development manager, I have been involved with QA Automation efforts at our office this past year, in part because I allocated a developer to assist in this effort.

Changing of the timing and location of the conference left me in to my own devices – I was suddenly the only presenter! Fortunately, I have given my share of presentations over the years, so this did not produce any anxiety. I did need to spend some time thinking about just what the heck I was going to present, however…

Next post, I’ll cover my thoughts about QA Automation, using material that I pulled together to present at the conference.