Are These Words the Same?

Please help a colleague [me] out and respond to the following survey. Your answers will help me prepare for a followup post. All data is collected anonymously as far as I know.

Selling the Dream

I used to be acquainted with someone whose motto for running his business was "Sell the dream but deliver the reality." Does that make alarm bells go off in your head? It does mine.

We all have dreams. Maybe it's buying a house or getting student loans paid off. Perhaps it's a vacation to somewhere exotic. My dream car is a Range Rover Evoque but it is just that, a dream car because at this point in my life I can only afford one in my dreams. Dreams are where our every wish and desire are fulfilled. Sometimes dreams do come true but usually through a lot of hard work and determination.

Now if I went down to say, CarMax, told them I wanted a Range Rover Evoque, had $25,000 to spend, and they said, "Okay" I'd be pretty excited. However, if when I showed up to pick up the car they handed me the keys to a Honda Accord, I'd be pretty upset. Just to be clear, I drive a Honda Accord, his name is Eric. He's unassuming on the outside but slip into the driver's seat, wrap your hand around the six-speed manual, and you'll soon learn there's more than meets the eyes. In other words, it's a great car. Nonetheless, if I'm promised one thing but given something different - or worse, inferior, I will not be a satisfied customer and in fact I will feel cheated.

Besides the obvious that the customer doesn't get what they expected, doing business this way establishes a relationship built on lies from the very beginning. If they're willing to tell a big lie, no doubt they're willing to tell little lies the entire time they're working together. Unfortunately by the time the client figures out what's going on it's too late.

In a perfect world, business ethics wouldn't even be a topic of conversation but I think this behavior is reprehensible. And I'm proud to say that I think my current employer is the most ethically sound company I've ever worked for both in the ways they interact with clients and how they treat their employees. I digress. I personally don't ever want to get burned so it is my desire to put out into the world that which I think can help others.

Here are some things to look out for to make sure you don't end up locked in with a snake oil salesman:

1. Promises to do a lot more than any other bidders
2. Promises to do the project for a lot less money than any other bidder
3. The proposal is extremely vague
4. The proposal is so long you don't know what it's talking about or is full of a lot of flowery language about how wonderful their company and process is
5. Any part of the proposal seems to be too good to be true
6. The vendor has no concerns about meeting any of your requests (not to say they can't be fulfilled)

What you can do to protect yourself:

1. Solicit multiple bids and compare them in detail, not just the price quote
2. Insist on extremely detailed contracts*
3. Demand transparency
4. Get references for recent, comparable work. Check them and look at the finished product if at all possible
5. Listen to your instincts - If you think you're being lied to, you probably are

* I recommend watching this video. It's aimed more at the vendor than the client but the advice is spot on and really, contracts protect everyone. Note, there is a fair amount of vulgar language and there is one metaphor used that is poorly chosen. Nonetheless, I think the good outweighs the bad.

The Dog Age Paradigm

It's a well-known fact that I am the proud parent of the world's handsomest dog. Diego and I have our birthdays a mere 10 days apart which inevitably leads to the "dog years" discussion. While I'm chronologically ten times older than he, in "dog years" I'm only about 1/2 older -- that is, if you subscribe to the notion of "dog years".

The average lifespan of dogs varies from breed to breed but it's somewhere in the neighborhood of 12 years. Since humans live on average about 80 years, we can say that dogs age about seven times faster than humans. Thus, while Diego has now completed three trips around the sun, he's actually 21 in dog years.

I think this model is silly and here are just a few examples of why:

1. Dogs can walk within weeks of birth (not even three months in dog years)
2. They reach adolescence well before a year (not even seven in dog years)
3. They're full grown well before being two (not even fourteen in dog years)

I do have a point in all of this, actually several:

1. Are there things in your project and/or testing that you just blindly accept as true even though they make no sense if you actually think about them?
2. One can prove anything with numbers.
3. Do you have processes that are overly simplified [or complicated] such that the intent gets lost?

I'd like to emphasize point one a little bit more. It's very easy for us to get stuck in a certain line of thinking about anything. Perhaps there's a developer that was plagued with delivering a series of bad code and now you think he's a terrible developer. Maybe some requirements weren't very clear and now the client wants something different than what was constructed but you think your solution is the best. Context-driven testing is God's gift to software testers. Test automation is the bane of mankind.

I'm not trying to suggest in any of those scenarios that opinion was formed haphazardly. Rather, I'm suggesting to not ever stop questioning anything, including your own conclusions. Things change as time goes on and context changes. I suppose the dog years "formula" came about as a way of explaining to children why pets don't live as long as humans. What might be acceptable in explaining a concept to a 5-year-old doesn't work for a 30-year-old.

Alternatively, the death of a family pet could be the "right time" to start teaching kids algebra. If we have to have a formula, I think this one works much better:

x equals the age in dog years and y equals the age in human years.

Who's Number One: Revenue or Customers?

There's a new kid on the block, App.net that, from what I understand, is a Twitter-esque service that is supported by user and developer membership fees, not paid advertisements. The company puts it this way, "We're building a real-time social service where users and developers come first, not advertisers." Call me a cynic but I don't think App.net puts users and developers first any more than Twitter and Facebook put advertisers first. And thanks, to my cynicism, this sparked a great Twitter Debate or "twibate" mainly with my boss, @jeffturner (from the bottom up):

As you can see from the conversation, I think that revenue comes before anything else - users, developers, or even advertisers. For a company to say that they put users and developers first is the very definition of being altruistic, that is to be selfless. If the company is sincere about users first, then I ask, why not be structured as a non-profit organization? There will be a part two of this coming soon to discuss the merits of both for-profit and non-profit business organizational structures. For the duration of this post, I simply want to assert my case for why I think revenue comes first because Twitter simply doesn't lend itself to the lengthy explanation this requires.

I can't think of a single business that doesn't say something along the lines of "the customer comes first" or "the customer is always right". But that's a lie. We all know it's a lie but it's not offensive because we are endeared by the implication that customers are at least very important. Customers aren't always right. If a person attempts to return a Dell laptop to an Apple store, the geniuses are going to laugh him out of the building. If someone fat-fingers a contract so it says a website will be built with HTML 6, the customer is still going to get an HTML 5 product.

The customer isn't always wrong though either. In fact, customers are extremely important - so important that I think it's fair to say that customers and revenue go hand-in-hand. If a business doesn't have a customer base to fill the bank account, it will cease to exist faster than Solyndra. Because of that, it's imperative that the company cater to the customers but the business itself still comes first. A company can't operate in a deficit to please customers. A company can't operate illegally to please customers. A company can't operate unethically to please customers.

In the end, whichever group is paying is going to get the most attention but don't mistake attention for importance. When ordering by importance revenue is what keeps the business operating and therefore revenue must be the greater of two equals. One may start a business with the earnest intent of providing a great service and not with the intent of becoming a bazillionaire. App.net was started to provide some user-oriented features that Twitter simply can't offer and they're able to do that because they're using a different model for generating revenue. They still wouldn't even be in business if they didn't have some sort of funding. 

Acknowledging that revenue is first isn't a bad thing. Money isn't a bad thing. However, when revenue becomes disproportionately large over the customers then the business/customer relationship begins to break down. There's an implicit trust that customers understand the business needs to make money but that the business will not gouge the customers. If the business can't make money, it ceases to exist. If the business takes advantage of the customers, they'll eventually catch on and patronize someone else who will treat them fairly. Balance is key but revenue is #1.

---

On a side note, I'd like to mention I haven't actually tried App.net's service but I believe that is irrelevant to the opinions mentioned above. This isn't a review of the service. Rather, App.net serves as an excellent case study of my broader world view on business economics and should not be construed as being either for or against either Twitter or App.net. 

Side note #2: Thanks to fellow blogger Stephanie Quilao (@skinnyjeans) and her post, App.Net: Why This Consumer Would Pay A Subscription for a Twitter-like Social Network, which helped set all the gears in my head turning. I always love to read something that makes me think!

Improvising on a tune called "Exploratory Testing"

Paul Manz is someone whom I would consider to be among the greatest North American organists of the twentieth century. Had you ever attended one of his hymn festivals, you would have been treated to a number of improvisations - that is simultaneous composition and performance. And I guarantee you, you would never have thought, "This isn't music, this is just noise!" That's because his improvisations have all of the structure of music as we know it: tonality, meter, tempo, dynamic, melody, harmony, etc. And he was doing it ON THE SPOT; nothing was written down.

Exploratory testing has many parallels with improvised music but yet, it doesn't have the same respect even when executed by the "Paul Manz-es" of the testing world like James Bach and Anne-Marie Charrett.

I improvise regularly when I sit at the piano. I wasn't always very good but my skill has improved little by little over time, but particularly the last two years whereby I have had to create my own accompaniments to support congregational singing when the music editor at Oregon Catholic Press fails to understand the needs of the untrained singer. But I digress. My point however, is that no one would question the legitimacy of my playing even though I didn't sound like Paul Manz and the only thing in writing was the melody and harmonic suggestion.

E.T. is structured just like improvisations are structured. There's usually some sort of suggested charter or mission. Testers utilize various techniques to expose and isolate defects. But yet because it isn't written down in meticulous detail, E.T. is considered inferior. Some of the worst music of all time has been written down, performed over and over, and made the performer filthy rich.

While I think there's a close parallel between improvising and E.T., it doesn't hold up for written music and scripted testing. Music and testing are both art and science but I think they use them in opposite ways. Music looks for an artistic result achieved through a scientific process whereas testing looks for a scientific result achieved through an artistic process. When you script a test, you strip out the art - the intent, the intuition, the sapience, the wonder.

Any good musician should be able to read and perform music because it demonstrates the technical ability while being a means by which we can learn ultimately to express our own artistic thoughts. A tester has no need to know how to write scripts or execute them. One learns to test by testing, talking with a mentor, reading, writing, etc. and by testing. By gaining understanding of the philosophy of testing we learn ultimately to achieve the scientific results.

It's not fair that exploratory testing doesn't always get the credit it deserves but then again life isn't fair. Sojourn on testers, continually strive to better yourselves and serve as a positive example of just how effective exploratory testing is.

Splitting Definitions

There are two words that we use interchangeably and even the dictionary considers them synonyms but I'd like to challenge us to be more judicious about when we use the word "normal" and when we use the word "average." For both words when we say that x is normal or average we're trying to convey a baseline against which to judge y. However normal and average imply completely different, I might argue opposite, methods of establishing the baseline.

Normal establishes the baseline through a rule. It's objective. Anything that doesn't follow the rule is abnormal.

Average establishes the baseline based on the collection of results. It's subjective. The baseline changes as the results change. Result x could be above or below average but it becomes part of the average when evaluating result y. If we wish to exclude x from the average then we're establishing a rule.

When it comes to software, functionality is generally normal and usage is average. In most cases we define [set rules] about how the software is supposed to work but we never know exactly who will be using it or how. It is quite impossible to set a rule as to who will be using the system. Instead we observe and look for trends and patterns. Be careful though because there is no such thing as an average user and when we create rules based on some composite, mythical person, we are sure to disenfranchise real people.

Normal = Objective. Average = Subjective.

Random Ponderings on Various Pay Structures

Recently, I was thinking about the various pros and cons of the various pay structures that we use: hourly, salary, and commission. Being an ardent subscriber of the context-driven testing school, I question everything -- even when I'm not testing.

Thought 1: Link to Productivity
Hourly payment is often applied where productivity can be closely tied to time.

Examples:
Manufacturing - parts per hour
Retail - number of associates needed to handle customer load
Custodial - how much can be cleaned in a given shift

Salary payment is often applied where productivity is linked to accomplishing a task that can require varying time.

Examples:
Software testing - make sure the system works
Teaching - in addition to classroom time, prep for lessons and evaluate student work
Business executive - run the company

Commission payment is often applied where productivity is connected with sales.

Examples:
Car salesman - sell more cars, earn more money
Real Estate Agent - sell more homes, earn more money
Mortgage broker - close more loans, earn more money

Thought 2: Productivity ≠ Working Hard
For any given task with a set amount of time, Person A could exude a great deal of personal effort and not complete the task whereas Person B could exude very little personal effort and finish the task with time to spare.

Thought 3: Time = Money
Hourly: The more hours you work, the more you're paid
Salary: The fewer hours you work, the higher your effective hourly rate
Commission: The more sales you make, which in theory means, the more time you use pursuing sales leads, the more you're paid

Thought 4: Salary is a bit of an odd duck
Unlike hourly and commission, the salary payment structure does not have a built in mechanism to actually get paid more than your base rate. A salary employee gets paid the same no matter how many hours he works or how many "tasks" are completed. Salary has other perks though. Generally it has more flexible hours and sometimes you may even get to leave work a little early or take off a few hours without using paid time off. And in comparison to commission, you're still guaranteed to make money. If a salesperson can't close any sales, he won't get paid. And I don't have any data to support this but with all things being equal, I think salary employees generally have a higher base pay than hourly.

Thought 5: Salary systems require integrity to work
In salary situations it is generally stipulated that hours worked in excess of 40 are not paid overtime. Moreover, employers generally require an accounting of time spent which should add up to about 40 hours. But in order for all of this to work, employees have to actually put in their 40 hours and employers have to keep overtime as the exception. In other words, employees shouldn't try to cheat the system and employers shouldn't try take advantage of their workers.

Thought 6: So why would anyone pick one over the other?
Really, that depends on a variety of circumstances. Generally the "choice" is in the choosing of the career. You don't say, I want to do FOO and be paid with structure BAR. Personality has a lot to do with it too. In the past, I've worked a number of hourly jobs. I liked being able to say, "my shift is over, time to go home." I think the pressure of a commission setting would would weigh heavily on me and I wouldn't enjoy it. But now I've been salary for my entire professional career and it's worked out really well because of the cerebral work that I do. Some days I finish a little early and then I don't have to wait for the clock to strike a certain time before heading out. Other days, I get in a thread and I don't even notice that the time is well beyond the average end of the day.