Steve Rowe's Blog

Steve Jobs on the Value of Saying No

2011-10-07T02:29:00Z

I ran across a great segment of Steve Jobs talking at the WWDC in 1997 just after he returned to Apple. Similar to my post about pruning the decision tree, he speaks about the power of saying no to the bad ideas. "Focusing is about saying no," he says. His analysis of what was wrong with Apple at that time was that they had terrible engineering management. They were doing too many things--interesting things--but had no direction. When he took over, the decisions that had to be made were not to cut things that were bad, but to cut things that were unfocused. A lack of focus makes the whole less than the sum of the parts. Good focus allows the whole to become greater than the sum of the parts.

Two segments are worth watching. The first is Steve Jobs explaining his philosophy:

The second is him responding to a question about why they cut OpenDoc. The interesting observation is that OpenDoc was probably better than anything else at some things. That, by itself, wasn't enough. It had to be part of a larger vision or it had to go.

He ends with a great observation about how you have to let the vision dictate the technology and not the other way around.

How much did Steve Jobs Mean To the Tech Industry?

2011-10-06T03:55:15Z

This picture says it all. The front page of Hacker News is completely dominated by the news of Steve's death. Even as someone who never owned an Apple product, he had a huge influence and raised the bar. Not just once, but at least 5 major products from him changed the state of the industry. The Apple // was a watershed for personal computers. The Mac for UI. The iPod and especially iTunes for digital music. The iPhone completely changed the phone business. The iPad created a whole new category of devices. His influence will be greatly missed.

Pruning the Decision Tree in Test

2011-09-28T14:26:00Z

Yesterday I wrote about the need to reduce the number of things a project attempted to do in order to deliver a great product. Too many seemingly good ideas can make a product late or fragmented or both. The same is true of testing a product. Great testing is more about deciding what not to test than deciding what to test.

There is never enough time to test everything about a product. This isn’t just the fault of marketing which has a go-to-market date in mind. It is a physical reality. To thoroughly test a product requires traversing the entire state tree in each possible combination. This is analogous to the traveling salesman problem and is thus NP-Complete. In layman’s terms, this means that there is not enough time to test everything for any non-trivial program.

When someone first starts testing, thinking up test cases is hard. We often ask potential hires to test something like a telephone or a pop machine. We are looking for creativity. Can they think up a lot of interesting test cases? After some time in the field, however, most people are able to think up a lot more tests than they have time to carry out. The question then becomes no longer one of inclusion, but one of exclusion.

In Netflix’s case the exclusion was for focus. This is not the right exclusion criteria for testing. It is improper to not test the UI so that you can test the backing database. Instead, the criteria by which tests should be excluded is more complex. There is no single criteria or set of criteria that work for every project. Here are some to consider which have wide applicability:

Breadth of coverage – Often times it is best to try everything a little rather than some things very deep and others not at all. Don’t get caught up testing just one part.
Scenario coverage – Look for test cases which will intersect the primary use patterns of the users. If no one is likely to try to put a square inside a circle inside a square, finding a but in it is not highly valuable.
Risk analysis – What areas of the product would be most problematic if they went wrong? Losing user data is almost always really bad. Drawing a line one pixel off often is not. If you have to choose, prefer focusing more on the data than the drawing. Another important area for many projects are legal or regulatory requirements. If you have these, make sure to test for them. It doesn’t matter how well your product works if the customer is not allowed to buy it.
Cost of servicing – If forced to choose, spend more time on the portions that will be more difficult or costly to service if a bug shows up in the field. For instance, in a client-server architecture, it is usually easier to service the server because it is in one spot, under your control, rather than trying to go to hundreds or thousands of computers to update the client software.
Testing cost – While not a good criteria to use by itself, if a test is too expensive to carry out or to automate, perhaps it should be skipped in favor of writing many more tests that are much cheaper.
Incremental gains – How much does this test case add to existing coverage? It is better to try something wholly new than another slight variation on an existing case. Thinking in terms of code coverage may help here. It is usually better to write a case which tests 10 new blocks than one which tests 15 already covered blocked and 2 new ones. It is very possible that two test cases are both great, but the combination is not. Choose one.

There are many more criteria that could be used. The important point is to have criteria and to make intentional decisions. A test planning approach that merely says, “What are the ways we can test this product?” is insufficient. It will generate too many test cases, some of which will never be carried out due to time or cost. It is important to prune the decision tree up front so that the most important cases are done and the least important ones are left behind. Do this up front, in the test spec, not on the fly as resources dwindle.

Pruning the Decision Tree

2011-09-27T15:54:00Z

A great post by Marc Randolph got me thinking. He tackles the question of why Netflix made the moves they made recently. Specifically, why did they spin off their DVD option as a company called Qwixter? The answer: focus.

What separates successful ventures from failures is choosing to do the right things. What separates great successes from merely good ones is choosing not to do the wrong things.

When faced with a question about whether to add a feature, the decision often revolves around whether customers will like it. This is a good first question, but stopping there leads to sub-optimal results. It is important to ask the next question: What can we not do by doing this? Resources are limited. For each feature that goes into a product, something else(quality, time, other features) comes out. If that is forgotten, the product will end up with too many features that are good but not great and a product that feels the same.

Shipping a great product then is about the decisions about what features not to implement and what bugs not to fix. Netflix demonstrates what it looks like to take this very seriously. They are jettisoning what is a popular part of their company so they can focus on what they think is the future. Only time will tell if they chose the right strategy, but one has to commend them for making a clear choice.

Follow my adventures at //build/

2011-09-15T16:52:00Z

This week I'm attending the //build/ conference where Microsoft is revealing many of the details about Windows 8. If you want to see what is going on, follow my Twitter feed at http://twitter.com/steverowe, I'm posting some pictures, linking to summaries, etc.

Listening to the team

2011-09-12T08:00:00Z

There is an old saying in software that goes something like this, “Scope, Timeframe, and Budget: Pick two.” Being a tester, I would rephrase this a little as, “Features, Timeframe, Budget, and Quality; Pick three”. It’s usually possible to hit all three of the first choice as long as you are willing to sacrifice quality. We’ve all seen products that do this. They have such potential, but just don’t work. Over the past year, there were lot of planning efforts going on around me and this was a great chance to observe different behaviors. One pattern I have seen a few times is worth discussing. That is managers trying to dictate all 4 aspects of a project. There are two ways this tends to happen: the dictatorial manager and the persuasive manager.

Before we jump in, it is important to define the four levers. Features represent the complexity of the product—how many things it can accomplish. Timeframe is how soon the product needs to ship. Budget is how much can be spent on the project. For software projects, this corresponds largely with the number and skill of people that can be put on the task. No discussion of budget can be complete without at least mentioning Brooks’ law. Quality is the ineffable attribute representing beauty, greatness, or merely suitability for a given task. In practical terms it means how many bugs are exposed by the product. Increasing the expectations for any of these increases the pressure on the project. Within reason, each can be relaxed to achieve the desired levels of the other three. It is important that managers understand that when they ask to increase features, they are trading off time or that when they ask to reduce time, they are trading off features.

The dictatorial manager is the more obvious of the two. This is the person that just says, “You will have the following specs done by this date.” Implied is that this will be done with a fixed number of people (never enough) and of high quality. This is the pointy haired boss from Dilbert. When the team raises objections, this manager is unphased. They stick to their position. If the team can’t get it done in the timeframe they ask for, they will find someone else who will. It never occurs to the manager that perhaps what they are asking for is impossible. The only good news is that this type of manager is often self-correcting. They are not enjoyable to work for. The best members of the team have mobility and will leave. This slowly guts the team of the most capable people and the project slowly fails. At a quality company this manager will be seen for who he is and removed from such responsibility.

The persuasive manager is less obvious but nearly as bad. This is the manager who convinces their team that it can do the impossible. In this case they don’t dictate an impossible situation, they merely get the team to agree to it. This manager is usually a really nice guy who just can’t say no. Instead they ask people nicely to sign up for everything marketing and upper management ask for. Their team likes working for them, it just can’t figure out why it is so over-worked. The quality of the project suffers as the team goes into an over-worked haze. This sort of manager is not as quickly self-correcting. The team does not leave except through burn-out. They don’t blame the manager because signing up for the work was their idea. Neither the dictatorial manager nor the persuasive manager will succeed. Both will usually ship something close to on time because they cannot admit failure. The quality, however, will be low. People stop caring once they are made to attempt the impossible. The team will be much weaker the next go-round because all of the good members leave through disgust or attrition.

A better model is to listen to the team. Most times a manager does not have control of all of the levers. Typically timeframe and budget comes down from on high. A manager cannot magically hire more people. Except through brinksmanship, they cannot cause the project to ship later. They do, however, have control over the expect level of quality and the number of features. A team will usually give signals if they think they are being asked to do too much. The wise manager listens to this and adjusts plans accordingly. This is the genius of systems like Scrum and Agile development. A tenet of these systems is listening to the team. Using a system of cost estimates and burndown tracking helps bring an objective view of the picture. Likewise, if the team hesitates or balks at signing up for work, a good manager will re-evaluate. This doesn’t mean automatically reducing the ask, but it does mean making sure you are convinced it can be done.

If a manager senses that the workload is too much, it is their responsibility to reduce it. As much of a manager’s job should be spent deciding what not to do as deciding what to do. This may generate heat from upper management who wants everything in a limited time, with a fixed budget, and at the highest quality. Helping upper management understand the situation and even taking the pain if understanding is not conveyed is the responsibility of the manager. If failure is inevitable, it is better to fail in a place of your choosing (that with the least impact/priority) rather than risk failure on a broader scale at a later date.

The Sidebar is Back!

2010-05-12T03:55:00Z

I'm apparently in the minority, but I really liked the sidebar in Windows Vista. On a widescreen monitor, there is horizontal space to waste and it was really convenient to have all of my gadgets showing over on the right-hand side. In Windows 7, the sidebar was removed. Gadgets are still there, but to me they became less useful because they were either hidden below all my windows or obscuring them. There was no way to have them always show and have windows flow around them. I've just discovered a new gadget called 7 Sidebar that acts just like the Vista sidebar, but for Windows 7. You can find it here if you too liked the look of the sidebar.

Netcast List April 2010

2010-04-29T16:10:22Z

It’s been a long time since I updated my netcast list, but my habits have changed a bit. Here is what I currently listen to regularly:

This Week in Tech – Weekly Tech News Roundup
GeekBrief – Daily snippet of gadget news
Games with Garfield – Monthly gaming podcast featuring the creator of Magic: The Gathering
StackOverflow Podcast – The podcast is changing so I have to decide whether the new format stays in heavy rotation. It has been a good podcast for programming types.
Windows Weekly – Everything Microsoft

I listen to these when I can:

Manager Tools – I’ve learned a lot about being a better manager from these guys.
Tekzilla – Video tech news
Cranky Geeks – More tech news
FLOSS Weekly – Interviews with open source projects. Very interesting if you are a programmer.
Econtalk – Interviews with economists. Usually pretty accessible.
Berkeley Webcasts – All kinds of classes from Berkeley in podcast format. I suggest CS61a which teaches through SICP.
Sound Investing – Investment discussion focused on buy and hold index fund investing.

If you have suggestions, leave them in the comments.

Resume Advice: List Your Classes and Projects

2010-03-19T15:28:00Z

It is campus hiring season and I have been reading a lot of college resumes lately. One thing I have noticed on many resumes is that they do not list what I consider to be some of the most relevant information. As important as it is that someone made the Dean’s list or worked at Best Buy, it is even more important to know their experience that is directly relevant to the job. Some have internships and these are directly relevant. Others have not been so lucky. That’s fine, but if you find yourself in this bucket, please, please list your classes and describe the major projects you have worked on. Knowing what projects were worked on gives me, the interviewer, a much better sense of what you are capable of. It also gives me more material to latch onto and ask questions about. As a candidate, you want me asking questions about your projects because you should understand them well and be able to talk about them fluently. Additionally, without classes and projects, a resume with jobs working at Home Depot or the local KFC looks just like every other resume. It is your internships, projects, and possibly classes that set you apart.

Pass Rates Don’t Matter

2010-03-17T12:50:00Z

It seems obvious that test pass rates are important. The higher the pass rate, the better quality the product. The lower the pass rate, the more known issues there are and the worse the quality of the product. It then follows that teams should drive their pass rates to be high. I’ve shipped many products where the exit criteria included some specified pass rate—usually 95% passing or higher. For most of my career I agreed with that logic. I was wrong. I have come to understand that pass rates are irrelevant. Pass rates don’t tell you the true state of the product. It is important which bugs remain in the product, but pass rates don’t actually show this.

The typical argument for pass rates is that it represents the quality of the product. This makes the assumption that the tests represent the ideal product. If they all passed, the product would be error-free (or free enough). Each case is then an important aspect of this ideal state and any deviation from 100% pass is a failure to achieve the ideal. This isn’t true though. How many times have you shipped a product with 100% passing tests? Why? You probably rationalized that certain failures were not important. You were probably right. Not every case represents this ideal state. Consider a test that calls a COM API and checks the return result. Assuming you pass in a bar argument and the return result is E_FAIL. Is that a pass? Perhaps. A lot of testers would fail this because it wasn’t E_INVALIDARG. Fair point. It should be. Would you stop the product from shipping because of this though? Perhaps not. The reality is that not all cases are important. Not all cases represent whether the product is ready to ship or not.

Another argument is that 100% passing is a bright line that is easy to see. Anything less is hard to see. Did we have 871 or 872 passing tests yesterday? If it was 871 and today is 871, are they the same 129 failures? Determining this can be hard and it’s a good way to miss a bug. It is easy to remember that everything passed yesterday and no bugs are hiding in the 0 failures. I’ve made this argument. It is true as far as it goes, but it only matters if we use humans to interpret the results. Today we can use programs to analyze the failures automatically and to compare the results from today to those from yesterday.

As soon as the line is not 100% passing, rates do not matter. There is no inherent difference in the quality of a product with 99% passing tests and the quality of a product with 80% passing tests. “Really?“ you say. “Isn’t there a difference of 18%? That’s a lot of test cases.” Yes, that is true. But how valuable are those cases? Imagine a test suite with 100 test cases, only one of which touches on some core functionality. If that case fails, you have a 99% passing rate. You also don’t have a product that should ship. On the other hand, imagine a test suite for the same software with 1000 cases. Imagine that the testers were much more zealous and coded 200 cases that intersected that one bug. Perhaps it was in some activation code. These two pass rates then represent the exact same situation. The pass rate does not correlate with quality. Likewise one could imagine a test case of 1000 cases where 200 were bugs in the tests. That is an 80% pass rate and a shippable product.

The critical takeaway is that bugs matter, not tests. Failing tests represent bugs, but not equally. There is no way to determine, from a pass rate, how important the failures are. Are they the “wrong return result” sort or the “your api won’t activate” sort? You would hold the product for the 2nd, but not the first. Tests pass/fail rates do not provide the critical context about what is failing and without the context, it cannot be known whether the product should ship or not. Test cases are a means to an end. They are not the end in themselves. Test cases are merely a way to reveal the defects in a product. After they do so, their utility is gone. The defects (bugs) become the critical information. Rather than worrying about pass rates, it is better to worry about how many critical bugs are left. When all of the critical bugs are fixed, it is time to ship the product whether the pass rate is high or low.

All that being said, there is some utility in driving up pass rates. Failing cases can mask real failures. Much like code coverage, the absolute pass rate does not matter, but the act of driving the pass rate up can yield benefits.

The Complexity Hammer

2010-03-16T12:30:00Z

I’ve been doing a lot of interviewing lately, especially of college students. There is one tendency I see a that really separates those that are good from those who still have more learning to do. This is the tendency of the good programmers to see elegant solutions to problems and the corollary that less skilled programmers solve every problem by adding more complexity. Stated another way, the thing that separates the best programmers from the rest is what happens when they run into a serious issue. In my observation, the best coders step back and look for a more elegant solution. The less skilled coders assume that their approach is correct and that another piece of state or another special case is the best choice.

Here is an example. The problem has been changed to protect the innocent. Often times I ask a question similar to the change-making problem. That is, write a program to enumerate all of the ways to make change for a dollar. A typical approach might look something like this. Note, I didn’t actually compile this code so there could be typos. If there are, I’m sure you’ll let me know.

void MakeChange()

{

int moneyLeft = 100;

for (int quarters = 0; quarters <= 4; quarters++)

{

    if (quarters) moneyLeft –= 25;

    for (int dimes = 0; dimes <= 10; dimes++)

    {

      if (dimes) moneyLeft –=10;

      for (int nickles = 0; nickles <=20; nickles++)

      {

        (if nickles) moneyLeft –=5;

        for (int pennies = 0; pennies <= 100; pennies++)

        {

          if (pennies) moneyLeft—;

          if (0 == moneyLeft) print…;

        }

      }

    }

}

}

I know what you are thinking, “That’s not the right way to solve this.” And you would be correct. However, I have seen a lot of people give basically this solution. Their failure to solve it correctly the first time isn’t the point of this post. Rather, it is their response to the problem. If you haven’t spotted it yet, this will only work correctly for the first time down for loops. After we get to zero, we never gain the money back from the pennies we spent during the last nickles iteration. When I point this out, the solution is too often not to step back and re-examine the problem. “Is there something wrong with this solution?” Rather the typical reaction is to assume that the solution is mostly right and to tweak it. One might think of this as a specific case of not asking the 5-Why’s. The initial reaction is often just to reset moneyLeft at the top of the quarters loop. When that doesn’t work, more variables are added. The result solution looks something like this:

void MakeChange()

{

int moneyLeft = 100;

int moneyLeftQuarters = 100;

int moneyLeftDimes = 100;

int moneyLeftNickles = 100;

for (int quarters = 0; quarters <= 4; quarters++)

{

    moneyLeft = moneyLeftQuarters;

    if (quarters) moneyLeft –= 25;

    moneyLeftQuarters = moneyLeft;

    for (int dimes = 0; dimes <= 10; dimes++)

    {

      moneyLeft = moneyLeftDimes

      if(dimes) moneyLeft –=10;

      moneyLeftDimes = moneyLeft;

      for (int nickles = 0; nickles <=20; nickles++)

      {

        moneyLeft = moneyLeftNickles;

        if (nickles) moneyLeft –=5;

        moneyLeftNickles = moneyLeft;

        for (int pennies = 0; pennies <= 100; pennies++)

        {

          moneyLeft—;

          if (0 == moneyLeft) print…;

        }

      }

    }

}

}

Not exactly an elegant solution and not one that is easy to get right. There are a lot of subtle cases to think through. Unfortunately, code like this, or code trying to be like this shows up on my white board too often. In a simple problem such as this, it is possible to keep all of the cases in your head and get it right. When the problem becomes larger, however, this is no longer the case. The programmer with the above solution will fail. Thus the solution above is not an acceptable answer even though is technically solves the problem.

If one takes a few moments to step back and re-examine the problem, it is easy enough to see that one doesn’t need to track the amount of money left. It can be trivially calculated when necessary. This is just a specific case of the principle that one should never keep state that can be calculated. Tracking such state provides no benefit and offers the possibility that it will differ from the real state. The solution might look like this:

void BetterMakeChange()

{

for (int quarters = 0; quarters <= 4; quarters++)

{

    for (int dimes = 0; dimes <= 10; dimes++)

    {

      for (int nickles = 0; nickles <=20; nickles++)

      {

        for (int pennies = 0; pennies <= 100; pennies++)

        {

          if (100 == (quarters*25 + dimes*10 + nickles*5 + pennies)) print…;

        }

      }

    }

}

}

Much more elegant. Fewer state variables and thus less to get wrong. All of this stems from the idea that one need not track state. There is no reason to keep a running total of the money. It’s all readily available at any moment. It is this key notion that one needs in order to come up with a much improved algorithm. As long as the programmer doesn’t step back and question the need for tracking how much money has been used/how much is left, they will be stuck adding complexity on top of complexity. This is a prescription for failure. This is not an isolated case. Now that I have noticed this tendency, I can often spot it in interviews or even in code reviews. The moral of the story: always look for the elegant solution first. Can the problem be solved by eliminating something or by looking at the problem differently? Only once you have eliminated these possibilities should you add more state. Adding state isn’t always the wrong solution, but it can be a crutch to avoid deeper thinking.

A few notes:

The initial paragraph isn’t quiet accurate. The best programmers often see the elegant solution up front and get themselves into such trouble much less often.

The final solution is not optimal. I know this. Optimizing it would not benefit the example.

Plan Intentionally

2010-02-08T15:36:00Z

I previously wrote about being intentional, but focused mostly on intentionality in execution. Being intentional is also important in planning. When planning a new product or the implementation of a feature, it is important to explicitly consider all aspects. It can be a temptation to move past the hard problems too quickly. “We’ll get back to that later.” Doing this can be disastrous. It is important to note that the decision on how to solve a hard problem *will* be made. It can be made up front in a thoughtful way, or it can be made on the fly at a later date, but it will be made. Putting off the hard decisions merely makes it more likely that they will be made on the fly.

This advice may seem obvious, but people don’t always follow it. For critical-path decisions, people know better than to leave them for later. It is the difficult peripheral issues that are sometimes left undecided. The boundaries between two modules might be such a place. The decisions on how to implement the module will certainly be decided, but might the way it is extended by or interacts with others be left for later?

I recall working on a feature for WindowsMe (this feature never shipped) which allowed video playback to be conditioned on some criteria. Perhaps the parental levels were too high or the rights were not present to play a piece of video. In that case, this feature would recognize this fact and stop playback. The developer responsible for this feature had created a complex infrastructure with plug-in providers and a great signaling mechanism. I was brought in to test the project late and took over from someone else. After looking at the documentation and playing around with it for a bit, I thought I understood what was going on, but there was one part that confused me. I went to the developer and asked him what happened when he sent the message that playback should stop. Who listened to this event? His response was that he didn’t know. This hadn’t been specified. Stop the presses! Here we had a conditional playback system that was just shouting at the wind, hoping someone would hear it and do the right thing. The developer of this system as well as the developer of the playback pipeline had both written fine pieces of software, but one detail hadn’t been intentionally planned and the end to end feature would not work. Admittedly this is an extreme case, but similar things happen on a less obvious scale if people are not careful to plan intentionally.

It isn’t always that the decisions are considered unimportant. It is that time runs out. When a hard decision is bypassed because it takes too long to decide, the chances of circling back to it before time pressure says coding has to start is high. It is better to take the time to make the hard decision up front and leave the easier decisions to be made on the fly. Acknowledge that there may not be enough time to do all the planning desired. There never is. Then decide on the most critical items first. Be intentional about what is and is not going to get planned. This way the unplanned items end up being those that are most conducive to being planned on the fly.

In short: Tackle the hard issues early. If you wait, they will be decided in a default/easy way. If the issue was hard to decide up front, it will never be decided well in the midst of coding.

Resolved: To Blog More in 2010

2010-01-01T01:38:00Z

As the year closes I look back and see that my blogging really dropped off this past year. I intend to try to blog more over this upcoming year. My position at work has changed from a lead to a manager and that gives me a whole new perspective on things and a lot of new ideas to blog about.

I hope your 2009 went well and that 2010 goes even better. For those who are hurting in this bad economy, hang in there. The sun always rises even if the night is long. Don't give up improving your skills. It will pay off in the long term.

A Taste of Stack Overflow DevDays

2009-11-23T19:38:15Z

If you missed Stack Overflow DevDays, there is some audio from it available on Stack Overflow Podcast #71. I wish there was a longer version of this. It’s only about 1/2 hour of outtakes from the conference, but it is still interesting to hear. These snippets are followed by a long discussion with some of the speakers. The conversation rambles and the audio quality is poor so feel free to stop listening after the conference outtakes.

Design Patterns Are Not Outdated

2009-11-19T16:43:00Z

A comment left on my answer to a question over on Stack Overflow has me a little worked up. I've seen this meme come out of programmers more and more and it just doesn't seem accurate. The statement goes something like this, "Design Patterns were only useful because C++ (or Java) was so broken." The implication is thus that design patterns belong in the dustbin of history now that we have moved on to more enlightened languages like Python or Ruby. In this particular instance the commentor was talking about the strategy pattern. His (?) assertion was that the need for the strategy pattern is not present in a language with first class functions. My response is three-fold. First off, this argument is historically ignorant. The design patterns came as much from Smalltalk as from C++. Second, it is not strictly true. First class functions alone don't obviate the need for the strategy pattern. Finally, providing an alternative implementation does not make the first implementation bad.

The argument that design patterns generally are due to flaws in C++/Java are historically innaccurate. Design patterns (like much of modern programming) originated in the Smalltalk community. Smalltalk is dynamic. It has first-class functions. Most of the flaws pointed to in C++ which "modern" languages solve did not exist in Smalltalk. The patterns, then, have value independent of that flaws and the accused language. For instance, the Strategy pattern is covered not just in the Gang of Four (where it happens to have a C++ example), but also in the Design Patterns Smalltalk Companion which points out that it is used in Smalltalk in the MVC framework at the heart of Smalltalk's GUI. The controller is a strategy pattern. It is also used ImageRenderer and a few other examples.

First class functions do not, by themselves, obviate the need for a strategy pattern. This is more a nit than a real argument, but it remains true nonetheless. To say a language has first class functions means merely that functions can be passed as data types. It does not necessitate that the language implements closures. Closures are a way of capturing the context of the function. They can be used to retain state between calls to a particular function instance. Without closures, there is no state. Without state, many of the strategy pattern uses fail. Consider for a moment using a strategy pattern to encapsulate encryption algorithms. Without closures (or objects), you would have to pass the encryption key to the function every time it was used. This is possible, but not terribly elegant.

The existence of an alternate implementation does not make the original implementation any less useful. The fact that I can get much of the power of OO out of first class functions and closures does not mean OO is now of no value. There are advantages to both techniques. Empirically there does appear to be power in OO that is not captured (easily) by purely functional languages. Most successful functional (or psuedo-functional) languages have adopted OO features eventually. See Python, Ruby, Common Lisp, Scala, etc. All added or have object-oriented features. Let us return to the example of the strategy pattern. Is its utility obviated by the use of first class functions plus closures? In many cases it is. Certainly it could be in the encryption example. On the other hand, strategies are often more complex than mere functions can express. The controller in MVC is a strategy. In anything but a toy application, the controller will consist of multiple functions. Sure, one could create these functions with the same closure and thus share state, but is that really a superior model? I would argue that it is not. In this case it would seem a less clear mechanism because the fact that the functions are tied together is less discoverable. OO languages and functional languages each do things differently. Things that are easy in one are more difficult in the other. Neither is superior in all respects.

It should be noted that when I say "design patterns" above I am referring to it in the common sense of the object-oriented programming design patterns made popular by the Gang of Four book. In a more general sense, each language has its own set of patterns and these can also be thought of as design patterns. Some of the OO patterns are specific to OO languages and the need doesn't translate to functional languages. Others are more "in the large" and likely translate well to all languages trying to solve big problems. It is my claim, however, that most of the GoF patterns will be useful in any OO language. They are not artifacts of particular implementations such as C++ or Java.

Is there really a benefit in lossless audio formats?

2009-11-19T07:14:55Z

Lossless codecs are all the rage amongst those who aspire to be audiophiles. Whether it is ripping CDs in a format like FLAC or WMA Lossless or listening the TrueHD track on Bluray movies, there are those who swear by it. Most audio formats like MP3, AAC, and WMA are lossy formats. They compress the audio by throwing away parts that humans theoretically cannot hear. This is called “perceptual coding.” Lossless codecs don’t throw away any information but instead compress more like Zip. Lossless formats require a lot more space to store and a lot more bandwidth to transmit. Are they worth it? Can people really hear the difference?

TrustedReviews says no. They go so far as to suggest than anything over 192kpbs MP3 is virtually impossible to differentiate. “[A] few people in the last six months or so - people who take their audio gear seriously and have spent thousands of pounds on Hi-Fi equipment - have admitted privately to us that 256kbps MP3 is easily good enough for serious listening, and that they struggle to hear much difference over 192kbps MP3 in many situations.” They conducted some A/B listening tests to see if ordinary people could perceive a difference. The results did not support the extra expense and size of lossless formats. In fact, most people couldn’t even differentiate between the 192kbps MP3s and a FLAC encoded version of the same songs. The test wasn’t scientific, but there’s a pretty good chance it matches what those reading this blog will experience.

Considering that most people listen to their music in noisy environments, on suboptimal speakers, or on tiny headphones from an MP3 player like the Zune, the chances they will ever be able to perceive the differences in audio are quickly diminishing.

The short of it: don’t waste the space ripping everything to lossless unless you plan to do a lot of transcoding in the future. Don’t go out of your way to get a TrueHD movie setup. AC3 is going to be just fine.

A Review of a Kindle

2009-11-13T18:14:00Z

Six months ago I purchased a Kindle 2. I originally bought the Kindle to make travelling easier. I tend to carry a lot of books with me when I take a trip and those books get heavy. With the Kindle, I could carry just this one device instead of 5 books. The Kindle didn’t disappoint. It weighs less than the typical paperback book. It fits nicely in my Scottevest jacket. I typically have about 80 books on mine at any given time giving me plenty of potential reading material. If that isn’t enough, there is the Kindle store with some 360,000 books.

The Kindle satisfied the purpose I bought it for, but has exceeded my expectations. Not only do I use the Kindle when travelling, but it has become my preferred reading device. The screen is a delight to read on. The contrast may not be quite what it is on a real book, but it is plenty good. The screen on the Kindle is much more comfortable to read on than the screen on a phone or a laptop. There is no refresh rate and no backlighting. This results in a significant reduction in eye fatigue. I can read on the Kindle as easily and as long as I can read a paper book.

In addition to being a great place to read, there are several features of the Kindle that make it my preferred reading tool. The first is the built-in dictionary and the second is the ease of taking notes. When reading a dead tree book, if I come across a word that I don’t know, I will usually guess at the meaning from the context and move along. With the Kindle, I can just move the cursor over the word in question and get a definition at the bottom of the screen. In this way I am able to understand the nuances of the text and expand my vocabulary. The Kindle is also a great place to take notes. Want to add a note? Just start typing using the integrated keyboard. Want to highlight some text? Move the cursor to the start, press down, move to the end, press down again. The notes and highlighted areas are collected in a text file that you can upload to your computer. They are also available on http://kindle.amazon.com/. The notes will follow the book to other devices (like the new Windows software).

So what isn’t to like? The Kindle is an excellent book-reading platform. It is a single-task device. It is great at what it does and not good at anything else. It has a built-in web browser, but it is the sort of thing you would only want to use in case of emergencies. It does not render pages well, is difficult to navigate, and is very slow. For instance, when composing an e-mail via either hotmail or gmail, it writes the letter, deletes it, then writes it again. It is very easy to get well ahead of the cursor even on the limited keyboard.

The Kindle supports MP3 playback, but not in any useful fashion. You cannot see the songs. You cannot select the songs. You can skip to the next song, but that is all. There is no shuffle. Playback happens in the order the songs were put on the Kindle. To say this feature is limited is an understatement.

The Kindle only reads its own formats. It can read variations of the mobipocket format but cannot read pdf, epub (the standard ebook format for everyone else), or even the encrypted mobipocket format found for free at many libraries. This choice perplexes me.

The note-taking is simple and works well, but it is capped. If you highlight too much of a book, the highlights will continue, but the material will not end up in the notes file. This wouldn’t be quite so bad if you were warned but you aren’t. Instead you find out later when you go to the notes file and see a warning instead of the highlighted text.

Perhaps the most disappointing part is the lack of software innovation going on. As someone accustomed to the rate of innovation on other devices, it is disappointing to see no new firmware or features being pushed. The hardware platform is stable, but why not improve the mp3 playback? Why not add new formats? Why not add support for tags or folders?

A few questions and answers:

How is the battery life? It is amazing. With the wireless left on, it will last several days. With the wireless off (and there is no reason to leave it on), it will last weeks.

Is it economical? No. If you buy a Kindle, don’t buy it to save money on books. Sure, they are a little cheaper than the hardcover, but maybe 10%. At $259 for a Kindle 2, it is going to take a long time to make up the difference. If you watch, there are many free books available which can help, but it is not a cheap device.

Are most books available? That depends what sort of books you like to read. I have found that a large percentage of what I read is available. I still run into many books I want that are not available, but I’m not running out of books on it either.

How about technical books? Surprisingly, it is pretty good. I have read a few programming books on it including Programming Clojure and Javascript: The Good Parts. It renders them just fine. Where it falls down is in the random access. I don’t recommend using it for reference material.

How does it compare to the Nook? I don’t know. I haven’t used the Nook. It appears to have superior hardware in most respects, but the book pricing is much worse. If I were making the choice today, I would still choose the Kindle. The Nook does appear to be giving it a run for its money though. Strong competition is probably what the Kindle needed.

Do you recommend the Kindle? Yes. Highly. If you like to read, get one.

StackOverflow DevDays

2009-10-22T07:38:00Z

I spent the day at Benaroya Hall for the 1st (annual?) StackOverflow DevDays conference. Overall eight speakers took the stage on topics from .Net MVC to Python to the Google App Engine. The room appears to hold just over 500 people and it was filled to capacity with programmers. There were some vendors in attendance including Amazon.com, Fog Creek Software, and someone showing off HexBugs.

The day started off with a short video titled Scrumms which was a funny spoof on life at Fog Creek and the StackOverflow podcast. It was quite entertaining. I hope they release it on the web after the conferences complete in a few weeks.

Joel Spolsky was the first speaker. I always enjoy reading and listening to him. This speech was not a disappointment. He was as entertaining as ever. The subject matter under discussion was that of design elegance. He began by pointing out that software often gives the user too much choice. Often times it interrupts the user’s work flow to ask a question most users are unprepared to answer. Other times there are options pages with myriad options which no one could know enough to actually use. What is a “trusted user” on GMail anyway? He cited a study where one store put out a lot of varieties of jam (24?) for people to try. Many did, but substantially fewer actually purchased than when the same store put out only a half dozen varieties. People are intimidated when given too much choice. Joel recommended the book, The Paradox of Choice. He then went on to talk about the simplicity offered by companies such as 37 Signals whose products do only one thing, but do it well. He argued that this isn’t the solution. Customers will demand more features and to grow, a company must grow its feature set. More sales leads to more features. Choice must be offered then, but how to do it in a way that doesn’t alienate the customer? The solution Joel offered up was to make sure the choices support what the user is doing. The users should be modeled and choices aligned along the path of their behavior.

Joel was followed by Scott Hanselman who gave an overview of the ASP.Net MVC framework. This is a web framework built on top of the ASP.Net framework, but which exposes much more direct control to the programmer. For instance, they now have direct control of their URL’s (yeah!). Scott was an entertaining speaker although I think he was a bit too self-deprecating about Microsoft. He spent most of the talk showing the audience various features in existing and upcoming Visual Studio products which make ASP.Net MVC programming easy.

Next up was Rory Blyth talking about iPhone development. He was an engaging speaker who obviously knows a lot about what he is doing. I had never looked at iPhone or Objective C development before. I can’t say I’m terribly impressed. The tools like adequate, but aren’t as good as Visual Studio or even Eclipse. Objective C looks like a mishmash of C and Smalltalk. Rory described learning to develop for the iPhone as the Stockholm Syndrome where you eventually come to love your oppressor. The iPhone is an attractive target to develop for from a business perspective (maybe), but the SDK doesn’t appear to be the reason people are flocking to it. One highlight at the end was when Rory showed Novell’s MonoTouch which allows for C# development targeting the iPhone. This looks like a slick environment even if it is a little pricey.

Following Rory came Joel again with a sales pitch for FogBugs 7. I have to say I was impressed with the empirical scheduling. There is a new plugin called Kiln for code reviews which looks alright, but I think I prefer the UI from Malevich better. For instance, the comments didn’t appear inline with the text when they were being made. They did later when the submitter saw them though so perhaps I just missed something as Joel blazed through the UI. If I were a startup, I would definitely consider using FogBugz to handle my planning and bug tracking needs.

Lunch was catered by Wolfgang Puck and was reasonably good consider it was a conference and the whole thing only cost $99. They divided up the tables into discussion topics (great idea!). I went to a table about programming languages, but others included agile methods, startups, and a few I forgot.

The first speaker after lunch was Cody Lindley from Ning who was talking about jQuery. jQuery has been on my list of topics to learn about, but never made it to the top of said list. It’s fascinating technology, especially considering I just read Crockford’s Javascript: The Good Parts recently and got a feel for the language as it was meant to be used. For those that don’t know, jQuery is the most popular Javascript framework right now. It runs on 35% of all Javascript pages on the web and 21% of all web pages of any kind. It’s primary use is to make manipulating the DOM (the page structure) much easier. Boiled down it lets a programmer easily select some portion of the page and apply an effect to it. In implementation, it appears to be a Javascript function that wraps up a collection of page elements into a class which then provides methods for manipulating the set. Cody used jsbin.com for his demo which appears to be an online javascript testing and debugging tool. It looks very nice.

Daniel Racha from Nokia was next up to talk about Qt (pronounced "cute" not "Q-T"). This is a cross-platform UI toolkit and development platform recently purchased by Nokia. It is also the basis of the K Desktop Environment (KDE) for Linux and is where Webkit originated. Webkit is the rendering engine that powers Safari and Chrome. Nokia’s plan is to use Qt as the basis for its phone app development story. The technology and the tools are both mature and highly capable. Daniel did a good job selling the merits of Nokia’s tool chain. Considering the toolkit supports 6 platforms right now (Windows, Mac, Linux, plus several phone OS’s), I can see how this might be the way for cross-phone applications to be written. Daniel also mentioned the Nokia N900 which apparently is completely open source to the point where end users could upload their own OS. I can foresee 3rd party variants like those created for the Linksys routers. This could be an interesting challenge to Apple’s iPhone strategy.

Ted Leung from Sun came to talk about Python. This is another language I haven’t had time to learn yet. His slides were terribly hard to read (purple on black—seriously?), but the content was good. He gave a quick overview of the language basics and then talked about more advanced features like destructuring, generators (simple continuations), decorators, and extensions. Python has definitely taken a lot from the world of functional programming.

Dan Sanderson was next up and gave an introduction to the Google App Engine. It looks like an interesting way to build out scalable web sites. This is the competitor to Amazon’s S3 and Microsoft’s Azure. It supports the Python and Java virtual machines and so sites can be implemented in Python, Java, or any language that targets the JVM (Clojure, Scala, JRuby, etc.). With that kind of support it would seem an app programmed to it would be capable of being moved, but that would not be the case. The app engine is a very different sandbox to play in. The database is non-relational and doesn’t support SQL (or at least fully SQL), the filesystem is different, there is no direct network access. In short, once an app is written to the App Engine, it won’t easily run anywhere else. The environment looks intriguing, but you are putting your company’s fate into Google’s hands.

The day ended with Steve Seitz from the University of Washington talking about some of the advances in 3D image extrapolation. Steve is behind much of the technology that became PhotoSynth. Steve’s talk was light on programming content but high on “Wow!” factor. This was a great way to end the day. I’m not sure my mind could have taken another heavy talk. The stuff Steve showed us was mind blowing. They are able to take regular photographs, process them, and recreate the 3D scene. Not only that, but newer technology allows for a walkthrough of the site and even full texturing. You can see it here. The best is this one:

<\/param><\/embed><\/object><\/div>";" galleryimg="no" mce_src="http://blogs.msdn.com/blogfiles/steverowe/WindowsLiveWriter/StackOverflowDevDays_14916/video5953daf864bf.jpg">

Overall the day was well spent. I got to learn about a lot of cool new technologies and renew my excitement for programming. Now I just have to pick one and find the time to learn it. If the event takes place again next year, I definitely intend on going. Thanks to Joel Spolsky and the folks at Carsonified for putting on such a great conference.

For more, find other reviews on Meta.Stackoverflow or watch the Twitter stream.

Forging a Team Identity

2009-09-30T19:25:53Z

For a group of coworkers to have a chance of becoming a team, they must share a common sense of purpose or identity. Dave Logan in Tribal Leadership calls this a “Noble Cause.” On small teams this often comes naturally. Everyone is working on the same project or related set of features. As teams become larger, their goals become more dissimilar and team identity becomes harder to forge. It is up to the leader to forge this team identity.

Having a unifying cause (whether noble or not) is important to get the most out of a team. If people are all working toward a common goal, they will make the right compromises to do what is best for the team as a whole. If there is no unifying cause, people will be working to optimize locally which is usually at odds with global optimization. Each person will be trying their hardest, but if they are pulling is different directions, some of their effort will cancel out the effort of others. Having a unifying cause does not guarantee that people work in concert, but it is certainly a prerequisite.

How does one go about finding a unifying cause? First look at the obvious candidates. If the whole team is working on a particular product or feature area, just use that. In my past I have unified teams around the concept of working on audio in Windows or on being the video team. Sometimes there is no single feature to focus on. In my last position I had 3 teams working for me. Each had a distinct area to work on. We were all part of the Windows organization, but we were such a small part that we couldn’t take that as our identity. Each team even had its own identity, but as a group of leads, we didn’t. What Joe was working on didn’t relate much to what Jane was working on. I was convicted by Tribal Leadership and Good to Great that we needed a point of unification, but there wasn’t a product we has in common. It was time to forge an identity rather than find one.

The unifying principal I chose was becoming better managers together. This is something we all had in common, being managers, and something we could help each other with. Even if the technologies we were working on didn’t form a conceptual whole, our positions did. Toward this end we made sure to have a lot of discussions about managing people. We would discuss situations and how to handle them. We started a weekly “book club” where we would read a chapter of a book each week and discuss it in our leads meeting (more on this in a future post). It worked well. The team began to gel work work together. People began forming triad relationships rather than being dyadic. That is, they started helping each other rather than merely reporting everything to me.

It is important that a team, whether it be a team of ICs all working on the same feature or a group of leads reporting to a manager, have some common identity. This in turns requires a goal or a unifying principal. If there are no obvious candidates to be found, identity should be forged from something less obvious. In the second case, it is easy to operate without a unifying goal, but things will run less smoothly. Be intentional about ensuring each team has a common identity.

Own the Feedback

2009-08-04T19:19:00Z

Some time ago I was at a management training course. The group was divided into those who were managers of managers known in this course as M2s and those who were what I have been calling leads–that is managers of individual contributors–which they called M1s. I was part of the M2 group. The M1s were divided into groups of 10 or so and an M2 was assigned to each group as the Manager and another as merely an individual contributor. A couple of the M2s–myself included–formed the executive committee and were not involved in the working groups at all the first day. On the second day we changed things up and I wound up as an IC on a team. I knew I could not come into this group that didn't know me and act as the leader. It wasn't my role and it wouldn't be accepted. I tried really hard to play the supporting role.

When I arrived, the group was in some trouble. They were in the middle of wordsmithing their mission statement (this on day 2!!). To make it worse, all 10 members were involved in this and it was becoming a marathon session. In an effort to help out, I made several suggestions and tried to ask questions to point them in the right direction. I didn't tell them how to act. They could freely take or leave my suggestions. At least, that is how I perceived it.

At the end of the 2nd day there was a feedback session. Many of the members said something to the effect “I felt you were trying to take over the team.” My initial reaction was to challenge the validity of these statements. Not out loud of course, but internally. I had no intent in taking over. In fact I had been trying hard to avoid taking over. I carefully crafted my suggestions in such a way that they were not instructions, but just offerings of opinion that carried no weight of authority. If I had been actively avoiding taking over, these people must be in error in their judgement.

When the M2s gathered I shared this experience with someone who had become a mentor to me. His sage advice was, “You have to own the feedback.” What he meant was that there had to be truth in there. Even if the feedback wasn't an accurate representation of reality–I was *not* trying to take over–it was an accurate representation of their perception of reality. Something about the situation and my actions had caused this perception. I could either accept that and look for the cause or I could reject that and learn nothing.

I chose to accept the criticism and looked for the root cause of their perception. I was totally new to the situation. These people did not know me. Even though my suggestions were not intended as instructions, they were perceived that way because I was perceived as the new guy and new guys shouldn't act with authority so fast. In their minds I was the new hire and didn't understand the situation. I had built up no relationships, no human capital with them and thus had no implicity trust. I thus talked with more authority than someone in my position should have. It wasn't so much me but the position I held. I needed to act more in line with their expectations. I needed to build the relationship before giving advice.

This analysis was born out later as people gave me the feedback that I had done less to try to take over as the session wore on. In reality, I had initially been rejecting their feedback and so hadn't changed. My actions were the same late on day 2 as they were early that day. The actions hadn't changed, but the perception had. I had built up some human capital and so my actions were being perceived differently. The specific takeaway is to know your perceived position and to act within it. Perception matters. It is important to build relationships before trying to affect change.

The more general takeaway is to always own the feedback. When people say they perceive you in a particular way, that cannot be argued. The fact is, whether you intended it or not, you were perceived in that manner. The only two options are to accept the feedback and act on it or to ignore it and burn the relationship. The world is too small to go around cavalierly burning relationships. Owning the feedback means accepting that you did something to create the perception. It could be reality. It could have been that I really was trying to take over the group. Or it could be merely perceptual. I had acted in such a way so as to appear to want to take control even though I didn't. It is important to discern which of these is true because the solution is different in each case.

This is advice I end up giving often at review time. Someone gets a tough message and wants to challenge it. “But I didn't do …” or “But that's not how it really happened.” These responses are not taking responsibility for the event. They are not examples of owning the feedback. The person proffering these responses will not fix the problem because they are externalizing blame for it. The true problem lies with someone else and so they have no responsibility or even ability to fix it. My response to this is consistent. The reality is that this is the perception. If they didn't do what they are accused of, then they did something to cause someone to think that they did. Whatever that was, they need to look for a way to address it. If not, they'll be getting the same review next year and at that point it will become a trend.

How to Interact with Your Team as a Manager

2009-07-27T17:49:09Z

As one moves from being a lead (manager whose reports are individual contributors) to a manager (manager whose reports are leads), there is an important decision to be made about how to interact with your skip-level reports. That is, how should a manager handle his interactions with the individual contributors reporting to his leads. There are two ends of this spectrum and managers often gravitate to one end or the other. The first option is to bypass the leads and go directly to those on the front lines. The second is to route most interactions through the leads. Both have their advantages and disadvantages. Where to position yourself between these two ends of the spectrum is not an easy decision to make.

If a manager decides to bypass her reports and go directly to the individual contributors (ICs), she has direct knowledge of how things are progressing. She develops a direct relationship with the ICs. Things are more likely to be done the way she wants. However, there are some significant downsides to this behavior as well.

First, it is hard to scale to this level. The fact that the organization chose to have leads should indicate that the work is too big for one person to manage. If the manager can handle all of the ICs directly, the lead position is extraneous and harmful. The reality is that this manager is unlikely to have enough time to closely monitor the work all of the time. Her interaction with the team will then tend toward drive-by management. She will swoop in and give direction on a particular part of a project but then lose focus before the results of the direction become evident. This can lead to poor decisions being implemented and frustration among the individuals carrying out the instructions.

Second, it can lead to discontent among the leads. They will have particular ways they want work done and a priority order for what they want done. Having their manager go directly to their reports means these instructions will be contradicted. This causes confusion among the ICs who will have conflicting priorities and goals. The lead will also feel his role being undermined by his manager. When she goes to his reports and gives them instructions, he is out of the loop and will begin to feel unnecessary or even frustrated. This can cause the lead to stop performing the duties of a lead and allowing the manager to do that work. As the manager is unable to give the same amount of attention, this often leads to a situation where no one is paying attention.

What about the alternative? Routing work through the leads. When a manager wants her team to do something, rather than going to Fred the IC with instructions, she asks the lead to ask Fred to do the work. This allows for the lead to always be in the loop. It allows the lead to ensure that there is a clear message (see blog past on providing clarity) so that the IC only has one set of priorities. It also allows the manager to scale. Rather than having to check in on Fred's progress, she can just ask her lead in their 1:1 how things are going. The details of the work can be left to the lead and the manager need only bother with the end goals. This may sound good, but there are downsides as well.

First, going through another person in communication always risks the message getting distorted. As anyone who played telephone in elementary school can attest, the more people that retransmit a message, the more it will change. In the elementary school game children are asked to sit in a line. The first child is given a message and asked to tell the next child in line. Each child in turn is to repeat what they heard to the next child. The final child will announce to the group the message he received. With rare exception, the final message is not even related to the initial one.

Second, going through another person can limit the amount of feedback received. If Jane the manager tells her lead Marcus to have his team make the iWidget program interface with the new build process, there is some chance that Jane will not learn that this is more difficult than initially conceived. If Marcus does his job poorly, he may not relay the message to Jane. This leads to frustration on all fronts. Jane is upset because the project is taking too long. Fred the IC is upset because he is being asked to do the impossible. Marcus may even be frustrated because both his manager and his report are frustrated.

The third and perhaps most insidious downside of this management approach is the lack of relationship that gets built. People will subconsciously distrust those who they do not have a relationship with. Their natural tendency is to distrust until they have reason to trust. The reason doesn't have to be large. It could just be seeing that the manager treats others fairly or having casual conversations which convey the sense that the manager is a “real person.” The result of this psychological phenomenon is that until a manager has built up social capital via relationships, she will not get the benefit of the doubt from her team. Subtly, the team will interpret ambiguous actions in a negative light. Asking for a code review will not be seen as a way to strengthen the team's coding skills but rather as a way to check up on people and “get them” if they aren't doing well enough. Mail sent asking about the status of a bug will be viewed as accusatory rather than merely inquisitive. The most insidious part is that the manager will probably never realize this is happening because she doesn't have the relationships that would provide the necessary feedback channel.

In the past year I made the transition to manager and faced this exact quandary. My decision was to route most interaction through my reports. When I needed work done, I would ask the manager to have the work done instead of going directly to the report. I knew the downsides of not letting leads do their job and wasn't going to make that mistake. Instead, I made the mistake of being too distant. I built up relationships with my direct reports, but not as much with the teams reporting to them. Based on this experience, I will be trying a more mixed approach in the future.

I still believe it is important not to bypass the leads when giving work instructions. Yes, this has the telephone problem, but the consequences of avoiding that are too great. At the same time, it is important to build a relationship with the individual contributors. This means ensuring direct contact. At the lower edge contact should be made at the individual level by wandering the halls and by skip-level 1:1s. At the higher edge, contact should be made by sending out broad mails laying out high-level vision, by all-team meetings even if there is no business demand for them, and by occasionally attending your team leads' meetings. The middle (direct business communication) should be left to the leads. In initiating contact at the individual level for personal contact and at the vision level for business, you should generate enough “human capital” that the team will come to trust you and give you the benefit of the doubt.

Be Intentional

2009-07-01T20:33:50Z

My old manager used to always say, “Be intentional.” It took me a long time to comprehend exactly what he meant by this, but eventually I did and have come to appreciate the advice. What he meant was to always make active, conscious decisions rather than just letting things happen. It also means to verify things rather than assuming they are a certain way. For example, if you don’t have enough time to do everything on your plate, think carefully about which items will not get done rather than just working on items in no particular order. It should be your intent which specific items go undone.

This is a good principle to act by. All too often people think about what they *are* doing but don’t consider what they *are not* doing. It is just as important to be conscious about what you are not doing as it is to be aware of what you are. If you don’t actively choose that which is not done, it is likely that the wrong things will drop off your plate. It is easy to be busy working on something that is important to the detriment of something that is really important. It is best to make all decisions, both positive and negative, conscious ones. I’ll often ask my team when something goes undone whether that was intentional or not. If there is only time to do 3 items and there are 4 that should be done, I’m fine with the 4th being dropped. It is a poor manager who is upset when the impossible isn’t accomplished. I do, however, hold my team accountable for that 4th item being something they intend to not get done rather than whatever just happened to be left at the end of the day.

I’ve seen this come up in testing features. I recall a time when a report of mine was testing a particular feature with two aspects to it. For good reasons he started working on the first part, a complex parser for device attributes. Being complex, this took a long time to thoroughly test. In fact, it was taking long enough that he was not going to be able to get to the second aspect of the feature at all. I inquired whether this was really the right approach. Did he think it was better to thoroughly test the parser and test the other part none or would it be better to test the parser to some level, then test the other aspect, and finally return (in the future) to cover the less important parts of the parser. Upon reflection he decided it was a better idea to cover both to some extent than one fully and the other none. The trouble here is that he wasn’t acting intentionally. The test plan called for testing both aspects thoroughly. The plan didn’t call for ignoring the second part. It was just because of the unexpected difficulty of testing the parser that the second was going to be missed. He needed to step back, re-evaluate, and decide intentionally rather than just letting events dictate what was going to be dropped.

This principle is also good to apply when dealing with other people. Instead of just assuming that the other party will do the right thing, being intentional means specifically outlining expectations of them. It is easy to think you’ve told someone what to do without them realizing that you did. Being intentional means verifying that your assumptions were communicated and following up later. It means being explicit when handing work to another person. Make sure they understand that it is your expectation that they now have the action item before you clear it from your to-do list.

Five Books To Read If You Want My Job

2009-05-28T03:03:52Z

This came out of a conversation I had today with a few other test leads. the question was, “What are the top 5 books you should read if you want my job?” My job in this case being that of a test development lead. At Microsoft that means I lead a team (or teams) of people whose job it is to write software which automatically tests the product.

Behind Closed Doors by Johanna Rothman – One of the best books on practical management that I’ve run across. 1:1’s, managing by walking around, etc.
The Practice of Programming by Kernighan and Pike– Similar to Code Complete but a lot more succinct. How to be a good developer. Even if you don’t develop, you have to help your team do so.
Design Patterns by Gamma et al – Understand how to construct well factored software.
How to Break Software by James Whittaker – The best practical guide to software testing. No egg headed notions here. Only ideas that work. I’ve heard that How We Test Software at Microsoft is a good alternative but I haven’t read it yet.
Smart, and Gets Things Done by Joel Spolsky – How great developers think and how to recruit them. Get and retain a great team.

This is not an exhaustive list. There is a lot more to learn than what is represented in these books, but these will touch on the essentials. If you have additional suggestions, please leave them in the comments.

Some Programming Languages to Consider Learning

2009-05-12T18:21:00Z

Learning a new programming language can affect the way you think. While most modern languages are Turing Complete and can theoretically all accomplish the same things, that’s not practically true. Each language has its own strengths of expressiveness. For instance, trying to write dynamically typed code in C++ is possible, but a pain in the neck. You would have to implement your own type system to do so. Each language makes certain things easy and other things hard. Learning different languages then exposes you to different approaches. Each approach provides a different way of thinking and a set of tools supporting that way of thinking. What follows are some of the languages I’ve learned and what I think they provide. This list is limited to languages I’ve studied in at least a little depth. There are many more languages out there that may be useful. If you have additional suggestions, please make them in the comments.

C – This is coding very close to the metal. Learning it promotes an understanding of memory, pointers, etc.
Lisp/Scheme – Once you get past your parenthesis-phobia, it’s a very elegant language. The big learnings here are treating code as data, metaprogramming (writing programs that themselves write programs), and recursion. Lisp is also a dynamically-typed language.
Clojure – A variant of Lisp that runs on the JVM. In addition to what you can learn from Lisp, it adds persistent data structures and transactional memory. Persistent data structures are ones that *never* change. Once you have a “pointer” to one, it will never change underneath you. This makes parallel programming much simpler. Clojure also is more of a functional language than Lisp/Scheme. It is not purely functional, but allows for the functional style to be followed more easily.
Smalltalk – Much of modern programming originated in this language. Modern GUIs are based on the Xerox Parc Smalltalk systems. Object Oriented programming was first popularized in Smalltalk. Extreme Programming, Agile, and Design patterns all found their initial formulations in Smalltalk. In addition to learning about OO programming, Smalltalk is great to understand message passing. This gives object-oriented code a different feel than the function call semantics of C++/Java/C#. Smalltalk is also a dynamic language.
Perl – Perl was once known as the duct tape of the internet. It ran everything. It has since been surpassed (at least in blogosphere popularity) by other scripting languages like Ruby and Python. The biggest thing to learn from Perl is regular expressions. They are built into the core of the language. Other languages support them but often as a library. Even those that do support them in the syntax do not usually utilize them so pervasively.
C#/Java – These languages both solve the same problems in almost the same ways. They are a great place to learn object-oriented programming. It is built in from the ground up. The OO style is one of function calls and strong interfaces (which distinguishes it from Smalltalk). These languages also have the largest accompanying libraries.

Inbox Zero, Take Two

2009-04-30T20:04:41Z

A year and a half ago I tried to get to “Inbox Zero” and failed. This is the idea that you get your inbox down to zero mails every day. I’m making another run at it and this time have been a little more successful. I’m not perfect, but I haven’t fallen off the horse yet either. Here’s what I have found to work.

Let all interesting mail fall directly into the inbox. Don’t use separate folders for stuff from your boss or an alias/list that is important.
Move non-interesting mail into a separate folder by a rule. I have rules to shunt off aliases I find merely interesting but not important into their own folders automatically.
Read or skim every mail that is in your inbox. For each, make one of the following decisions:

Respond. Read it and take the appropriate action. If you can do this in a minute or two, just do it.
Delete it. You have the information or it wasn’t interesting. Either way, you don’t need to keep it around.
Archive it. You may need to refer back to it later, but you don’t need to take any action on it.
Mark it for further reading. It’s not critical to act on it, but too long to read now. Put it in a folder to read later.
Mark it for further action. It will take longer than you have to respond, but a response is necessary. Put it in a folder for later response.

Following these rules makes my inbox look something like this:

Inbox

Action Required
Archive
Read Later

Interests

Various subfolders for the non-critical aliases I am part of.

I also have a rule to move all mail sent to: or cc: me directly to my inbox. This way mail intended for my eyes won’t get filtered into an “interests” folder.

I have found this system simple enough to keep up with it. It also means I no longer miss mails which got filtered into some folder I haven’t yet read for today. I now see every interesting mail and am at least aware of it. It also helps me keep track of the mails I really need to go back and respond to. My old system was just to leave them unread, but this got unwieldy very quickly and I never made it back to most of them.