Measuring the Value of Testing

One of the best and most obvious ways to excel in any company is to show how your work is making the company money, or providing value that directly leads to making the company money. The more directly you can show your connection to how much money is being made, the better position you're in. For instance, if you can easily show that the feature you developed, or the feature you designed and brought to market, made the company $X over a time frame of Y years, you're doing well. If you can optimize the function such that X is large and Y is small, you're on a fast track to upper-management.

Showing this sort of result in testing is a much harder proposition. It's easy to say that you tested a feature or product that made $X over a time frame of Y years, but lets be honest here: being the product manager or lead developer and making the same statement definitely carries more weight when attached to a resume. The person generating the idea and the person originally implementing the idea will always be seen as being closer to the end result and positive cash flow than the person ensuring the value of the idea, and ensuring that the mass market can actually use your idea as expected. I'm not saying that this is "the way things should be", I'm just stating it's the way things are.

That being said, here's why I think demonstrating the value you've directly provided to a product is harder for testers: you can't show the diff between what the product would have made had the bugs you found been released to the public. That is an alternate reality we don't have access to; it's an A-B test that can't be run.
If it were possible to conclusively show that the company made $Z more because of the bugs that had been found, I think testing would be taken more seriously across the industry.

Testing in Layers

My old boss and mentor was chatting with me over Facebook recently about a concept that he termed, "testing in layers". It is the basic idea of slowly testing out a new release with people who are close to the code, then providing the release to people a little further away (friends/family/investors), then a little further (active members on your forums), while eventually moving out toward your normal everyday users. This idea struck me because it provided a simple mental model for actions that I think many in the testing community are already doing at a basic level, and provided much room for complexity if need be. It's nice to provide a concept around an existing process, so that it can be better codified and thought out.

In my world, I use this idea in the following context:

• Test internally with engineering (QA)
• Test internally with non-engineering (Marketing, etc)
• Test by releasing to trusted users on our forums
• Test by sending the release to particular people who email into Support, whose problems may be fixed with this release
  
• Test by releasing to everyone on our forums
• Test by releasing to a small number of people who download through the website

One of the issues with this idea is that a feedback loop needs to be in place at each layer. If we should release a build to the forums and don't listen to the complaints and issues that this layer is having, then this testing is pointless. However, the further out you get from the center, the harder it is to get solid feedback. When we release to a small number of people through the website, they probably don't know that they're getting a brand-spanking new release. In this case, how do we get their feedback? As of right now, we simply watch to see if they uninstall, and if the stars align, they might even leave us feedback. It's not perfect, and can use improvement, however so far it's a process that is working adequately to help us determine how the release is doing.

The idea of quality feedback loops for your product will be saved for another blog post. Lets just say that twitter has been proving quite useful in getting product feedback lately.

When has Outlook "Started"?

I have recently had the opportunity to work with a small team to define and run some basic performance tests for Xobni. If you've done some serious performance tests before, I probably don't need to tell you what a peculiar beast performance testing can be. The fun part about this project is that we are measuring areas where are customers are having pain points, and building tools to automate the running of those measurements. On the other side of the coin, creating a consistent and controlled environment where performance measurements can be taken without fear that something external is affecting your measurements keeps me up at nights. No, not literally, but environmental control is one of our biggest problems.

One particular measurement which we've been stuggling with for some time is simply known as "Outlook Startup Time". How do you know when Outlook has fully, really, finally, finished starting? Most importantly, when do our users think that Outlook has really "started"? This is an important question for us: if we're going to improve Outlook startup time with Xobni installed, we have to know what that means. Well here are a few ideas for measuring Outlook startup that we've implemented in a tool of ours:

• When the "Reading Pane" is visible and has text
• When the Xobni sidebar appears AND the Reading Pane is visible
• When the Application.Startup event fires in Outlook
• When Outlook has finished syncing with Exchange
• When you are able to move to the next mail and have it load within a certain period of time
• When the CPU usage drops back to a level on-par with usage before you started Outlook

As you can see, we're measuring a lot and trying to see what sticks. What are your thoughts? When is Outlook usable, by your definition?

A Different Kind of QA: Calling all Engineers

This is a repost of a blog post I made on the Xobni blog. You can read the original post here.


It’s common for people to ask why a good engineer like myself would want to work in QA, especially when you have to fight the stigma’s of QA, namely:

1) You are in QA because you are not good enough for development

2) You are in QA as a stepping stone for development

3) You are in QA because you don’t like coding

My response to those statements: pish-posh. While these statements may apply to some people in the field, they certainly don’t apply to the people serious about QA. A good QA Engineer solves quality problems with an algorithmic intensity that rivals traditional programmers. They are a true hacker in the older sense of the word - they are here to find and exploit the problems in the system in any way possible.

Every problem has its boundaries. For most developers, the boundaries for implementing solutions are usually confined to one language, stack, or technology. The boundaries for problem solving in QA are generally much wider, simply because our solutions don’t have to be productized, exposed to the public, and aren’t necessarily even in the same language or stack.

This allows a much wider range of creative freedom when solving problems. Learning new languages and technologies becomes essential for your work. Having a large arsenal of tools to attack a problem becomes a necessary part of the job. This provides you with even more of a reason to learn about the latest and greatest in tech, which is something that appeals to all engineers alike.

At Xobni we approach QA differently than most. The people we look for are not here because they are not good enough for development. They are not here because they don’t like coding. The QA people here are expected to be at the top of their game. They are expected to build and create software that can topple the Jenga-like building blocks of our product. They are expected to be creative people who like to learn, explore, and exploit software.

That being said, Xobni is looking for a QA engineer! Check out the job post, and send resumes to ryan dot gerard at xobni.com if you think you can rock our world.

Productivity and Flow

I've been thinking a lot recently about that state of mind where you lose track of time, focus intensely, and generally are very productive. This state of mind is not only associated with working; it can be found when exercising, playing games, and other associated focus-intensive activities, but generally I associate it with work, mostly because my best work is done in this state of mind. I find that if I can lose myself for a while and disassociate with reality while working, I generally come out of that state with an amazing amount of work done.

I was thinking recently that if I could induce this state of mind more frequently, I could become a more productive person. After a short amount of googling, I discovered that there is an entire area of research in psychology devoted to this subject; it's known as "flow". One of the main researchers in this field is a Hungarian psychology professor named Mihaly Csikszentmihalyi. He's published a few books on the subject, and the one I picked up is called "Flow: The psychology of optimal experience".

The book itself was a little too self-helpy for my tastes (if you look carefully, you'll see that the subtitle of the book above is "Steps toward enhancing the quality of life"), however I found tidbits inside could have been taken out of any of the software management books I've read.

After skimming through the bits on how and why you desire happiness, I found the core of the book: the elements of flow experiences.


1. Engaging in a Challenging Activity

He explains that the activity you're engaged in has to be at the edge between skill and anxiety. Even if your activity is complex, if you're too familiar with it, it won't be considered "challenging" to your psyche. You have to find something that is within your reach to learn or finish, but isn't easy.

2. Merging of Action and Awareness

Your attention is completely devoted to the activity, such that you have no awareness of the outside world. It is intense concentration, but seems effortless when deeply involved.

3. Clear Goals and Feedback

This is fairly self-explanatory, and it is also where I started seeing parallels in software development and management. On the development side, having small coding goals that are constantly achieved and iterated on is how I think many productive people program. On the management side, providing clear feedback and goals to your employees is a staple of good management.

4. Concentration on the task at hand

This is probably obvious, however what I found interesting was that he believes only a select range of information can be allowed into your awareness when in this state. Irrelevant information in your mental activity can break your concentration, and hence your flow.

Relating this to back to software environments, he goes on to state that quiet environments are essential to keeping your concentration. Much has been written already about how loud environments are productivity killers, and this just provides more evidence to that.

5. The Paradox of Control

He says that the flow experience is strongly associated with a sense of control. This resonates strongly with programming in my experience. One of the psychological benefits of programming (in my non-expert opinion) is the sense of mastery and control one gains over the system you're programming against. "Hacking" (in the Paul Graham sense, not the Kevin Mitnik sense) is merely another way of asserting your control and power over the system, by finding a non-obvious or faster solution to a specific problem. It's a very primal feeling that I think many, if not most of us, desire.

Mihaly then writes that the "paradox" of control "...is that it is not possible to feel a sense of control unless one is willing to give up the safety of protective routines". In essence, your sense of control comes by putting yourself into situations where you actually have less control, since the unknowns are much greater than in situations that you've experienced before. As he writes, "Only when a doubtful outcome is at stake...can a person really know whether they are in control".

6. The Loss of Self-Consciousness

Losing your sense of self-consciousness is a phenomena typically talked about in association with meditation, or zen-like activites. This loss is typically accompanied by, "a feeling of union with the environment". Projected onto programmers, this environment you feel a union with is typically whatever framework, system, or specific program you're working in.

Mihaly explains that what is temporarily lost is not the sense of self, but the concept of the self. High-performing violinists are very aware of their fingers, as runners are aware of their breathing. They haven't lost their sense of self, but the boundaries for how they define the self have temporarily vanished. This can be a very liberating experience, as "...the feeling that the boundaries of our own being have been pushed forward".

7. The Transformation of Time

It is normal to emerge from a flow experience and see that hours have passed without your awareness. What you're measuring when in this activity is not time, but states or milestones. When programming intensely, it's not uncommon to think of your progress not in terms of minutes and hours, but in terms of functions written, functionality working, and pieces integrated. Your world turns into a state-driven world, and not a time-driven one.


For the skeptical types (like me), I want to say that these elements are conclusions drawn from many studies of people experiencing flow in many different types of activities. While this doesn't mean that the conclusions are true, it does have more credibility than just some quack spouting off what he thinks brings about flow experiences.

Hopefully this has provided you with some thought-food to chew on regarding your own productivity. I think the main take-aways from this for me are that to really engage deeply in an activity, one needs:

• A challenging task
• A quiet environment
• Clear Feedback (usually in the form of finished functions and functionality in what I'm writing)
• A clear mind
  
• Enough time set aside to engage deeply with the activity

I said earlier that I found parallels with this book and other software books I've read, and these take-aways prove it. These bullet points could be taken directly out of "Peopleware" or "Managing Humans", or any other book that deals with the topic of software productivity. It's always interesting to find parallels between different disciplines, and I think the psychology of programming to be particularly interesting.

The Great TODO List

Organizing and planning your work is tough. It's not hard to list everything you need to do, but prioritizing what you need to do can be an artform. For instance, do you focus on exploring a problem with the server (which is high-priority to your co-worker), editing a design document (which your boss wants done soon), or finding the root of that newest bug (which is really what I'm getting paid for)? There are definitely subtle tones of politics in these decisions, but I try to keep those matters out of my head when prioritizing.

I was discussing day-to-day planning tactics with some friends yesterday, and we found we all had different methods. I thought I'd share mine with you. I call it the Great TODO List. It's quite simple really. Anyone can start using this method immediately. The low-techness of it is astounding.

Step 1: Open Notepad
Step 2: Write down everything you need to do
Step 3: Put everything you need or want to do today at the top of the list

Amazing, isn't it?

Every day or so I go through the list and roughly prioritize what should be at the top that I may have forgotten about. As I go through the day, when I start to feel like I should be working on something else, I just consult the list, and pop from the top. Yes, the list is a stack.

The one downside to this method is that the list continually grows. I have stuff on my list from a few weeks back that I should still do at some point, but the likelihood of me doing that stuff is getting smaller and smaller by the day. The list needs love and pruning.

Quality and Perception

Well it's a new start for me. I have a new job with Xobni as their Quality Jedi, and it's a nice change. The startup life has been something I've been talking about for a while, and the time for action presented itself in the form of a ripe opportunity.

I've been thinking a lot more about product quality lately, in the general sense. This is probably because product quality will be much more on my shoulders than before, as I'm working with a relatively new product that has already been launched (in the form of a beta). I've been thinking about how one can attribute the status of "high quality" to any product, and I've realized that the only person who can bestow that status is the consumer.

Ultimately, no matter how much a product is tested and sent through the wringers of QA, the consumer is the one who decides whether your product is of high quality. It is the perception of quality that makes something of high quality. Everyone I know who has owned a BMW has moaned a little about how often it has to be taken into the shop for repairs. And yet BMW retains the status that their cars are of high quality, due to the fact that they are "german-engineered".

The perception of quality is powerful, and can directly contribute to product success. The first product put out by Xobni is called "Insight", and is a plug-in for Outlook that gives you a "people-centric" view of email. Email is data that is important to the consumer (vitally important to some), and anything that builds on top of that data must provide value while not corrupting or interfering with the basic tasks (emailing) in any way.

That is the quality challenge with this product, as I see it from a high-level. What is more important than verifying the product functionality is working as expected, is making sure that the consumers current tasks and environments aren't disturbed by the product.

That being said, now the question is, how can we affect the perception of quality to the user? This is a question I'll have to ponder more. The value we're building into Outlook will allow them to accomplish their tasks faster, and more efficiently. I think this increase in efficiency is the key to the quality perception for our product: the users are getting more done by using our product, without having their current email environment disturbed. This may sound quite basic and obvious, but I think it's good to reinforce these base points as to why we're building what we're building.

Interesting times are ahead.

GTAC!

Sorry for the lack of posts -- I've been out of town recently.

I'm currently at the Google Test Automation Conference, at Google's New York office. Thus far, it's been a great experience. There are two things I've learned about (this morning) that I wanted to blog about: how to design a conference, and Google's testing philosophy.

Allen Hutchinson, an engineering manager at Google, gave some good insight into how they designed the conference, and why they made the decisions they did. I pulled lots of good insights from this talk.
*Keep the conference to under 150 people. Sociological research has shown this is an upper bound (and a magic number) that allows a group to keep a sense of community
*Provide outlets for people to discuss the conference. Their high-profile testing blog is open for unmoderated comments on this conference, and a google group was created as well.
*Make the talks available online after the conference
*Try to decrease the amount of repeat speakers from past conferences. They want fresh blood and new ideas introduced in their conference
*Ask old speakers to help select new speakers - or just have people outside your organization help select the speakers

Allen also mentioned that they kept the conference to a single track so that you can see all the talks, but to be honest I rather like the multiple track system. It allows more speakers, and allows you to skip talks that do not interest you.

Pat Copeland, a Director in Google, then spoke about the testing philosophy that Google maintains, which I found quite interesting.

*Measure everything you can. More data allows for more analysis.
*Continuous builds and faster builds allow more time for testing
*Focus on improvement of the system, and not the bits and pieces
*Testing Goal: fully test a product in one day

Pat also mentioned some challenges that they face as an organization, which I think applies to pretty much everyone:
1. Simulating real-world load, scale, and chaos is difficult
2. Deciding what to measure is difficult
3. Complex failure scenarios are expensive to test

The talks (and more importantly, the people) have been quite interesting thus far. I'll hopefully have more to update after tomorrow.

My Favorite Laws of Software Development

There was a great blog on the Laws of Software Development, and there were a few I saw as related to testing that I thought I should share.

Brooks' Law: Adding manpower to a late software project makes it later. Or testers, in this case.

Conway's Law: Any piece of software reflects the organizational structure that produced it. Good to keep in mind when testing.

Heisenbug Uncertainty Principle: Most production software bugs are soft: they go away when you look at them.

Hoare's Law of Large Programs: Inside every large problem is a small problem struggling to get out. Finding those small problems is worth searching for.

Lister's Law: People under time pressure don’t think faster. Or test faster.

Nathan's First Law: Software is a gas; it expands to fill its container.

Scalable Test Selection

A few weeks ago I gave a presentation at the Google Scalability Conference on the idea of Scalable Test Selection (video can be found here). Now that the video is up, I thought I'd share with you all this idea developed within my team. I must preface this by saying that this was not my idea -- the credit belongs to Amit and Fiona.

As Cem Kaner has said before me, there is never enough time to do all the testing. Time, in essence, is your scarce resource that must be allocated intelligently. There are many test strategies one can choose from when testing a product, however the question must be raised: how do you know whether you're testing the right things, given the amount of time you have to test? This is an impossible question to answer, however there are situations where the question is pertinent. For instance: when a change is introduced to your product at the last minute before release, and you have to decide what to test, how do you choose? There are probably some intelligent guesses you can make on what to test based on what has changed, but how can you know that this change hasn't broken a distant dependency?

This is the situation where we believe Scalable Test Selection can help. Given a source code change, what test cases are associated with that source code? Essentially, how can we link test cases to source code using test artifacts?

We have identified (and presented on) three ways to associate test cases with source code:

• Requirements: If source code is checked in to satisfy requirements, and test cases are checked in to satisfy requirements, then a connection can be made.
• Defects: A test case fails, which then is associated with a new defect. When source code is checked in to fix that defect, an association is made between the code and the test case
• Build Correlation: For a single build, you can associate a set of source code changes with a set of test case failures. Now iterate that over successive builds, and you have a large set of source code and test case associations

With all this data that you can use to associate source code to test cases, when future source code changes are checked in, a tool can be written that can find all the test cases that are associated with that source code. In the case that you're in a time-crunched situation, you can have another source that suggests what test cases you should run in your limited amount of time.

What we're doing is applying simple data-mining techniques to the test data. There is much more to the idea that I'm not talking about (prioritization of test cases, implementation ideas, etc), however I hope you get the jist. I fully recommend you watch the video if this topic interests you, and feel free to email me if you want the slides :).

CAST Conference

I just finished Day 1 of the AST Conference (CAST), and boy did I have a good time. The talks were good, but the people were better. There was definitely a general feeling of community there, which is something I haven't seen much at conferences I've been to lately. The crowd was relatively small (~180), but all good people.

Highlights for me:
* Hearing Lee Copeland talk about the role of QA as a services group (this makes almost too much sense to me)
* Talking to Jon Bach about the future of AST, CAST, and the other conferences that AST is hosting
* Watching a small group gather after my talk on Meta-Frameworks to share their experience with Meta-Frameworks

Anyway, now that I'm leaving tomorrow, I wish I was staying another day.

The Time Trade-Off

I started prepping for the CAST conference next week by reading up on some test patterns that the AST group has produced in the past. I was reading some great stuff this weekend by Cem Kaner on Scenario Testing, when I came across a fantastic quote:

"The fundamental challenge of all software testing is the time tradeoff. There is never enough time to do all of the testing, test planning, test documentation, test result reporting, and other test-related work that you rationally want to do. Any minute you spend on one task is a minute that cannot be spent on the other tasks. Once a program has become reasonably stable, you have the potential to put it through complex, challenging tests. It can take a lot of time to learn enough about the customers, the environment, the risks, the subject matter of the program, etc. in order to write truly challenging and informative tests."

It's so true, it's painful. Deciding on what to test is becoming increasingly important in my own work, as the amount of work stacks up, and the amount of time to test it decreases. It's an interesting balancing act.

An interesting bug in Java binarySearch

Josh Bloch, author of Effective Java Programming and one of the best in the biz, blogged last summer about an error in his own implementation of binary search within Sun's JDK. It turns out that the most straightforward implementation admits a flaw so subtle that the version in java.util.Arrays, in particular, lay dormant for almost a decade. It is one of the most interesting bugs I have seen in a long time, and in fact I didn't notice it myself. Simplified slightly from the original:

// locate an index of key k in sorted array a[], 
// or if k is not present, return -1
int binarySearch( int[] a, int k ){
  int i = 0;
  int j = a.length - 1;
    
  while( i <= j ){
    int m = (i + j) / 2;

    if( k < a[m] ){         // left half
      j = m - 1;

    } else if( a[m] < k ){  // right half
      i = m + 1;

    } else {                // found
      return m;
    }

  }
  return -1;                // not present
}

The culprit is sly: Operating on a large enough array, computing m = (i+j)/2 is subject to integer overflow, becoming negative due to wraparound, e.g.

  int M = 0x7fffffff;         // 2^31 - 1
  int[] a = new int[ M ];
  a[ M - 1 ] = 1;

  // the call...
  int r = binarySearch( a, 1 ); 
  // ...throws an ArrayIndexOutOfBoundsException !

Fortunately the midpoint can be computed safely via m = i + (j-i)/2. Already there are many blog posts on this blemish, but none concerning quality. What might a software engineer learn about testing from this long-hidden oversight?

1. A lesson from numerical analysis, that time-honored formulas aren't necessarily robust when copied to finite arithmetic.

2. Vary your test data. Surely the Sun test battery for binarySearch passed, again and again, on the same sets of arrays and keys. Fine for 9 years -- but static lists of tests become stale. Which arrays should we select, or search for? Read on...

3. Specialized conditions are required to pinpoint rare defects. This flaw cannot be exposed for sizes below 2^30, about 1 billion; no wonder nobody noticed. The truth is that the endpoints of anything almost always provide interesting insights. Here, searching far to the left always passes, and only searching far enough to the right can throw the Exception. Aha. This leads to a favorite maxim...

4. Design tests specific to the implementation. The greatest of the Java int primitives is M -- nothing to do with binary search -- instead, a boundary in the language itself! Therefore, an array of that length makes a worthwhile test case in Java (cf. Mathematica, Python). Something to remember when writing your own test suites.

Professor Kahan at Berkeley once summed up his lessons about testing (from the infamous Pentium divide glitch) into a fitting quote:

Seek singularities!  There lie all the errors.

Wisely put, as are Josh's remarks about programming defensively, vigilance, code reviews, static analysis, solid proofs, and formal verification. (I would disagree with his view that there will always be bugs, but opposing formidable Dr. Bloch isn't really something one ought to do).

The paradox is that although testing can't exterminate our errors, it still needs to be done to provide corroborative evidence of correctness, even for well-proved algorithms! Later, I'll augment this post with test strategies which might have exposed the flaw. With test methods in mind, we might be able to expose ever more errors, and add to our QA repertoire.

An exercise: Using 32-bit two's compliment integer arithmetic, compute the average of i and j, correctly rounding to even. Test it with i and j at the extremes. My solution is not short.

Ubuntu: A Fresh Perspective

I decided to replace the Fedora core 4 machine I had at home with the bizarrely named "Feisty Fawn" version (7.04) of Ubuntu, which has gotten oh so much attention as of late. Having never installed Ubuntu, I wanted to know what the big deal was.

There was only one disk to burn. That was a nice surprise. I started booting, and found that the CD I burned was actually a Live CD. It booted me right into Ubuntu. Naturally, I didn't read much about installing the distro, so I surmised for a minute that perhaps Ubuntu was just a Live CD. Not so -- after I actually looked at the items on the desktop, I found a single "Install" icon. Clicking this proceeded with the install of Ubuntu on my local hard drive.

The distro has so far proved to be very usable. There is an "Add/Remove Applications" feature which is remarkably like the "Add/Remove Programs" feature in Windows. That is very useful for users who grew up in a Windows world. My one complaint thus far is that I can't login as the root user. I'm sure that if I look around the net enough I can find a way around that :).

Concurrent Programming: The Next Best Thing

I was one of the lucky few to attend the Google Developer Day in San Jose last week. It was quite interesting. One of the best talks I went to concerned the Google backend infrastructure. One of the topics they've worked on extensively is storing and organizing massive amounts of information. This probably isn't a surprise to anyone, but it highlighted to me the coming importance of concurrent programming.

For a short one-line introduction to the subject: concurrent programming concerns the simultaneous execution of multiple interacting computational tasks. O'Reilly recently pointed out that as the processor speeds remain stable, but the number of processors inside a computer continue to increase. In 5-10 years, having a computer with 50-100 processors will probably not be unusual. The real question is: how do you take advantage of all those processors?

I think many consumers assume that all these extra processors in their computers are being leveraged. I would say they are most likely assuming incorrectly, or at least, they are being leveraged inefficiently. Concurrent programming languages (such as Haskell) allow multiple processors to execute tasks simultaneously, and coordinate tasks between them. Now that's some sexy programming.

It can also make good financial sense to move into this area of programming. In O'Reilly's article, "The Faint Signals of Concurrency", utilizing an 8 CPU machine for processing data is much cheaper than buying a cluster of 8 machines for processing data.

Haskell is already a "hip" programming language (stop laughing). Among nerds, it is the cool language that wears its sunglasses at night, listens to jazz, and can recite quotes from famous philosophers. I would say that this is a bleeding edge language, and really needs more investigation by me.

User Expectations

Bill Higgins has recently written a fantastic post titled, "The Uncanny Valley of User Interface Design". He discusses how people have a basic mental model of how things should appear, and when they differ from that mental model, we reject them.

He has a great example of this concerning the lack of an explosion of Java GUI apps:

"My own experience with using Java GUI apps of the late 1990s was that they were slow and they looked and behaved weirdly vs. standard Windows (or Mac or Linux) applications. That’s because they weren’t true Windows/Mac/Linux apps. They were Java Swing apps which emulated Windows/Mac/Linux apps. Despite the herculean efforts of the Swing designers and implementers, they couldn’t escape the Uncanny Valley of emulated user interfaces."

He's definitely on to something. This got me thinking about user expectations, and how yet another thing a pursuer of quality must keep in mind is this difficult to quantity quality. The sort of je ne sais quoi of a web or desktop app that maybe meets all requirements, but just doesn't feel right. Sorry, was that french phrase a bit too pretentious? I couldn't find a better phrase to use. It had a sort of je ne sais quoi about it.

High Performance MySQL

Databases have recently become interesting to me. Previously, they've always seemed like these massive beasts that provide such simple and basic functionality, I didn't understand how companies such as Oracle could make billions selling databases. Yes, it was a dirty word in my vocabularly. And yes, I'm now a reborn DBA in training.

Recently I've been working on a small PHP project reporting statistics on some data from our network. The small project has been collecting for some time now, and has begun to attract some attention. It's also started to slow down considerably. I read a few MySQL performance articles and blog entries, which had quite a few tips and tricks, but in reality I was adding indicies and making config changes without really knowing how to measure the performance differences, or how the change was really affecting my web app. It was blind performance tuning.

And then I picked up "High Performance MySQL". This book is changing my life one page at a time. I've noticed that most of the articles and blogs around MySQL on the web (at least, the ones I could find) were centered around the basic stuff: installation, basic configuration, and cookbook recipes. This book goes to the next level and answers many questions that I've previously had, but didn't have an aggregated place to find.

The key to that last statement is aggregated. I'm sure there are articles out there that explain the differences between InnoDB, and MyISAM, various ways to benchmark your queries to measure performance differences, or methods to cache your queries to improve performance, but having them all aggregated in one place provides context that has proved valuable.

If you're looking for the next level of intelligence on using MySQL in real-world environments, this book is highly recommended.

Testing Old Versions of IE in Linux

As much as I wish people would move off their old versions of IE and Firefox as fast as possible, it's rather hard to induce this. Microsoft has tried hard to move people to IE7 by making it a Windows Update. However, the simple truth is that when developing web sites, you must support many different browsers, including those old, terrible versions that you wished had never been released.

There is a small problem with this: finding these older versions of IE is rather difficult. Oh they are out there somewhere, but it's not easy and obvious. I usually resort to downloading some version of IE 5.5 off of a sketchy website, and then proceed to do multiple AV scans of the file I've downloaded.

And what should come to the rescue...Linux, naturally! I recently found a project called IEs4Linux that installs IE 5, 5.5, and 6 off of Wine. It's meant to be used for web designers to test site compatibility in older IE versions. Personally, it will be useful for my own web testing -- and now I don't have to use Windows to test IE anymore.

Apple Rising

Paul Graham, that most prolific of writers for any tech geek, recently posted an interesting article titled "Microsoft is Dead". I think the title was for dramatic effect, as what he means is that Microsoft is dead in the same way IBM is dead, i.e., not innovative or interesting anymore. I believe he's right, for the most part.

One of the reasons he touted as a sure sign of Microsoft's death piqued my interest:

"Nearly all the people we fund at Y Combinator use Apple laptops. It was the same in the audience at startup school. All the computer people use Macs now. Windows is for grandmas, like Macs used to be in the 90s."

Without a doubt, Apple is rising. It's something I've discussed with friends, and spent time trying to decipher. At any tech conference I go to, there are tons of people with Macs. Whenever I visit the Google campus, there are macs all over the place.

What does this mean? Why are people moving to Apple, rather than installing Linux on their laptops with cheaper commodity hardware? There are a myriad of small reasons that I can come up with, but there is no denying the trend. Or fad. I'm not sure which it is.

A good quote to be reminded of

A recently came across a Peter Drucker quote that struck me as very true.

"Growth that increases productivity is healthy, growth without an increase in productivity is fat, and growth that decreases productivity is cancer...."

I think it's often easy to forget that, in software at least, output is king. If what you're doing doesn't contribute to output or productivity, you may want to rethink what you're doing.