My title doesn’t distinguish between software quality, processes quality, data quality, etc.. Right now I am starting to organize a document which outlines what I feel are (currently) the quality related risks for 2009 and the steps we can take to attempt a mitigation of them. Since this is not just about our software I don’t have my usual taxonomy of bugs to fall back on. Here are the big buckets I am think comprise the quality of an organization

• People – without people, there is nothing
• Product – this is what those people produce
• Service – to customers (consumer and corporate) as well as business partners; new and old
• Communication – internally and externally

I think each bucket can be further broken down into ‘Focus’, ‘Development’ and ‘Delivery’.

This is still very much an idea in progress. What other buckets are there? What traits d those buckets have?

The current Rands In Repose is the story of The Larry Test which is about done meaning Done and some subtle team heuristics to decide if you have reached the Good Enough state for shipping. I like Michael Lopp’s writing style and the points he raises in his posts; another recommended blog if you have any sort of management / lead aspirations.

Anyhow, the most important bits of this post are not even related to the main narrative.

• Different managers have different communication styles and there are those where delivery of criticism feels almost pleasant. But criticism, whether it’s constructive or destructive, coming from the guy who signs the checks often triggers the knee-jerk negative “I did something wrong” vibe. – It is not just managers who have to keep this in mind. If you are a leader (officially or unofficially) you need to be aware of this. Also, in situations of greater power distance, greater awareness needs to be had.
• What your boss has that you do not is, hopefully, more experience. What he should be able to do after looking at a situation you’ve been staring at for a month is say, “Yeah, I’ve seen this before and this is how this is going to play out.” – And hopefully that experience is still relevant to the current situation. If not, you’re screwed.
• Part of your job is to become your boss. What you are doing while stumbling to and fro is finding and building the experience your boss already has. The trick and the art is, how long did your boss let you stumble? I mean learn. There’s a fine line between managerial insight and incompetence. Your job, and your manager’s, is to let your team wander long enough to find that experience. – Isn’t one of the agile practices to Fail Fast then write a unit test to prevent the failure from ever coming back? Same thing for experiential learning. Fail, then don’t fail that way again. Fail in a new way. Whomever can figure out how to write unit tests for human behavior will make a killing.

The book-of-the-month in the testing community right now seems to be Outliers by Malcolm Gladwell. I’m sure I’ll read it eventually, but a more important book I think was released around the same time. That book is Tribes by Seth Godin.

As you might tell from my recent burst of leadership and marketing related posted, I think to have the most career success possible you need to step up and assume a leadership role. This does not mean leaving your day-to-day testing position for the meetings and bureaucracy of management, but one of community, group or tribal leadership.

A tribe is a group of people connected to one another, connected to a leader, and connected to an idea.

The key part of that definition is ‘connected to a leader’. People connected to an idea is not enough, and that is where Tribes comes in. Tribes lays out the why and to a certain degree the how of tribe leadership. There are no ‘chapters’ per se, but around 115 or so little topics stung together to form a nice narrative which make it great commuting reading or for taking a break between tasks. Here is a sample of those headings

• Why should you lead? And why now?
• Fear of failure is overrated
• Participating Isn’t Leading
• The difference between things that happen to you and things you do
• Sheepwalking
• The elements of leadership
• Positive deviants

Each of those topics has one or two great points about leadership in it, often backed up with a quick story, often from Seth’s own experience. This humanizes the topic in way fictional cases cannot.

I liked Tribes. A lot.

I learn something from every book I read, though most of the time it is just ‘stuff’ that I tuck away for later use. Tribes had the wheels of my brain were whirling the whole time while I was reading it. What tribes (vs. groups) do I belong to? Who are their leaders? Is the leader who I think it is? Am I a tribe leader? Am I supposed to be? I self-identify with the Context-Driven school of testing, though it could quite easily be relabeled as a tribe as it has all three parts of one. I think this blog and its readership might also be a tribe to a certain degree; one whose leadership I inherited through creation. Now to lead it. What other groups do I know that could transform into tribes with some leadership? Is my role to assume that leadership, or help others to do so?

My only complaint with Tribes is the format, as usual. At 21.2 x 13.2 x 1.2 cm and only 150 pages, it is a small book but the decided to make it a hardcover with dust jacket. I understand there is a certain prestige of hardcover over softcover, but that no doubt adds to the cost. Amazon is selling it for $11.99 right now, but would likely have it below the magic $10 threshold in a different format.

And of course, a book about tribes wouldn’t be complete without a tribe behind it. This tribe has been, and continues to be a busy one. First there was the Tribes Casebook which was followed up by the Tribes Q & A ebook. Both of these nicely compliment the book and further illustrates the power of a tribe.

Tribes is a big book packed in a small format and absolutely deserves a place in your bookshelf. It could also have been the most-important but overlooked non-testing book for testers of 2008.

The fastest way for me to get to / from the train every day is through a park. Being Canada though, it is covered in snow. It dawned on me the other night that my trek through the snow is similar to approaching a new task.

• When it hasn’t snowed for a few days and I have walked back and forth creating a pretty easy path for me to walk in whether or not I have my boots on or just shoes.
• Sometimes I forget to look at the weather and it snows while at work and I am caught without boots. Why would I need boots when I have already cut a path through the snow? I am still able to walk the park, but it is not going to be as fast or productive (or comfortable) as it might be had I been prepared. I could also change strategy and walk around the park.
• If someone else has walked there before me, it is easier, but unless their feet and stride are the same size it is still not as easy as it could otherwise be.

This is all just a nice way of saying “don’t get too comfortable treading the same path; eventually you are going to have to cut a new one (and having cold feet sucks)”

Here is a quote I lifted from a local indie rag attributed to Joyce Carol Oates regarding growing up and aging. Yes, the two are distinct categories.

Our society is mistaken: the experience of maturing is infinitely more delightful than ‘perpetual youth.’ In youth, one is likely to wish to be experienced….. That is, to be watched, listened to, admired; in maturity one is far more interested in experiencing — in living

No great insights and comparisons to testing about this, but it seems to fit nicely into some as-yet-unknown slot in my brain. Well, almost none. One might read this that the people who are the loudest and most demanding in having their opinions heard (right, wrong or other) are the less ‘mature’ than those who just experience and pass along that experience to others.

I found Kanwardeep Singh Ahluwalia’s paper Scalability Design Patterns via High Scalability (and is another one I have been hauling around ever since). High Scalability is one of those sites that testers should be following. All sorts of ideas pop up there.

First, two quick bullets.

• Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged
• Amdahl’s Law

And now the patterns themselves (which he mentions are best suited to transactional systems. YMMV). Note that there is a bit of implicit ordering with the parallelism ones. See the graphic in the paper to see it clearly. Also, some patterns don’t really seem to be a pattern; a meta-pattern? A pattern container?

• Optimize Algorithm – Identify tasks which can be completed in a shorter period to save processing time
• Add Hardware – Adding hardware to the existing physical node will result in what is commonly known as “vertical Scalability”, where as, adding hardware as a separate new node will result in enhanced “horizontal scalability”
• Intra-process Parallelism – Multi-threading will allow the process to make use of multiple cores, CPUs and/or hyperthreading
• Inter-process Parallelism – The system needs to replicate its process by spawning their multiple instances. All these multiple instances need to coordinate with each other to handle the load in a distributed manner. These processes can coordinate with each other with the help of a load balancer, which helps in assigning the task to each process. [The] optimum number can be determined by increasing the number of processes gradually and then observing the gain in the scalability.
• Hybrid Parallelism – Spawn both multiple threads as well as processes
• Optimize Decentralization – All such bottlenecks should be avoided by following decentralized approach, where in processing is not dependent on a particular resource, instead multiple resources are provided to make each parallel path independent enough not to be burden or dependent on the other path
• Control Shared Resources – Shared resources should be categorized in to “Access Only” and “Modifiable” resources. The most common solution to prevent the corruption of shared resources is to capture a lock on the shared resource, modify it and release the lock.
• Automate Scalability – The system needs to have a monitoring entity that measures the current throughput and has the ability to increase or decrease the number of threads or processes in the system.

I found Adam Shostack’s paper Experiences Threat Modeling at Microsoft in my bag tonight. Goodness only knows how long I’ve been totting it around. It’s a nice little behind the scenes look at how the empire analyzes its code for security issues. Here are the nuggets that jumped out at me (most of which apply to things outside of security).

• The term “threat” is used to mean both ‘threat-agent,’ that is, the person attacking a system, and as a risk, that is, what might go wrong.
• Threat modeling can be asset-centric, attacker-centric or software-centric.
• There are at least two reasons it may make sense to perform threat modeling without experts. First, experts might not be available because they are in short supply for financial or other reasons. Second, having the people who will build a system – not all of whom are security experts – involved gives them a sense of ownership and an understanding of the security model.
• There is no single “best” or “correct” way of performing threat modeling, but rather, a complex and multi-dimensional set of tradeo?s which might be made in order to meet a some set of implicit or explicit goals.
• Cost includes getting started (training, setup, software) and ongoing time commitments within a project.
• Methodologies evolved, and they evolved and continue to evolve in response to needs we discovered as we worked
• Current SDL threat modeling methodology is a 4 step process: diagramming, threat enumeration, mitigation and verification
• Use standard Data Flow Diagrams (DFD), with the addition of “trust boundaries”
• Microsoft often uses ‘feature crews’ of developers, testers and program managers who are very focused on their feature or features.
• STRIDE
• One of the anonymous reviewers asked for evidence that ‘the approaches taken are the right ones.’ I make no such claim. I do claim that the approaches are useful, for the challenges that we have identified and which I have discussed. In light of the many meanings of threat modeling and the many goals which processes may serve, I don’t believe that there is a right or wrong approach, only ones that are more or less useful.
• DREAD
  • Damage potential: How great is the damage if the vulnerability is exploited?
  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How easy is it to launch an attack?
  • Affected users: As a rough percentage, how many users are affected?
  • Discoverability: How easy is it to find the vulnerability?
• A failure to effectively model people leads to problems
• Clearly state your expected user and their skillset [of your threat model]
• Design explicit development integration points for the security modeling methodology. The integration points may seem obvious to the designer, but might not be to someone learning the system for the first time.
• Processes which can be used by any intelligent and skilled engineer will be more broadly used than processes which require unusual skills.
• Ease of use and clear documentation are important, and often receive little attention, even in work labeled “practical.”
• Data is not generically trustworthy, it’s trusted for some set of purposes. Defining that set of things is easy for small problems, and seems to be hard to generalize

Amazon’s EC2 address space is dynamic, which means it is a perfect haven for spammers and others persons of ill repute to hang out. Unfortunately that means that a lot of the email providers don’t trust email coming out of there as not-spam. The solution is to use a 3rd party smtp server, either directly or as a relay. The most common configuation involving relaying and EC2 seems to be Paul Dowman’s A rock-solid setup for sending SMTP mail from your EC2 web server. This setup, while effective, has a pretty nasty drawback that he outlines at the bottom. And that is all your mail is sent as the account you are relaying through.

But what if you don’t want all your mail sent at that user? Well, in general, it appears that you are out of luck, except in one specific use case. Fortunately for me, I am that use case.

Our application sends email to two broad categories of recipient: users (password resets, invite others, etc.) and us (feedback). Or said another way, mail we want relayed and mail we don’t. Relaying would still work technically in both cases, but what we really want is to have the feedback to come ‘from’ the user’s email so we can respond to it. (We also have FogBugz wired up to auto-respond to some accounts which is even more killer a feature than the project prediction)

Luckily, postfix has the ability to be configured this way. Here are the deviations / additions from Paul’s instructions.

• Remove the global relayhost from main.cf

  #relayhost = [mail.authsmtp.com] relayhost =

  #relayhost = [mail.authsmtp.com] relayhost =

• Specify a transport_map in main.cf

  transport_maps = hash:/etc/postfix/transport

  transport_maps = hash:/etc/postfix/transport

• Now create the transport map

  yourcompany.net : * smtp:[relay.othercompany.com]

  yourcompany.net : * smtp:[relay.othercompany.com]

  What this says is that any mail going to yourcompany.net is not relayed (so retains the From information) and everything else gets pumped through relay.othercompany.com’s smtp server

• Convert the file to something postfix knows how to read

  postmap /etc/postfix/transport

• It is likely also a good idea to fix the permissions of the file too.

  chown root.postfix transport*
  chmod 0640 transport*

• reload the configs into postfix with

  postfix reload

  postfix reload

• And then test your config to make sure you didn’t completely screw it up.

This still doesn’t solve the issue of being able to dynamically decide when to relay through different accounts, but it does solve the integration with FogBugz problem. Now, does any postfix wizard out there know how to determine the relay, not on the recipient’s address but the sender’s?

One of my posts got a pretty big bump at dzone and puttering around a bit I found Signs of a GOOD Manager / Team Lead. In the article Dave Schinkel (who really should put his name a little more prominantly than just at the bottom in the copyright footer) goes through each of these points in detail, but here is his list of characteristics / attitudes / process of good management & leadership. (Various emphasis are his.)

1. Have a passion about technology but care more about ensuring that their underlying team succeeds
2. Motivates his/her team on a regular basis
3. Passion to teach or help younger members learn
4. Ability for the lead to handle their big titles & responsibilities without constantly using a lame response such as “I’m too busy for your problems because I’m a manager and I am very busy myself” which presents a very negative type of attitude back to your developer.
5. Openness to share their expertise & insight to team members
6. Ability to Humble oneself
7. Checks often to see how team members are doing not because that manager wants to push his team, but sincerely wants to see if there are any issues or struggles
8. Ability to communicate the requirements & expectations effectively to team members
9. Treat everyone as equals
10. Do not micro manage. This will make your developer absolutely despise you. And eventually I can guarantee you that he/she will eventually say adios to that day in and out. Micro managing also shows how weak you are as a manager who feels they need to control EVERYTHING. Not healthy for you and not healthy for your team.
11. If a subordinate is struggling, lift them up
12. Understand that there must be some time set aside for your developers to study/learn
13. I don’t care what the deadline is. Take the human aspect of work into perspective in regards to YOUR team.
14. Stop saying “it’s easy” to your developers