Author: Alan Page

I’m back at the job after a long break (including a month vacationing in Australia – trip report coming). I spent a chunk of time after the Xbox One ship figuring out what the next step in my software career was going to be.

In the days up to the Xbox One launch, I hinted on twitter that after One was out the door, I was on to something else. At the time, I had no idea what I’d be doing – while development and improvement on Xbox One will continue for years, there will never be another opportunity to ship the initial One hardware and operating systems. I still have a ton of passion for the consumer space, and I fell in love with the Xbox as a living room entertainment device over the past two years, but I knew I was ready to do something new.

I’ve been at Microsoft for nineteen years now (yes, I’m old), and despite that, I try to keep an eye of what’s going on in the industry and consider non-MS opportunities if they’re the right choice at the right time. The career advice I give frequently (and follow adamantly) is to follow the Three P’s – the Person, the People, and the Product. This means that you should work for a person you respect and will enjoy working with; with people (a team) that works the way you like; and on a product (or technology) you are passionate about. Surprisingly, I found these in a company outside of Microsoft – along with all of the goodies that would make the move a good one for my family…but in the end, the relocation wasn’t the best move for me now, so I ended up passing (and hopefully didn’t burn bridges in the process).

In the end, I followed my Three P’s advice and chose to work follow my Xbox manager to a new team, working with people I know and enjoy working with, and on a really cool (and unannounced) technology. I’m really happy with the choice I made and I’m excited to get back in the groove with a new team and new project.

Oh – and Happy New Year.

I’m on vacation, and this post is auto-generated. See, you can trust automation sometimes…

Another year gone by, and another few dozen posts. Here are the top viewed posts of the last year (note – not all of these were written last year – this is just what people read the most last year).

In order of views:

• Titles for Testers
• Dichotomy for Dummies
• Debugging for Testers
• Coding, Testing, and the A Word
• Exploring Testing and Programming
• Why Information is Important
• Tear Down the Wall

Thanks to everyone who reads, comments, or reacts on Twitter to my rants and ramblings. Plenty of big announcements coming up, as well as more thoughts on what I see happening with testing in the future.

Happy New Year.

I’m heading off for a long vacation today, so this is likely my last post of the year. It’s been a crazy year, and I thought I’d end it with something that a lot of my recent posts have been leading to (e.g. this post on tearing down the walls).

Some of you will hate this. I’m not sure if it’s because you’re afraid of your job, or because it’s so far out of your world that it doesn’t make sense. For you, let me tell you about the audience who will read this and say, “ho-hum – tell me something I don’t already know”.

Testing as we know it, is changing – and the changes are big (for some folks, at least). Testing as an activity will always exist. But I see test as a role going away – and it can’t disappear fast enough.

Test Is Dead (or is it)?

A few years ago, my friend James Whittaker angered testers world-wide with his talks on Test is Dead. James premise was that for a whole lot of software out there, it’s more cost-efficient to get data and issues from customers actually using the product than from a test team pounding on the product. Unfortunately, way too many testers failed to see the context and big picture of the main point and screamed loud and wide about how quality would suffer without testing.

But James was far more correct than people give him credit for.

Hiring testers to pound quality into a product after it’s been developed is a waste of money. The more I think about it, the more I realize that Test Teams are an artifact of older, predictive (staged / waterfall-ish) software development models. The notion that one team (or part of a team) is responsible for writing code, and another part of the team is responsible for making sure it works as expected seems wasteful to me (even after spending the majority of my career doing just this).

Test teams are dying. You may disagree, but I encourage you to take a critical look at whether you believe a non-integrated test team is the most cost efficient way to evaluate a product. Yes, I know there are companies formed entirely around evaluating already-developed products – but I believe that the days of testing-quality-in (the equivalent of the people who clean up after animals in a parade) are ending (or ending, at least, for the quality software products of the future).

Testing is NOT Dead

Before you skewer me with your protests (and some of you will, despite my best efforts to explain), let me reiterate. Testing is not going away. The testing activity will thrive and improve and evolve. It’s just time to think about getting rid of the old ways of thinking about who does the testing and where it happens.

Plain and simple, we (the software industry) have been wasting money for years letting testers play safety-net for lazy developers. It’s much more cost effective and efficient for developers to write unit tests and some or all functional level tests – and maybe more. Other developers on the team (many of them former testers) should focus entirely on “ilities” such as reliability, performance, security, etc. as well as evaluating end-to-end scenarios (epics) spanning multiple features. (related paper from me here – it’s a few years old, but I think it foreshadowed this change nicely).

There are other activities – like data collection and analysis (feel free to insert the buzzword “Data Science” here if you wish) and other tasks we need software teams to do – but we don’t need separate teams for those tasks. We need people to do those things, but those specialists can work anywhere. Why is it that I’ve seen just as many performance or reliability teams reporting to development managers as I have seen reporting to test managers? Some of my colleagues talk about the need for testers to “transition” to data science or other roles. In reality, it may be a transition, or it may be different people. It doesn’t matter (what remains true, is that we will have an increasing need for people who can analyze data). I think one of the only reasons we don’t talk about having a specific “Data Science Team” is that we already have enough disciplines in software engineering, so we default to shoving them into the best suited discipline for analysis roles.

Whole Team Approach?

We need integrated teams – not separate teams. We need teams of generalizing specialists to make great software. The disciplines and teams get in the way of efficient creation of quality software. Some say that the programmer/test relationship provides checks and balances – but I see no reason why those discussions and positive conflicts can’t happen on a team where everyone works tightly together.

I’ve seen a few mentions of the “whole team approach” to software creation, but that term (to me) doesn’t adequately describe how great teams (can) work. In a team full of generalists, everybody can do everything, but nobody does anything particularly well. That doesn’t work if you’re trying to make quality software. In a team of generalizing specialists, everyone does something (or a few things) really well – but the team members are adaptable when necessary. Teams need specialists in design, user interface, performance, reliability, deployment, internal infrastructure, data analysis, and scads of other areas. Teams also need people who specialize in testing – specialties that include end-to-end evaluation and risk analysis, as well as coaching developers writing unit and functional tests.

But the separate team for test is dead. It’s a waste, and we need to stop thinking about putting our specialists on separate teams.

Testing is a Specialty

I’m looking at a twitter feed full of comments from testers worrying about what this means to their careers. A good tester, as part of a team of generalizing specialists is worth every bit of salary and value as any other specialist on the team. Test “specialists” who can’t provide this level of value, however, probably should worry about their career. Test may be dead, but good testing will live and be valued for a long, long time. But we need to stop thinking that we need test teams to pound quality into a product, and figure out how to fully integrate great test minds into great software teams.

There’s a subtlety here that goes beyond semantics. Jobs (most of them, at least) aren’t at stake here. The great testers of today will be great test specialists on software teams tomorrow. It doesn’t’ matter if they code or not, as long as they provide value and contribute. I’ll repeat that, because I can almost guarantee a comment about how stupid I am for proposing a world where testers need to code. Test specialists won’t (necessarily) need to code. Many of the “test automators” today will write features, as well as functional tests (using their mad automation skillz) – and they’ll coach the programmers on how to do the same – leveraging the specialties of each other.

A glance through any testing community will show dozens of definitions of what testing is, and what testers do. It’s too much. It doesn’t matter. We need to stop building organizations where one team writes code and another team tests it. Testing needs to happen all of the time, and at the same time as development. For this to happen, we need to get testers out of their test teams, and fully integrated into software teams.

A Better Future

Today, testing articles, posts, and tweets are filled with whining (or mere complaints) about the sorry plight of testing, the lack of testing respect, the difficult of measuring testing, and other worries of the testing community I’ve been hearing for the past 20 years.

But a new world where testing is merely a specialty within the software team eliminates these worries. There’s no more us versus them. We have a team, and we each supply different specialties that contribute to the team’s success.

Preemptive post script

I’m leaving (on a jet plane), and I half-rushed this post out. I half (or full) rush most of my posts, but this one is important. I’ll try to respond to comments (and hate mail) when I land, but I expect I’ll have follow ups and re-writes coming. I’m positive there will be much speculation on what I didn’t mention, so I’ll deal with that soon as well.

More will come.

Five years ago this week, How We Test Software at Microsoft hit the shelves. The book has done well – both in sales, and in telling the story of how Microsoft approaches software testing.

An unfortunate aspect of writing a book like this is that after five years, most of the book is obsolete. Sure, there are some nuggets that stand the test of time, but so much has changed – and is changing, that it’s hard for me to recommend much of it as practicum. I don’t know if a new version is warranted – or necessary, but you never know what will happen.

To be clear, I’m still proud of the book, and think it has a lot of great ideas that will help many companies – it’s just not an accurate reflection of how Microsoft tests software. Here’s a section by section recap / overview of what’s changed….

The New World

Section 1 – About the Company

Now that we’re a Devices and Services company, the description of our product groups is flat out wrong. Beyond that, our organizations are much different – our test dev ratios are changing (from nearly 1:1 at the time of writing to nearly 2:1 dev:test today).

Five years ago, a few teams used adaptive (agile) engineering approaches, whereas now, nearly every team in the company is using or experimenting with some flavor of adaptive development. We ship almost everything faster. Testers are moving to analysis of end-to-end scenarios and data analysis, while “traditional” functional testing is moving (where it belongs), to the programmers. The career path examples we showed in the book have all changed – and will likely change again as the company continues to adapt and grow.

Section 2 – About Testing

The techniques described in the about testing section are all still relevant (although these days, I could easily increase the chapter on test design by about 50 pages and keep it full of good ideas). What’s changed most (and what will continue to change) is how much of the activities in this section are carried out by developers (and how much more of will be carried out by the developers in the coming years.

I’m still particularly happy with the chapter on Model-Based Testing (and thanks to Michael Corning and Harry Robinson for their help with the ideas for this chapter).

Section 3 – Test Tools and Systems

The section on bug reports is good – as long as you have the need to track bugs formally. Many teams can (and do) get by with fixing bugs as they find them – with no need to document the bug. I’ve also become even less of a fan of tracking test cases, but the examples are probably still valuable for those who need to do this.

It’s hard to believe that five years ago, I failed to recognize the critical relationship between test automation and test design (they’re in different chapters!). Although the technical information is correct, I would like to take The A Word and shove it into chapter 10 as an addendum.

The customer feedback systems I wrote about have expanded massively – and are much more of a focal point these days – both in the data we gather, and how we use it.

And finally (for this section), what blows me away is how much different our approach is to testing web services. I don’t think Ken will be mad if reveal that this chapter is embarrassingly obsolete. This isn’t because what we were doing then was bad…it’s just that we’ve grown so much in our approaches here that our five-year old processes seem obsolete in comparison.

Section 4 – About the Future

I suppose this section is still relevant  – and most of the future as I saw it in 2008 is reality today (although much of this section, in hindsight, could have been better written.

Next?

In a perfect world, I’d write another HWTSAM. Maybe someday, I will, but it’s not on the roadmap for today. There are too many big changes coming (both planned by MS, and spinning in my head) for me to put a stake in the ground. Or maybe, software is changing so much that trying to capture how a company does it at a point in time is impossible. I’ll need to think about it.

For those of you who bought (and read) HWTSAM – thank you. There’s still some good stuff there, but read it with a grain of salt (or at least from a lens knowledgeable that it’s a half-decade old book).

I intended for my last two posts to cover the main points of my STAR West keynote, but I neglected to mention a few of the books I referenced in my talk (which not coincidentally, are some of my most recommended books for those studying leadership.

I first read Leadership on the Line as part of a class I took several years ago, and many of the concepts have stuck with me. My favorite quote (slightly paraphrased) is, “Leadership is disappointing people at a level they can tolerate [absorb]”. Too many people try to lead by pleasing everyone. Good leaders are comfortable making decisions that not everyone agrees with, and know that teams are more productive when there is a slight level of discomfort or apprehension (as opposed to the extremes of complacent or overwhelmed).

I am a huge Patrick Lencioni fan. Lencioni writes business novels – stories about business that explain some of the principles and ideas he believes in. His Getting Naked is a peek into how he runs his consulting business, and mirrors the way I approach leadership and influence. Humility and learning in context are great approaches for anyone diving in to a new project, and I have found every one of Lencioni’s novels to be a page turner. Lencioni (in his one non-business novel publication) is the first person to clue me in on the fact that product quality is directly related to team health – something I’ve been reading more about over the past few years, and something I believe in whole-heartedly.

In my experience, there are a lot of parallels between good leadership, and good consulting (bearing in mind, that the definition of a consultant has changed remarkably over the past several years).

I could write a whole post on how this book relates to leadership. And, in fact, I did (and if you’ve read this far in this post, go read that post now for more info).

 

Several years ago, I had an opportunity to hear Peter Spiro speak, and to also have dinner with Peter and his daughter while on a business trip (we were both speaking at the same internal conference). In his talk, and at dinner, he recommended The Feiner Points of Leadership. I read the book (and have re-read it several times), and I always seem to find ideas I can use (and ideas that are weirdly relevant to whatever I’m going through). The writing is conversational, and the advice is practical (opposed to the theoretical hand-waving in most leadership books).

There are at least a dozen other leadership books on my bookshelf that I like, but if you were to see my beat-up ragged copies of these books, you would know they’re the most used (and most loaned) books in my personal library.

In my last post, I wrote a bit about what it takes to build a great team, and how it takes a great team to build great software (which also covers about half of what I spoke about at STAR West in October). In this post, I’ll see if I can cover the other main points from that presentation.

Leadership and Management

Many people still get leadership and management confused. One does not have to be a manager to be a leader (and most certainly, not all managers are good leaders). As someone who has spent the majority of their career as a peer to test managers (yet in a non-manager) role, I frequently see the manager role as one that runs the testing business, while my role is to improve the testing business (in fact, I would say that many of my non-management Principal band peers provide as much, or more leadership to the team than the people-managers on the team).

Many people (and company cultures) assume that career growth for a software engineer always involves a “promotion” into management. Too often, this policy results in turning great software leaders into mediocre managers – or worse, enables mediocre engineers to prolong their career by becoming completely inadequate people-managers.

The formula to fix this isn’t difficult.

1. Let the people on your team with demonstrated skills in people management manage the team (and there are dozens of ways to discover who has, and does not have these skills before making someone a manager)
2. Encourage strong engineers to take on team leadership (but not necessarily management roles).

In my last post, I said there’s a direct relationship between team health and product quality. One surefire way to negatively impact team health (and subsequently product quality) is to put people in roles they’re not ready for – or roles where they cannot succeed.

Learning Leadership

Not many things irk me more than self-proclaimed leaders. Being a great leader involves study and hard work. Just as great engineers know patterns and heuristics that enable them to build great software, great leaders know patterns and heuristics that enable them to lead.

Too many leaders (or those who call themselves leaders) rely on only a few leadership tools – often thinking that if they merely tell people what to do, that they’ll do it. Leadership is influence, and influence requires credibility, compassion, humility, strategy and many other factors. You can’t lead with only a handful of leadership ideas – you need dozens or more.

It’s just as important for a great leader to have a toolbox full of leadership ideas as it is for a software engineer to have a toolbox full of design ideas. Not enough people understand this point.

If you think you’re a leader – or if you want to be one, experience alone is not enough to get you there. Work at it, practice, and learn. And then work at it, practice, and learn some more.

I picked up my Xbox One this morning – a special white console with “I made this!” engraved on it. The reviews started appearing last night, and for the post part, they’re quite positive (and I’m not surprised by the drawbacks listed in the reviews I’ve read so far). Now that this project is officially behind me – and before I figure out what’s next, I have some backlog blog posts to share.

Lessons Learned

I gave a keynote at STAR West in October on “Lessons learned from Xbox One”. Given that it was an unreleased product at the time at the time of the presentation, rather than talk about the details, I spoke mostly about the team, and how strong team principles lead to great software projects (I spoke of my love of the Xbox team in a previous post – https://angryweasel.com/blog/?p=723). I thought I’d share a few of those lessons.

Lesson 1: Build a Great Team

In order to build great software, build a great team first. I’ll say that differently in case it didn’t sink in (or make sense). Worry about building a great team first, and then let them build a great product. I realize this isn’t always an option for every organization, but I see too many teams take an existing group of people, and then try to make a product that isn’t in the sweet spot of that organizations strengths. A good team can usually make a few good things, but a great team can make anything great.

That leads to a phrase I heard once that rings too true – “Don’t ship your org chart”. Just over ten years ago, I was working on Windows CE (an embedded operating system loosely based on Windows). During product planning, I noticed what looked like an unbalanced number of networking features (there were a lot – including some relatively obscure functionality). I didn’t know if it was a product strategy decision, customer requests, or what, so I asked. The answer was, “Our networking team has a lot of people, and we need to keep them busy.” To this day, I still don’t know why there was no attempt to shift people around as needed for features customers wanted, but I do know it seemed silly at the time, and it seems silly now.

Which leads to…

Lesson 2: Diversity and strengths

I’m a believer in teams filled with (or at least largely populated by) specializing generalists. Everyone certainly doesn’t have to be able to do everything, but every team member should be able to do many things well, and a few things very well. It’s important, when building a team to have diversity in both generalization and specialization – and match those skills with what’s needed for your project.

In my opinion (and experience), you can’t have enough deep specialization. My official job title at Microsoft is Principal SDET – that means I’m in the Principal band, and that I don’t manage people. I think far too many testers (and organizations) see management as the only career growth path, when there is huge value in developing, growing, and nurturing the experience of experienced individual test contributors (which reminds me, I wrote a paper about the value of highly experienced non-manager testers a few years ago).

There are 100 or so Principal SDETs at Microsoft (plus more in the management ranks that I haven’t counted lately). When I joined the team two years ago, there were five of us (Principal testers) – two on the Xbox Live team, and three on console. For various reasons, we wanted a name for our virtual team on the console software team. The mythical Hydra name was already in use to describe our three-OS model, so after a bit of deliberation, we named ourselves after Hagrid’s three-headed dog in Harry Potter, and Team Fluffy was born. Over time, we expanded (and promoted) our way to eight Principal testers in console, and three in Live, for what I believe is the highest team concentration of Principal testers at the company. Someone asked once if we needed that many Principal ICs – but honestly, I don’t know how we would have made this product without the diversity and deep skills of this group. I think the eight of us all contributed significantly to getting this product shipped on time with quality.

Teams and Products

Yes – products are important, but I’m a huge believer in the team first – and I think it’s just as difficult and challenging to build a great team, as it is to build a great product – and that we should all put the same care and passion into hiring and developing our teams, as we do in building great software.

I’ll share a few other lessons later this week.

I first heard of “10x” software development through the writings of Steve McConnell. Code Complete remains one of my favorite books about writing good software (The Pragmatic Programmer, Writing Solid Code, and The Clean Coder are also on that list). Steve McConnell’s rarely updated blog (titled 10x Software Development, contains the following tagline:

Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell’s thoughts about how to move toward the "10" side of that 10:1 ratio.

This article, and this one, are probably the best views from the McConnell side on 10x. They cover a lot of the studies and anecdotal information about the 10x concept. Although the original study cited a 10-fold difference in productivity and quality between different programmers with the same levels of experience, I use the 10x label to describe those software folks who “merely” differentiate themselves in terms of output and quality significantly more than their peers. While I will use the term “10x” throughout this post for conformance with the topic, it’s not an exact multiplication. For me, the term means, significantly higher output and quality.

The Myth?

Recently, there was a bit of buzz about this article about the Myth of the 10x Engineer. The meat of the article includes some valid criticism of the studies citing 10x Engineers, and as someone who is generally a skeptic, I acknowledge that the studies have holes. I think there are a lot of misconceptions about what a 10x engineer actually is, so the controversy doesn’t surprise me.

The article begins with the following statement:

I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half. You burn the candle at both ends. You end up with alcoholism and depression. You’re talking about a very small subset of people. And they might end up in divorce and financial ruin. When people think you’re a 10x engineer, they think you have skills that you don’t. You invariably let people down.

The full article (which, by the way, is very nicely written and worth the read) makes a very good case against the validity of the studies about 10x, and includes several statements from the author’s twitter followers supporting the quote above.

Not a Myth?

But I interpret 10x much differently, and think a lot of commenters miss the point. This, in my opinion, is at least partially due to the “10x” label.

But more importantly, 10x isn’t about working 10x as hard. It’s not even about working twice as hard. It’s not about effort. Being 10x (or significantly more impactful, or whatever you want to call it) is about making smart choices and taking care in your work. I’m sure if I were to put fifty similarly proficient developers in a room and ask them each to implement a known set of algorithms or implement well defined functionality into an existing app, or any other task where the problem and solution are largely understood, that there will be some variance in the time it takes each of them to finish the tasks, but the best in the group would maybe be twice as fast as the average – if that.

Where 10x software engineers excel is in adaptive challenges – where the problem may be understood, but the solution is an unknown (and where the problem may change as the solution emerges). 10x engineers recognize patterns, they know when they’ve hit a dead end, and they can zoom from the 10,000 foot big picture down to minutiae and back again in an instant. They aren’t significantly more productive than their peers because they work eighteen hours a day or even because they type at a whirlwind pace. They are more productive because they solve problems 10x faster than their average peer. They are more productive because there’s less waste in their work – they are careful enough to do things right the first time, but have enough breadth of knowledge that they find the correct choice sooner. You can’t make yourself into a 10x engineer by working harder or longer – you make yourself a 10x engineer by studying and practicing your craft, by investing in learning, and by challenging yourself to continuously make better decisions about how you work.

All that said, not everyone needs to be – or can be a 10x – and that’s ok. But I, for one, want (and love) to work with 10x developers so I can learn from them, learn how they learn, and perhaps discover a few tips to improve my own output and value.

In early January, I’ll hit my 19 year anniversary of working at Microsoft (I’ve worked for Microsoft 18.5 years, and as a vendor at Microsoft for the first 5 months or so). There’s been a lot of change over the years, but perhaps never as much as is going on right now.

We’re getting a new CEO, the review system has been paved, there’s a major re-org underway, and Xbox One ships in 6 days. I can honestly say that the two years I’ve spent on Xbox has been the most challenging, fun, and eye-opening experience of my career. I’ve learned a lot – I’ve had an impact – I’ve worked with incredibly smart people – I’ve made friends. I can’t rave enough about how great it’s been to be part of this team.

But it won’t be the same anymore. Sure, a lot of the people on the team will still be here, but you only launch a console once every 5-7 years. The Xbox software will continue to improve and games will get even better, but you only get to ship the console once. Of course, there’s so much more I want to do here, that there’s a reasonable chance I’ll continue to work on Xbox, but I can’t say for sure yet. I have other opportunities to weigh – and I’m in much need of a vacation and some rest (and some quality time with my family), and this is no time to make big decisions. I’ve managed to change my mind at least once a day for the past few weeks when thinking about what’s next…and just when I think I have it figured out, a new opportunity shows up.

I’m sure the rest and family time will lead me in the right direction.

In the meantime, I have a zillion things I’ve been meaning to write about, and no marathon debugging sessions to get in the way, so I expect to barf some random ideas onto the internet in the coming days and weeks. I may spend some more time on twitter (heck, I even posted to Facebook last night!).

I can’t wait to see what happens next.

I forgot to mention this before, but on Thursday, Jason Arbon from applause and uTest will be giving a practically free ($99) course on mobile application quality. Jason is a great teacher, and really knows his stuff in this area.

More information at the SASQAG web site (scroll down a bit on the home page)