SquidgeyFlint's Blog

Learn from your QA staff

2008-09-13T13:37:00.001-07:00

In modern times, it is common practice for developers to write unit tests with their code. This is a great thing. But developers aren't practiced at writing tests, nor do they have that base knowledge that your QA team would have.

Why not start learning from your QA team and getting them to share their subject matter expertise? Your QA folks have many years of experience in how to find bugs in software.

Just for fun (to prove this to yourself), the next time you bump into one of your testers in the hallway, ask them to list the standard / rule-of-thumb use-cases for boundary condition testing. I bet they come up with a few you didn't think about. They know a lot of cool stuff like that, stuff that you need to know to write effective unit tests.

There is a lot of good that comes from this.

The developers will start writing better unit tests. That means they find more of their own bugs, the ones that are easy for QA to find. This reduces cycle time and makes better use of the QA folks time.

The test team will feel good and valuable and loved because you are highlighting the fact that they have knowledge to share and you want to learn from them. This is not only a morale boost, but a culture shift as well.

Having more interaction between the test team and the dev team, outside of the "your app sucks" and "why didn't you find this bug" meetings, will enhance that relationship making for better and smoother interactions on projects which makes for better delivered product.

Don't give your crap to your testers

2008-09-13T13:28:00.001-07:00

If you're a developer with any kind of honor or pride what-so-ever, your goal is to have no bugs. And while all software has bugs, the bugs in your code that QA does find, should be so arcane and edge case-y, that they everyone is impressed that those bugs were able to be found.

Said differently, let's say you drop your car off at your favorite shop for a tune-up. How would you feel if your car won't start when you go to pick it up, as if the tune- up had made your car worse and the mechanics didn't notice?

You'd be the indignant kind of mad. You'd think that those mechanics had no sense of pride in their work and didn't care about you the customer.

So how do you think it reflects on you when you give something to QA and in the first 5 minutes, running through the basic smoke tests, the app fails? Do you like like looking like a dolt? Don't you want to be able to find the bugs in your code before they do? Sure you do, because you have pride in your work.

Test your stuff before you give it over to QA. Don't waste their time and yours by giving them stuff that fails on the easy tests. Test their mettle. Make them stretch to find the good bugs because you've already squashed the easy ones.

Not me, not me

2008-09-08T21:46:00.001-07:00

I heard from a few friends of mine, that I'm wrong about software owners choosing to ship untested software and I thought I'd drop a quick note about that.

Does QA actually release the software themselves when they feel it is ready?

If not, then whomever owns the software and decides to ship is overriding the QA group.

It happens when QA's schedule is nickel and dime'd up front. When the QA schedule at the end of the project is compressed because dev teams slipped. When the software is released with known bugs. When the QA team isn't given an equal voice and influence at the triage table. When time for building automated test suites is cut.

The only time QA is really in control is when they have total go/no-go authority _AND_ they aren't being pressured by one manager up who is vested in the date.

Mind you, I don't think the QA group should be given total go/no-go authority. That is a business decision that needs to take a lot of factors into account. I wish I could say that it was only about "quality" but it isn't. Besides, what is "quality" anyway and who's requirements define the quality of the software product? Is the QA team incented to follow the business goals (which always include quality) or to let no bugs get to production? The two are very different.

I just bring this up because the conversation gets easier when we own up. You own the software, you decide when to release. If you can accept this fact it clears up a lot of other confusing issues.

I own the software and am responsible for it working or not working.

I own the test rigs and test environments since those things are critical to my knowing that my software is going to work. Just as I use testing to verify the work of the developers, I use the developers to verify the work of QA. I leverage the QA team to develop some components of that test system along with my dev team but I am still responsible for the test team's output even though they report up through a different chain. They are essentially loaned to me as part of my team for their expertise. All of the test environment code is reviewed by someone from the dev team as we may have to modify it, fix it, extend it while they are doing other important work, just like inside the dev team.

If you can own-up to this state of mind, your interactions with your QA team _will_ change as now you are working together on your own thing -- the thing that you have vested interest in.

Who does what? (pt 1)

2008-09-08T19:23:00.001-07:00

Up until this year, our QA "team" owned and operated the test environments. We've been running the same general software stack for about 5 years so large portions of the QA space were also 5 years old and had been maintained by 3 different SDET's over time. This year we had a pretty big storm in the form of:

a new SDET, new to the company and our team.
a whole lot of software being written and ready to test all at once,
a large scale host lease return / migration effort all happening.
a lot of "hard-coded", by-hand local changes in temporary files in our QA maintained regression environments.

That last part was the real killer because as the hosts were swapped, the regression environments stopped working and the new SDET didn't really know how they worked enough to fix them. Meanwhile, we couldn't test the gobs and gobs of software and a number of projects were poised to start slipping day for day waiting on our singular new QA resource to migrate hosts and fix the regression environments.

As SDE's were starting to idle, we had a few options:

Shelve the new software and move on to other new software while waiting on QA.
Build the new test environments for the new software ourselves.
Help QA fix the broken environments.

We chose both to have SDE's pitch in to help fix the broken environments as well as start building the new automated test environments for the new software just written. This was a real eye opener and not in a good way.

We found a lot of stuff that is considered poor Software Development; like full test harnesses cut-and-paste cloned six times to lots of stuff that wasn't checked in like code and config.

The SDET's who had been serially writing and maintaining our test environments over time had some strikes against them:

They didn't get to spend much time writing software and as such their software development skills atrophied.
They didn't religiously check in code and get code reviews (this is Amazon policy for SDE's).
They didn't allot time in their estimates to do these things.
They considered the work complete without these tasks being done.

All of these "transgressions" are the exact same ones that less experienced software teams make and it was sad to see this when the QA team was surrounded by SDE's who weren't allowed those oversights.

At the end of our intervention we had fully deployable regression environments that the SDE's understood and could extend. Subsequent host migrations were trivial and the SDE's started down a path to centralize, leverage, and extend the automated test rigs producing some really interesting improvements in test case generation and execution.

There was an additional feature add here: once the SDE's saw first hand how hard their software was to automate, they went back and changed the software to be more easily testable. In one recent example, by changing an app to take a file of inputs for testing, instead of feeding those inputs through another team's test domain publishing software, they were able to get the test runs down from 6 hours to 20 minutes AND allowed all the SDE's to run their own mini-stack simultaneously. That was a huge win and a big lesson.

The first moral of this story is that we should have been holding the SDET's up to the same standards as we held ourselves. They were building stuff that would ensure our software was good, yet we didn't code review that work nor make sure it was checked in, as we would if we were borrowing developers from other teams. We should have considered the test environments to be ours as well, even if we didn't build them nor extend them.

(continued)

Use QA wisely

2008-09-08T18:44:00.001-07:00

I've heard stories that some groups in Microsoft have a Dev to QA ratio of 1:2 (that's 2 QA for every Dev). On my team at Amazon that ratio is more like 7:1. (7 Dev for 1 QA). 7 SDE's can write a lot more software than 1 SDET can test and as such we have to prioritize quite a bit to make the best use of our SDET's time.

For a while our QA traditionally spent a lot of time running regression tests. Mind you, our software doesn't have a UI so the tests are all about setting state, applying data to the application, and verifying state.

That wasn't such a good use of time. Computers are really good at monotonous repetitive tasks and tying up QA manually running regression tests was an egregious waste.

The first step was to automate the regression tests so that QA could kick them off and then work on other stuff. The next step was to fully automate the regression suite so that it could be run by anyone, not just QA -- like the Dev team. The third step was to simplify the machinery of the regression suite so that each developer could run it locally, as part of their development effort.

At this point, the SDE's are able to drop software into the regression suite before they even check it in!!! New test cases to go along with the new features are added to the automated test suite along with development, as a way to test the software being built, as it is being built. The automate test suite can then easily be run after the code is merged to mainline, and then again after we merge the code up to the release branch. Our QA never has to get involved in this cycle which is great because there are more valuable places for them to contribute.

QA now has a lot more time to bring their expertise to bear: finding mean and devious ways to break the software and expose the bugs.

The other benefit is that when the automated tests are easy to run, the developers will run them all the time and catch the easy bugs before QA gets a turn. That further reduces cycle time and raises the bar on the QA team to find the really good bugs.

Your QA team is your friend

2008-09-03T23:42:00.001-07:00

At Amazon we work in the total ownership model. Each team is fully responsible for the software and services we write. We own, develop, maintain, and operate.

I like this model for a number of reasons but when it comes to QA it makes the situation very clear. The software is mine and I am responsible for shipping quality software that is not only good, but also doesn't page me in the middle of the night.

The software runs better in production when it has been well tested. Testing has to be done before the software ships. That is work that has to be done. Facets of that work are better done by folks classically trained in QA. Other parts of that work are better achieved by software engineers. Regardless of who gets the work done, it has to be done, and done well.

If your QA group is competent then they will find plenty of bugs if you give them tools and time. The more useful tools and API you give them, the more bugs they will find in less time. If you don't want to give them enough time to do their job then you get what you paid for, just like when you compress a software engineer's schedule so much that you get some clunky rickety thing that barely works.

In the Amazon model, if I ship bad software then _I_ shipped bad software. QA doesn't ship bad software because they don't ship software. They advise me on the state of my software. Sometimes, time to market pressure requires software to be released with known non-critical flaws that will be fixed in a follow up release. Most times, the date is slipped and the bugs are fixed.

In the case where QA gives the software is given the green light and then fails terribly in Production, you have really clear and specific things to discuss with the QA team and clear and specific opportunities to adjust the process on the next iteration -- which is usually pretty soon given that you have to fix all the bugs you just launched with.

(more on this soon)

Goodby Stylus PDA/Phones

2008-08-10T18:44:00.001-07:00

I got a Blackberry a few months ago for work. Amazon supports the enterprise server and besides getting my work email and calendaring, memos, and full outlook integration, I can also surf the company intranet and use a variety of web-based tools to keep monitor things and understand issues as they are developing. This is very very cool.

I've also started using the blackberry for other things, like shopping lists. It's nicer than pen & paper because as I pick up things, I delete them from my list and it gets shorter. That's much easier to see what is left plus it makes me feel good to have my list get shorter.

What dawned on me today while adding some things to the list after talking to my wife was that I was able to add those things one-handed. I didn't need to break out some stylus to tappity-tap the additions to the list.

The iPhone has a touch screen but it is configured for fingers -- no stylus. Blackberry has a full keyboard and the great trackball -- no stylus. Palm -- the PDA of yesterday -- stylus. Windows mobile phones? Stylus. Blackberry's next big release? Touchscreen ala iPhone. iPhone's next rumored big release? Full keyboard ala Blackberry. The top two convergence phones don't use the stylus.

Nintendo DS uses a style and is well received for it. In fact, I do my best to only buy games for the DS that use the style because it makes gaming so much better. My HP laptop is a convertible touch pad device and the touch-screen / pen is really nice for certain things.

Both of those uses are things that require your full attention and you expect to have to use both your hands. Your Phone / PDA is really an accessory. You use that briefly while doing other things. It is not expected to always be an all enveloping experience and along with that, you don't expect to need two hands to use it.

On Software QA

2008-06-19T07:23:00.001-07:00

Between transitioning to a new QA person at work (again!) and having a lot more software needing QA than QA time available, I've been taking a much closer look at our QA, the automated test environments they've been using, and doing a _lot_ of thinking about what that function should be and how it can be best served.

While I'll be writing a bit out this over time as my thoughts coagulate a little more, I happed to come across this article ( "A Bit Bugged About Lack of QA Respect" ) about Videogame QA which is interesting to see given that the Videogame QA folks are generally maligned for letting bugs through.

Windows Live Writer

2008-06-03T21:02:00.001-07:00

Windows Live Writer is part of the Windows Live set of services and is basically a local app that will post to your blog for you. At first glance the value seems to be the ability to save local drafts. The editing options are a little better in that you aren't stuck in some Javascript WYSIWIG editing block.

Also interesting is that if you have multiple blogs, like say this one and the family one, you can easily switch back and forth between the two which is kinda nice.

You can also edit recent posts that you've made via Windows Live Writer along with managing your blog settings. What is a bit strange is that while you can manage blog settings, and if you edit a recent post, it will go get the actual post from the blog, it doesn't give you a way to edit posts that you didn't make from the tool.

Something else that it should do for a real value add is give you the option to search from the tool to get a URL to hot-link. Instead of my having to go look up the URL for Windows Live, I should've been able to highlight "Windows Live" and pick an option to do a web search to find the URL for a hot-link. That would provide extra value with the power of a desktop app.

On the whole this little app seems like a nice addition.

Rumbullion is a band that

2008-04-08T11:54:00.001-07:00

Rumbullion is a band that we saw while having lunch in austin.

Overheard in an elevator

2007-12-23T17:08:00.000-08:00

A woman's cell phone conversation overheard in an elevator:
"No, you won't see me tomorrow.. I'm out for two weeks vacation."...
"I'm heading home to get drunk!!!"
(Chorus of hooting from the rest of the elevator)
"I think the people in the elevator like that idea"
"No I'm not going to be drunk for the whole two weeks!!!!"
"No..."
"I'm not"

Then the doors opened and we all went our separate ways.

Quotable Quotes

2007-11-03T19:09:00.001-07:00

The large print giveth and the small print taketh away

This week was the first time I heard this and I dig it. It's probably pretty common but it was new to me.

Jesus built my hotrod...

2007-10-26T19:17:00.001-07:00

Jesus built my hotrod by Ministry is basically a rock and roll version of the hamster dance.

The Right Way

2007-10-23T22:20:00.000-07:00

My Dad always said that there's no point doing something if you're not going to do it the "Right Way" (tm).

What life has taught me is that the "Right Way" is frequently not the right way and that "Good Enough" is usually good enough. The thing about doing something the "Right Way" is that the "right-ness" depends on what you are doing. If you're reroofing your house or you're redoing your bathroom, you do it "the right way" because getting it wrong will be very painful and expensive and the risk is very high. If you're putting down some paving blocks in your backyard to make a little patio, "Good Enough" is good enough.

There's an old view of the Software Engineer sitting high upon his ivory tower writing software the "Right Way" and if the users aren't smart enough to understand how to use, then they shouldn't be allowed to use it. I still come across this frame of mind from time to time and not only is it almost always patently wrong, it is tremendously frustating because the purveyor of said "right-ness" can't understand why you can understand and gets supremely frustrated at your lack of understanding.

Feh.

At Amazon we need to move fast; be nimble and quick. In fact a recuring trend in the software development world is fast iteration. You rarely get it right the first time, so it's better to take a couple of passes at the problem, learning from mistakes along the way. It's the old joke about Microsoft taking 3 releases of any product to get it "good". The first launch gets it out the door. The second launch makes it usuable and actually gains some marketshare. The third launch is where it gets better than sliced bread.

The trick to being nimble and being able to keep operational overhead down is to walk the line between speed and quality. If try to you build the super bullet proof ivory tower system, not only is it unlikely that your 3 year project will ever launch, but it will be pretty impossible to change and bend with changing times and changing requirements. You'll build in big, hard to fix bugs early on. Building enough to get you through the next 2-3 years nets you a lighter, simpler system that is easier to iterate. And in all those fast ierations, you have many more chances to find and fix bugs. It's not "the Right Way" but the better way. :->

Happy things

2007-10-12T17:12:00.001-07:00

One of the things that always brings a smile to my face is seeing a toddler happily running for mommy.

Giant spider collects children

2007-10-06T17:42:00.001-07:00

When I was a kid we didn't have cool stuff like this.

Galatic Conquest

2007-09-30T11:58:00.000-07:00

Ogame.org is a web-based resource management strategy game. You start off with a few resources in your pocket, enough to build a Solar Engery Plant and a Metal mine and you are off and running.

You can work your way up to building spaceships of all sorts, planetary defense shields, missles, espianage probes. You can attack planets and steal resources. It's real-time but generally slow as you ramp up your empire. It doesn't require a lot of attention and can be fun if you like the idea of "leveling up".

Coffee

2007-09-30T11:50:00.000-07:00

Even bad coffee is better than no coffee at all.

If this statement isn't true than you haven't fully embraced your caffeine addiction.

http://www.hopkinsmedicine.org/Press_releases/2004/09_29_04.html
If you missed your morning coffee and now you have a headache and difficulty concentrating, you might be able to blame it on caffeine withdrawal. In general, the more caffeine consumed, the more severe withdrawal symptoms are likely to be, but as little as one standard cup of coffee a day can produce caffeine addiction, according to a Johns Hopkins study that reviewed over 170 years of caffeine withdrawal research.
The researchers identified five clusters of common withdrawal symptoms: headache; fatigue or drowsiness; dysphoric mood including depression and irritability; difficulty concentrating; and flu-like symptoms of nausea, vomiting and muscle pain or stiffness. In experimental studies, 50 percent of people experienced headache and 13 percent had clinically significant distress or functional impairment -- for example, severe headache and other symptoms incompatible with working. Typically, onset of symptoms occurred 12 to 24 hours after stopping caffeine, with peak intensity between one and two days, and for a duration of two to nine days. In general, the incidence or severity of symptoms increased with increases in daily dose, but abstinence from doses as low as 100 milligrams per day, or about one small cup of coffee, also produced symptoms.
The research also showed that avoidance of caffeine withdrawal symptoms motivates regular use of caffeine. For example, the satisfying feelings and perceived benefits that many coffee users experience from their morning coffee appear to be a simple reversal of the negative effects of caffeine withdrawal after overnight abstinence.

Upsell / Cross-sell

2007-09-11T23:03:00.000-07:00

I need to change the oil in the Pathfinder and I happened to be near a Jiffy Lube so I stopped in. They are the kings of the Up-sell / Cross-sell.

First you pull your car up in back and then go inside to wait. Then a few minutes later they call you out to talk to you about what services you want. I just wanted a simple oil change.
Synthetic? (3 different kinds of synthetic to choose from)? Nope. Regular.
Which regular (2 different kinds of regular oil)?
Air filter? Fuel Filter? Transmission fluid? Transfer case fluid? Differential fluid? No, no, no, no, really, I just want my oil changed, nothing else, no, no, no, just an oil change, really.

At this point the guy apologized and said that he had to ask all those questions. Poor dude.

I go back and sit down for a few more minutes and then some guy in "Auto Glass network" coveralls comes to get me. He shows me a few dings in the windshield and asks me if I want to replace my winshield while they change my oil. No, I just want an oil change. Really? Your insurance will cover it 100% (how does he know that?) and we can do it in the time it takes to change your oil. (no they can't. They don't even have my winshield there and it takes more than 20 minutes.)

I felt like I was running a gauntlet in old school movie where the very caucasian hero wanders through some third world market surrounded by salesman. Yikes.

Cost of Operations

2007-08-04T10:52:00.000-07:00

For a lot of companies, cost reduction is a focus in profitability. For retail merchandisers, cost reduction is a major focus, because while there isn't much control over the per unit margin, there is a lot of control over how much is spent to sell the product.

Online retailers, like Amzaon, are really part software company. We build, deploy, and operate a lot of software. Since we're a 24x7 retail website, every minute that customers can't find and buy product is lost revenue. That means we have a lot of energy applied to ensuring that the website is running in top form all the time.

When cutting costs, there are a number of different avenues to focus on. When I worked for Aetna, pencils were metered and carefully handed out. At one company I have worked for, Ibuprophen was removed for a while from the first-aid stations as a cost-saving measure. Pencils and Ibuprophen don't move the needle. Staff reduction does move the needle. Unfortunately, after you layoff your workforce, your ability to do much of anything is supremely hindered. You may be able to keep your operation running, but forget innovation.

Instead of cutting staff, a better focus would be to focus hard on reducing operational cost and generally increasing productivity. We've been focusing a lot on reducing the cost of operations at Amazon and the result is that we have more developers spending time on developing (and golly, the stock price is up too, go figure). If you consider developers as fixed costs and their value add is new stuff, by increasing the amount of time they have to work on new stuff, you increase their efficiency. By reducing operational cost you get more value from your staff.

What's hard about reducing operational cost is that you usually have to dedicate a good chunk of said staff to that task. By doing that you don't build new features with those folks. So you are basically taking a hit up front to get your house in order. While it can be a bitter bill to swallow -- that you let yourself get so far gone -- the net results are marvelous.

Software developers tend to feel a sense of ownership for their software and services and nobody likes owning some custy, junky, crappy software that always dies and just generally "sucks"! Nobody! Having a smooth running system that doesn't wake people in the middle of the night and handles your peak transactional volume well is something to be proud of and makes you feel good about your job. When your developers are feeling good about their jobs, they tend to germinate ideas at a higher rate and the ideas tend to be better as well. And then... then... since the developers are busy spending all their time fighting fires, they actually have time to explore these cool new features which makes the website that much better.

Reducing operational cost is not something you can usually do in a month or three. It requires a long term commitment AND it requires a culture shift to build software in an operational friendly form -- which also makes it take a little longer to build. The value there is that you spend the extra time in software, up-front, once vs the death of a thousand cuts as you spend countless hours over time dealing with software that is hard to manage.

Spend a little now or spend a lot later.

Technology

2007-07-21T11:08:00.001-07:00

It dawned on me the other day that keys are on the way out. Car keys. House keys. No more keys on your keyring.

It's been progressive and started with cars. First an (assumedly) RFID chip was embedded in car keys to prevent popping out the locking mechanism. The car won't actually start -- it will crank but not start -- without that RFID chip in close vicinity.

This has been taken a step further on a number of high end vehicles such as Corvette, Mercedes, Lexus, Infinity, and Porsche. All you need is to have the RFID chip in your pocket and the car will start. No keys in the ignition. Just a push button starter. It's only a matter of time now for this to make its way down to the mid-priced and then the rest of the car market.

This is very cool by the way. Not having to fish keys out of your pocket when you are jumping into your car with hands full on a rainy day (not that it ever rains in Seattle). Not having to have keys in your pocket at all. As an aside, my wife's new Subaru Outback has the biggest key I have ever seen and then it still has a great big keyfob remote attached. There is no way I have room for that in my pocket.

The other thing that will happen over time is that the keyfobs themselves will get smaller too. For those of you who dig the idea of embedded chips in your skin that you can wave around to make stuff happen, that'd be just as possible for your ride but you'll always need some kind of remote control available for remote lock.

What will be really exciting is when those RFID "keys" will be general enough to be used for more stuff that just your car -- like your house.

Kids and Sticks

2007-06-25T23:26:00.001-07:00

IMG_0878
Originally uploaded by SquidgeyFlint

We went to an appreciation picnic this past weekend for my boy's second grade teacher. Even knowing how much kids like sticks, we parents were surprized when we saw them drag this branch out of the bushes. Normally I'd be worried about this but the branch was heavy enough that they needed at least 4 kids to carry the thing. They were so slow with it that they couldn't chase anybody down. They tried of course but were too slow and uncoordinated. Once they figured out how how to up-end the thing -- like a flagpole -- then we had to intervene. That would hurt, getting squished by that big branch falling down.

Technology

2007-06-24T10:20:00.000-07:00

Cell phones are technolgoy that we take for granted. Yet 15 years ago they were still very expensive and rare. Once the prices came down on both the hardware and the service, the super-fast adoption rate is a key indicator of the chell phone's "just right" technology. In case you remember what cell phones used to look like, here's a nice retrospective image set from msn.com. It was only about 10 - 12 years ago that phones got to the order of small that we know them today and that was still bigger than what we'd consider average today.

I would go a step farther to say that cell phones really turned out to be an enabling technology. The wide-ranging wireless network that cell phones are based on has grown and expanded to support an increasing volume of data transaction as well. This trend will clearly continue and cell phone like personal devices -- will be everywhere had by everyone.

They clearly still have a ways to go with the interface but they are getting better. I think the Apple iPhone is the start of the next generation of personal devices. I do have to say however that I like the current form factor of the small flip-phone and don't like the form-factor of the iPhone for being a phone. As a UMPC, the form factor is interesting and the multi-touch display is definitely trend setting.

Technology

2007-06-16T20:18:00.001-07:00

Garmin Nuvi 350 in my car
Originally uploaded by SquidgeyFlint

Add-on GPS units are another example of technology that just makes sense and provides such a valuable service that it's easy to become dependant upon it.

Earlier this week I went up to Redmond for an after work Microsoft Playtest. Since traffic can be highly variable I choose to potentially be hungry instead of late. I got there with enough time to spare to find food. Fortunately, I had my trusty GPS with me and asked it to tell me what food was nearby. It couldn't've been easier to get food and get back in far less time than had I just started driving around looking for stuff. I'd've definitely got lost. After the Playtest was over, I needed some fuel, so score another one for the GPS.

While GPS units are still pricey, these are definitely going to go the route of power windows and anti-lock brakes -- eventually coming standard on every car. The touch screens are easy to use and while the quality of the user interfaces can vary, they're all easy enough to use. The real value here (besides the core functionality) is the built-in database of businesses. That are many other pluses but being able to do things like hit the button for 'GAS' and have it show you all the gas stations near by, closest ones first, is an awesome use of personal technology.

Good design and good technology

2007-06-13T20:55:00.000-07:00

I'm a generally old dude and in my lifespan I've seen a lot of change in technology... maybe not as much as my parents but it's still pretty impressive. Compare 4 VHF channels with an audio signal remote control to 500 channels of Satellite TV via an integrated Tivo (DirecTivo).

Tivo is a great example of a technology so well placed and well designed that once you have it, you can't imagine life without it. The MrsSquidgeyFlint thought I was buying some techy gadget / stereo equipment kind of thing. It didn't take her long to become so comfortable with the concept that she couldn't imagine life without it -- like when we'd go visit her parents in CT.

Tivo's greatness hits on two fronts:

It's such a simple and obvious idea that you can't believe you didn't think of it.
The interface design was easy enough to figure out and remember.

While bungling either of these elements can sink an idea, I'd say that if you can only have one, you need the first option - the simple, obvious idea. "What if you could record TV without having to mess around with tapes. What if you didn't have to worry about what time your show was coming on? What if you could pause live TV. What if you could rewind to hear that last little bit again?

You could already do most of this with a VCR except that it was a lot of work... and hard to do. And then you had to mess around with all those tapes... and you had to get the times right. And then you had to swap tapes to make sure you didn't record over shows you hadn't watched yet. Tivo took that all and made it super easy to do with a simple set-top box, virtually no setup, no maintenance.

Fun stuff on Amazon.com

2007-06-12T21:38:00.000-07:00

I work @ amazon and it seems like every week I find something new and interesting that we sell. Take this Hello Kitty Bowling Ball for example. It looks like it comes in 2 sizes. 6 lb and 16 lb. I thought 8 lb was the lightest ball made. What I really find amusing is the 16 lb ball. That's the heaviest "size" of bowling ball and at least back when I was bowling regularly, you didn't see many women throwing 16 lb balls.

Then there's this dummy hand grenade that I found last week while looking into an issue in the Sporting Goods store.

The creme de la creme of course is the well known JL421 Badonkadonk Land Cruiser/Tank. You should definitely check out the customer reviews. Who knew that the JL421 would be so popular?

Goodbye squidgeyflint.spaces.live.com, hello Blogger.com

2007-06-10T19:08:00.000-07:00

I originally setup a space over at spaces.live.com b/c MSN Messenger assumed I had one there and there were some built-in widgets to pull xbox live stuff like my GamerCard and my last played games.

Recently I decided that I want to start actively blogging (again really -- the first time was way back in 1995 before the term was coined) and in trying to get the MS place set up nicely was hard.

To me it looks like they want to be more like MySpace and less of a blog spot. That makes them heavy and hard to use. Too many widgets. Too much dynamic in browser stuff for editing. It's hard to find a simple html widget to try and hook in things like a