Silos, Walls, Teams and TV

Between Netflix, Amazon Prime, and a busy schedule, I’ve gone without cable television for the last five or so years…up until a month or so ago when I bit the bullet (for a variety of reasons), and added a television package to our existing internet service. It’s working great so far, but the story about how we got everything working is worth sharing and pondering.

The Picture

On a Wednesday evening, I called Comcast to add a television package. I knew what I wanted, so ordering was easy. The sales person told me I need to schedule an installation, so we set something up for Sunday. There was no record of our house every having cable television before, but three years ago, I had service for a short time so I could watch the 2010 world cup. So – I had a hunch that I could take care of it myself, so I made arrangements to pick up a box and try it myself.

Thursday morning I grabbed a set top box from the retail store – where the sales person confirmed that I didn’t need an installation – just a “switch flipped” on the box at the end of our driveway.

On Friday night after work, I plugged in the cable box and watched to see what would happen. I half-way expected it not to work, and I was half-right. I was getting audio for all of the channels, but no picture. I was pretty sure things on my end were correct, so I gave support a call.

I’m pretty polar on my customer service experiences. When I have a good experience, I’m elated. When I have a poor experience, I’m annoyed at best. I called support, answered some questions, pushed some buttons, and eventually found a real person to talk to. I clearly explained my situation (new box, previous cable in the house, audio is loud and clear, no picture) to the support person. As I expected, they used a script, asking me if my box was plugged in and if the cables were connected (despite that I had already explained that I had audio and was connected via HDMI). After only a minute or two, I was able to get transferred to someone else. They tried rebooting my cable box a few times before putting me on hold to “talk to a colleague”. Soon after, I was disconnected, and when I called back, the support line was closed for the evening.

On Saturday morning, I called back, and went through the same process. This time, someone eventually figured out that “ I had the wrong account codes”. But – they couldn’t change them. They had to transfer me to someone in sales who could apply the correct account codes. The sales guys did their thing. They tried to sell me a bunch of stuff I didn’t want, but eventually “applied my codes” and sent me back to support – because I still had no picture.

I spent over 30 minutes with the next support person. I still had no picture, and she had me double check all of my connections, and insisted on rebooting my cable box a few times (remember folks, reboot-is-always-a-valid-solution), but no dice. Finally, I chimed in and said, “Hey – to remind you, I ended up here because my account codes or something like that weren’t applied properly – does that help?”. After an awkward silence plus about 3 seconds, a picture appeared on my television. Problem solved! She closed by asking (certainly a Comcast standard) if there was anything else she could do for me. As a matter of fact, there was. I asked her to verify the services I was signed up for and the price I was paying. Sure enough, the guy in sales screwed it up, and I was getting services I didn’t want for more than I planned on paying. So…she transferred me back to accounts.

I explained the situation to the person in accounts, but was told that the type of account I signed up for was an account outside of her department. Her department, apparently only handled the “standard” packages, and I needed to talk to someone in “specials” or something like that. She transferred me again, and within a minute or two, my service remained up and running, and I was getting the services I wanted for the price I planned to pay.

To be clear, the television service (on top of my internet service) has been flawless. But the path to get there was nothing but.


I could go back and count everyone I had to talk to, but in reality, the problem with my experience above is that I talked to way too many people. In fact, I’d say that I talked to too many people the moment I talked to the second person. In nearly all of the great support experiences I have experienced (and have read about), I’ve been taken care of my one person (sometime a few) who were empowered to help. At Comcast, employees apparently work in silos. They have a single activity they are trained in, and allowed to perform. I’m sure that makes sense on paper (to someone), but in practice, it’s a poor experience.

Making Software

Believe it or not, this post isn’t about my support complaints. It’s about making software – because I fear that many organizations are making software the same way that my cable company handles support. When you have a team of programmers who only program, testers who only test, analysts that only analyze, and managers who only manage, you have an organization that works slowly, and likely produces crap.

Not everyone, of course, has to be able to do everything, but everyone should feel empowered to do whatever is needed (within their capabilities). You should be able to write a spec, fix a bug, perform a test, or lead the team regardless of what your title says.

Generalizing Specialists

There’s a reasonable number of talks and articles amongst the agile community on Generalizing Specialists

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle.  (reference)

It’s worth noting that the article quoted above refers to Specializing Generalists – and although it appears that many folks use the terms interchangeably, I think there’s an important distinction.

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. (reference)

Again (because for some of you, I’ll have to say it again), I’m not saying that everyone has to do everything. Your “generalist” skills don’t need to span every software activity. But I am saying that you will be more valuable to your team (and your team will work better and make better software) if everyone in your organization can do more than specialize in just one thing. This is true regardless of the methodologies and approaches used on your team. Silos and walls create waste (wasted time, wasted efforts, wasted energy, etc.).

I really don’t understand why some software teams insist on having specific roles for specific team members and offer little to no encouragement to reach beyond their silos. Great results come from great teams – and great teams (whether it’s a sports team, a sales team, or a software team) work together and compliment each others skills.

See also: T-Shaped Personas (and E-Shaped)

The Professional Attribute Game

I chuckle a bit every time I see a tweet or a blog post talking about how some attribute is uniquely important for anyone wanting to be successful in a software role – when in reality, there are many professions where these attributes help lead to success. I’m not saying the attributes aren’t important, but I am saying that it’s wrong to assume that proficiency in one of these attributes immediately qualifies one to be successful in software.

So – in a 5-minute spout of Alan-being-annoying-on-a-Monday, I give you the “professional attribute game”. Pick one line each from column A, B, and C, and you will have your own profound statement about what it takes to be successful in the 21st century.









Back to less snarkiness soon – but feel free to add your own attributes, actions, and professions in the meantime.


While cleaning out some boxes my Mom had packed away, I came across a yearbook from my freshmen year of high school. I hated my freshmen photo. I had skull surgery a few months earlier (long story for another post), and needed to have my head shaved. As I remember it, by the time school started, my hair was nothing but stubble.

I cracked the yearbook open to show my wife the ugliness of my head, and was a bit surprised to see that my hair actually wasn’t much shorter than my hair is now – but a glance around the rest of the page showed that my classmates from 1979 all had hair covering at least half of their head. My hair was short compared to my peers, but in hindsight, not that short at all.

It’s that time of year at Microsoft when people get uneasy (or freaked out, or hysterical, or angry, etc.). It’s review time. What’s worse, is that it’s review time at a company that has a forced curve of performance rankings (note: there is a bit of leeway this year, but it’s still a curve). Now, you’d think that in a company full of tech geeks, people could figure out that no matter how much leeway there is, that you can’t get 75% of the company into the top-20% bucket – or that in a company crammed full of smart people, that half of them are below average.

The Hairball

To be clear, I’m not defending the review system; it is what it is. To me, the review system is the tax I pay to get to do what I do. I have a choice to work where I want to work. If I don’t like the system, I can go pay the tax of another company’s system. Everyone has that same choice. Live in the system, change the system, or leave the system. Marlena Compton once recommended a book imageto me, which I, in turn, have recommended at least a dozen times. Orbiting The Giant Hairball is the story of an artist at Hallmark, and how he learned to deal with corporate life, and his sanity, at the same time. If you love your work, but struggle with the bureaucracy and politics – or even if you just want to figure out how work fits in with life, this is a great book. Also – as Marlena told me, don’t buy the e-book. For full effect, this book needs to be read in dead-tree form.

A “Bad” review

Let me tell you a story about my first review at Microsoft. I was hired full-time in June of 1995 as a level 9 (equivalent to a level 57 – our minimum hiring level today for software folks is 59). Reviews back then were in August, so I didn’t have my first annual review until August, 1996. In those 14 months, I helped ship all of the Asian versions of Windows 95, tested the crap out of IE2 and IE3 (including writing ISAPI server extensions, and what was probably among the first web automation in the industry), got rave reviews from external offices for a web translation tool I wrote, and maintained servers for our entire test team. I awaited my accolades… My reward? A $1000 dollar bonus and an $800 dollar raise.

The world was unfair, and I was a victim.

I remember talking to a friend of mine who was an old-timer at the company (she started fours years ahead of me in 1991). She was sympathetic, but wise. She told me that she knew I would do well in the long run, and not to worry about it. This wise women of 26 told me that careers will have ups and downs, but in the end, everything evens out.


I didn’t believe her, but she was right. My career has had its ups and downs, but overall, it has gone pretty well, and as I’ve grown, I’ve learned how to take control of what kind of work I want to do, and what kind of worker I want to be.

What I needed, was perspective. And I’ve echoed my friend’s advice to dozens of others over the years (and have already done so many times in recent weeks).

The next time you’re upset with how you’re being treated at work, ask yourself if it’s a glitch in the road, or a trend you need to avoid. If it’s a trend, don’t whine. Fix it, or find a new job. If it’s a glitch, sulk for a moment, if needed, and then move on. Your career isn’t defined in a moment – or even a year. Have some perspective.

Blog + Leanpub + Scrivener = “A”

Depending on how you look at it, I wrote a book.

Except that I already wrote it (it’s taken almost entirely from previous blog posts. And to be fair, it’s not really long enough to be a book (the good news is that you can easily read it in an hour or two, and that it’s available in three different electronic formats).

When I wrote the Last Word on the A Word post some time back, I felt an urge to revisit all of my various posts on GUI automation…and after pondering those for a while, I thought I’d consider compiling those posts into a one-stop-shop of what I think about test automation and test design.

And I ended up with The “A” Word. And I’m happy with how it came out.

When I began compiling the book, I was planning to give it away for free. But – after working with the leanpub tools for the last few weeks (and being impressed time after time), I felt bad not giving them any money for their tools. As a result, I decided to make the minimum price free, but allow people to pay if they wanted (as I’m already overpaid for a job I love, I’m donating all of the profits to the American Cancer Society).

I also found that Scrivener was a perfect ally in this little project. I bought a copy a while back, but haven’t done much “serious” writing recently. After struggling a bit to figure out what should go where, I decided to give Scrivener a full test run, and it worked perfectly. My colleagues in Office won’t like me saying this, but my next book will also be written entirely in Scrivener.

So, if you haven’t checked out The “A” Word already, what’s stopping you? Check it out and let me know what you think.

My Toolbox – 2013

On my bike ride to work today, I was thinking about my current toolbox – the tools I use on a daily basis to get my job done (or to help me get my job done). Or, to be perfectly honest, I’ve been thinking about my toolbox for a while – I just thought about writing about it on my commute today.

This isn’t going to be a typical list – that’s for two reasons. One is that I’m not typical. The second is that I use some internal tools that may be helpful…but since nobody outside of the Borg can get to them, aren’t that interesting to share. But – what’s listed below covers most of what I use on a day to day basis.

Stuff I use for Testing

This list could go on for a while, but I’ll stick to tools that I use every day, are free to anyone, and find great bugs.

  • Application Verifier – AppVerif is a dynamic analysis tool (a lot like the old boundschecker tool). It’s easy to set up, the bugs are easy to debug, and its false positive rate is near zero. If you test a windows app, you should use it.
  • Driver Verifier – DV is (IMO) the biggest blue-screen remover I know of, or can imagine. It finds driver faults way, way before they ever manifest in a system crash. If you test drivers, you have to use this tool (literally, as I think the driver certs require that you run it).
  • Static Analysis Tools – we use an internal version of the Code Analysis tools from Visual Studio. I’ve never actually used the VS versions of the tools, but from what I can tell, what I use daily to help guide me to product issues is almost exactly the same as what we ship to developers.
  • Kernel Debuggers – When you work on an operating system, you need a kernel debugger, and the debuggers from MS are great (I could just be used to them, having used them for years). Windbg (I pronounce it wind-bag) looks a bit like a throwback (IOW, it’s not a pretty debugger), but it’s a powerful debugger.

Command Line Goo

I spend a lot of time at the command line (our build system uses a lot of command line tools, and I’m comfortable there). Many years ago, I used NDos/4Dos, but I still prefer the standard cmd.exe shell to the currently available Windows shell alternatives.

But the command line is much more than a terminal – it’s the way you use it that makes it useful.

  • Macros – I don’t know about you, but I always forget complex command lines – especially for commands I don’t use often, , so I use a lot of doskey macros. I have a network accessible power supply hooked up to my consoles, so I have a macro that reminds me of the commands to reboot, and connects to the ip address (that I always forget) -doskey netpower=echo Run rb num to reboot console num$Tsleep 2$Ttelnet %powerip%
    I have 40 or so of these, and scanning through the list, I use nearly every single one on a daily basis.
  • Grep / Findstr – I’m always looking for stuff, and findstr is my partner. Need to find every instance of a file containing the text ‘f’’ that does not have the text ‘bar’ on the same line: findstr /sip foo * |findstr /vi bar.

Other Tools

Tools I use every day include:

  • Notepad++ – This is my primary editor. Since I build from the command line, I don’t need anything except an editor that launches quickly and makes it easy for me to read and write code quickly. Notepad++ also has macro support which is great for those times when you need to make the same change across hundreds of lines.
  • Notepad2 – This is my backup editor. Sometimes, I want a file to load in a single window (notepad++ loads multiple documents). For example, I have a bunch of output files I need to look at every few weeks, and I never got around to writing something to get the output I need from the file. So, when I’m ready to look at the files, I run for %f in (*.txt) do start /w notepad2.exe –g –1 %f
    That launches notepad2 for each text file (waiting until I close it before launching the next one), and automatically puts the cursor on the last line of the file.
  • Visual Studio – I do a little bit of coding in VS, but I mainly use it for work item tracking in TFS
  • Leankit – I keep my life in order (including my work life) using personal kanban, and leankit is my tool of choice. It keeps me sane.
  • Others – I use Excel, a few different mind-mapping tools, scripting languages, and terminal server frequently as well, but the use cases are probably less interesting.  Other Office apps (Outlook, OneNote, Word, etc.) also get extensive usage, although less directly related to software development or testing.

[Preemptive comment: yes – I know that the brain is your most important tool as a tester (or programmer) – but this is true for all knowledge work. You need to use your brain to know when to use tools like these, and recognize when they will help you. Consider brain power noted.]

What’s Your Super Power?

When I’m interviewing experienced candidates (for any software role), one question I frequently ask is, “What’s your super power?” I like hearing answers like, “I can learn new things really quickly”, or “I’ve found over 1000 security bugs”, or even “I’m a batch file (or other language) wizard”. Recognizing super (or special) powers in yourself shows me that you have some idea how to ride your strengths – and gives me an idea of how you may fit in with the rest of the team.

Power in Diversity

When asking about super powers, I don’t like hearing answers like, “I’m good at everything”, or “I’m good at filling in”. Imagine the X-Men, but instead of five of them, imagine one super hero who was super strong, could teleport, heal from injuries quickly (and has claws!)…who also shot lasers out of their eyes and control the weather. There’s no way Mr. Eye-laser-healer-armor-plated-strongman-mind control-weather controlling dude could kick Magneto’s butt by himself. You need a team to do great things, and great teams have diversity. If the X-Men were just a bunch of people who all shot lasers out of their eyes, their fighting options would be pretty  limited. For example, if your test team is a bunch of “automators”, you’re in a similarly bad place.

The One Trick Hero

Of course, you can’t only ride your strengths. Imagine if Storm was a couch potato who happened to have the ability to change the weather. Not only can she change the weather, but she’s buff and knows how to fight. More importantly, she knows how to work on a team and contribute her skills to the greater good of the team. As a tester – or a test leader, your super powers are important – not just to you, but to the success of your team.

So – what is your super power?

This & That

Clearing out some random news and thoughts. None of them worth a post, but worth sharing…probably.

  • A few days ago, I reposted the Microsoft SDET personas I originally wrote (5? years ago) for the MSDN tester center. They could use a bit of updating, but they hold the test of time fairly well (link here).
  • I have a flurry posts planned for the next few weeks while I vet and flesh out some potential ideas for my (way too many) STAR West presentations. If you’re planning on attending my workshop, feel free to post topics here, and I’ll work them in.
  • Pair programming harmful? In an article almost worthy of the Onion..oh, I can’t describe it. You’ll have to read it here and form your own opinion. I hate to give the author more hits on his blog, but for someone who is considered a “specialist” in software engineering (and widely published to boot), this article and “research” are off of the deep end.
  • Have you seen the Angry Weasel. One of the hidden gems of attending the Telerik test summit recently imagewas getting a connection to someone to make me a mascot – or a logo, depending how you look at it.  If you’ve actually stepped out of an RSS reader (yes, there are others besides Google Reader), you’ve already seen it, but posted below anyway for the rest of you (blue version for some variety). 

*Many of you don’t know where the AW in comes from. The story (although missing many details), is on the poorly edited and more poorly updated homepage for this site.

Last Word on the A Word

It’s been a busy month. (I blame Xbox One for monopolizing my time), and I’m way overdue for what I meant to be a “day-after” follow up for my last post. If you didn’t read it (or if it’s been so long you’ve forgotten), here’s the summary and where we left off:

  • “Automation” is an overloaded and abused word that often implies that test code only exists to automate human tasks – that’s stupid
  • If you are a tester who codes, you write code. Period. Some of your code may automate tasks. Most will not (or shouldn’t)

Some have asked if I’m against all automation. My tautological answer is that I’m against bad automation. My better answer is, no – I’m not against automating tasks for some testing. Automation is overused and overvalued in software – while the coding of diagnostic and analysis tools is extremely undervalued. In many cases (quick check of basics, some unit tests, monkey testing, etc.), automating a set of user tasks is beneficial and provides a lot of bang for the buck, but focusing entirely on automation of user tasks is a waste of any programmers time.

I wrote a chapter in a test automation book a few years ago, but on principle, I didn’t write about automation. I wrote about a simulation framework that made it easier to write some targeted automation. To me, writing something like this is a great use of a tester’s time – often much better than to write a suite of automated scripts.

The point is, if your testing strategy is entirely to automate a suite of user tasks, you are doing way more to keep “automators” busy than you are actually providing valuable testing. We can debate the goal of the testing activity, but one thing it is not, is the activity of running through a bunch of user tasks over and over. In fact, one of the touted benefits of automation is repeatability – but no user executes the same tasks over and over the exact same way, so writing a bunch of automated tasks to do the the same is often silly.

I’m done writing about automation for now. I may continue to write about code or debugging or testing. My advice for testers is to worry less about “automation”. Ignore it if you can – but at the very least realize how overloaded…and overblown the word is is the software community and take a holistic approach to software testing.

Coding, Testing, and the “A” Word

I frequently go days at work without writing code. On many days, I do “typical” test activities (seeing what works, what doesn’t work, etc.) Some days I’m debugging all day. Other days, I’m sifting through the perl and batch scripts that bolt our build process together. On other days, I’m managing projects, tweaking excel, or trying not to cause too many problems in SQL. This afternoon, at least after lunch, was coding time – and probably the first extended code time I’ve had in a few weeks.

Without too many boring details, I had a backlog item to write a service to automatically launch a memory analysis tool and periodically take snapshots of memory allocations in specified processes. The memory analysis tools (which I also wrote adapted from another project) work really well, but need a lot of manual intervention in order to get accurate data. I wrote a quick “spec” on my whiteboard, wrote tests as I went along, and in about four hours I had it up and running successfully. I’m confident that the service will make it much easier for our team to find and isolate memory issues. To me, writing this tool was a testing activity. It doesn’t test anything, but certainly makes testing of the product much easier.

On my drive home, I was pondering the universe (and my day) and remembered that there’s a sad bit of truth in the software world. It’s a fallacy that causes great confusion. It promotes poor strategies, bad hiring decisions, and endless confusion among management, contributors, and consultants. It may very well be the most misunderstood word in the world of software. It’s the “A” word that is practically ruining testing.


Yes – as much as I hate them, I used a one word paragraph. I did it because the abuse and misuse of “automation” in testing is causing too many smart people to do too many dumb things. That said, I suppose an explanation is in order.

Once upon a time, someone noticed that testers who knew how to code (or coders who knew how to test) were doing some wicked-cool testing. They had tools and stress tests and monitoring and analysis and they found great bugs that nobody else could find – “Test Developers” were all the rage…so we (the industry) hired more of them. Not much later (and possibly simultaneously), someone else decided that testers who could code could automate all of the tasks that the silly testers who didn’t code used to do. Instead of finding really cool bugs, coding testers were now automating a bunch of steps previously done manually. Not to be left out, UI automation frameworks began to sprout, with a promise that “anyone can automate – even a tester.” Now, test teams can spend the bulk of their time maintaining and debugging tests that never should have been automated in the first place.

And that was the first step into darkness.

This mindset, although common, kills me:

  • Testers who code write automation
  • Automation is primarily made up of a suite of user tasks
  • Automation is primarily done through the GUI

All of these items are, in my opinion, idiotic – and likely harmful to software quality. It focuses test teams in the wrong place and is, frankly, insulting to testers who know coding.

If you’re a tester who writes code (or a coder who cares about testing), try this:

  • Write tools that help you find important bugs quickly
  • Write a few high level tests that ensure user actions “work”, but leave most of it for exploratory testing, user testing (assuming you have great monitoring tools), or both.
  • If you must write GUI tests for the above, write fewer of them (that way you’ll spend less time investigating their flaky behavior).

If you’re a tester who writes code, you’re not a test automator, you’re not a test automation engineer, and you don’t write test automation or test code.

You write code. And you test.

You write code that helps the product get out the door sooner. And if the code you write (or the testing you do) doesn’t help the product, why are you doing it in the first place?

Rockin’ STAR West

The cat’s out of the bag – I’m popping out of my no-conference bubble, and making an appearance at a testing conference (STAR West in October). The theme of the conference is “Be a Testing Rock star”,Me, pretending to be a rock star. I'm sure I'm in the middle of some very clever stage banter here. and while I think that theme begs for an appearance from Michael Larsen, I’ll do my best to live up to the hype.

I’ll be giving a keynote on testing the Xbox. While I’m certain I’ll have interesting stories and pragmatic examples I can share in a generic fashion, I’m hoping I can share much, much more. I don’t have clearance yet to share too much about the Xbox One, but assuming I can get my proposals in place, it should be a pretty exciting talk to share. By the time STAR rolls around, I’ll have passed my 20 year anniversary working on software, and working on this product has definitely been the highlight of my testing career.

I’m also signed up to give a half-day workshop on testing. Literally – “on testing”. The title of the workshop is Alan Page: On Testing, and I’ll take the time to share some good stories and examples of new testing ideas, but I expect the attendees to drive the content. More details on that as we get closer to the event, but I expect it will be a ton of fun, and especially interesting to those folks who just want to suck up some new and interesting ideas.

More as the conference gets closer.