Dave Naffziger's Blog

As BrandVerity has grown, I’ve sought out web-based applications to run various aspects of the back-office. Without fail, I’ve been consistently disappointed with quality of these seemingly-mature applications.

I applaud the focus that many of these applications have taken. There are stand-alone applications that that handle invoicing, payroll, accounting (of-course), transaction processing, etc.

All of the web-apps appear on the surface to be inspired by web2.0. They have the right colors, fonts, ajaxy goodness, etc. However, they fail on either basic usability or on core functionality.

Here are a few highlights from my recent testing:

FreshBooks - Invoicing
A service complete with APIs for access that even snail-mails invoices… but doesn’t email invoices.

SurePayroll - Payroll
They handle state payments for Unemployment Insurance, but not Workers Comp deductions. Broken form fields that don’t accept the most basic of information (business identifier)

PayQuick - Payroll
Ajax forms won’t submit. Complete lack of guidance on what values fields expect ($ vs. %).

Oh, and PayQuick won the PC Magazine editor’s choice award with SurePayroll a ‘close runner up’.

Authorize.Net - Transaction processing
Took a week to get a ‘test account’. Menu system fails spectacularly in Firefox (menu items simply don’t appear, but you don’t know they are missing).

And then there’s the accounting packages. If you’ve ever dealt with QuickBooks online (IE only), I’m sure you wish for that time back as much as I do. It typically takes 3x the clicks than it should to accomplish anything.

Maybe the downturn has an upside? All the developers working on Facebook Apps and Social Networks just might end up working for these companies (or starting their competitors).

Despite the fact that I despise fanboyishness, I’m developing a deep admiration for Amazon’s work with AWS. This admiration only deepens when I compare their ‘cloudy’ approach to Google’s.

App Engine reminds me of the Transformers that I used to play with as a kid. They were way cooler than any other plastic toys available, but they were still plastic toys. They had some flexibility, but ultimately you were playing with either plastic robots or machines.

Amazon’s Web Services remind me of the Erector Sets I adored. They came with electric motors, gears, pulleys and tons of structural pieces. I felt that you could build anything with an Erector Set. Not only that, but you could combine pieces from the set with just about anything else by bolting it together.

I’ve toyed around with both services and even built a simple tool on Google App Engine that we use for Regular Expression development at BrandVerity: PythonRegex, and a SimpleDB Query Tool. However, I increasingly find that App Engine isn’t an option for any project of reasonable scale or complexity (not to mention that I find the SDK cumbersome and unstable). It seems ideally suited for the next housingmaps.com, but not for most projects.

However, Amazon Web Services offers an incredibly deep and powerful set of tools that only continues to expand in scope and capability. Browsing the available AWS services feels a lot like a visit to Home Depot - the potential excites me. The building block nature of AWS allows the services to be mixed and matched with just about any application. EC2, S3, SimpleDB, Cloudfront, mechanical Turk, are all serving to drastically lower the cost of starting and operating a web business. Not only are the services super-useful but their very nature encourages a number of extremely beneficial programming practices (particularly dependency reduction and linear scalability).

I love that the pricing is incremental. My bill for toying around with AWS was $0.14 in the first month. I’m always wary of Google’s ‘free services’, and find that they require a careful read of the TOS to determine if it is a good idea to lock into their services. With AWS, I know my prices up front and can build very simple forecast models. Nothing is hidden. Not only that I love that AWS is constantly lowering prices. Prices have dropped for nearly all the major services in the last year.

Beyond the automated tasks, Mechanical Turk is purported to have 300,000 ‘Turkers’ earning extra income performing straightforward tasks that automation can’t solve well. Apparently the average lifespan of a task is less than a few hours. Photo tagging can be accomplished for 1 to 2c per photo. Semantic Web applications could be built with slight technological investment and instead depend on the semantic abilities of a small army of people.

The announcement that really impressed me was the aggregation of public data sets (Elastic Block Stores). I’ve long believed that the data sets maintained by governments and similar organizations possess a tremendous amount of knowledge that when freed from access constraints could expose deep knowledge. Amazon removed a significant barrier to this analysis and I can easily see a future where the world’s collected knowledge is available for easy analysis.

I eagerly await new developments from our new overlords in the cloud.

As more and more of our data moves to the cloud, it frequently gets scattered across different sites. As much as I love data, aggregating and normalizing it is a pain. I have been an advocate of Yodlee for nearly a decade, and have become so accustomed to it that I can’t imagine how people manage their finances or frequent flyer accounts without it.

Microstock (stock photos that cost <$10 per photo) has become an increasingly large business and is rapidly tearing the $2B traditional stock photography business to shreds. There are probably close to a fifty thousand individual photographers contributing photos to sites like istockphoto, fotolia and dreamstime.

If you are a photographer, you’ll submit your images to multiple sites: the sites are non-exclusive, it costs nothing to submit a photo and it increases your chance of selling the photo (which can be sold multiple times). But tracking the performance of your photos is very challenging - you need to download data files from multiple sites, normalize them and then somehow link the photo-by-photo performance data from the different sites.

Rahul and Casey Zednick just launched LookStat, a must use application for serious microstock photographers. Not only do they aggregate the data from multiple sites, but they also do the very hard work of normalizing your data. That means that you can see how much a single photo is making across all sites.

I fully expect that LookStat becomes an essential application for photographers. Congrats on the launch!

The Seattle tech news scene has long been dominated by two bloggers: John Cook and Todd Bishop. Both were formerly writers/bloggers at the Seattle PI, and both left at the same time to launch TechFlash with/for The Puget Sound Business Journal.

Although the site launched on 10/21, it seems that they’ve both been writing for a while and are in the process of publishing back posts (either that or they soft-launched back in September).

There were a number of things that disappointed me about their prior coverage, and I hope now that they are free from the restrictions of a big media news organization like the PI they’ll become better bloggers. Anyway, here are my suggestions for making TechFlash even better:

1. Full feeds. No respectable tech news source sends out partial RSS feeds. Attention is way more valuable than the incremental page views. I spend way more time reading the other publications on John Cook’s Feeds list than I have on his blog at the PI. Full-length feeds are a big part of that. If partial-feeds are a must, then at least write a paragraph feed summary - don’t just take the first 30 words…
2. Opinion. Please provide some. If all we wanted to know was what a company did, we could visit their website. Tell us if they will be successful or if they’ll flop or what you think of their offering.
3. Unique. Guest bloggers are great, but don’t just reprint their content. I subscribe to Andy Sack’s blog. I read his original post on venture over the holidays last week. I really don’t need to see the same thing twice in my feeds (yes, even though it was a good post).

Regardless of whether or not they implement these feeds, I’m definitely excited for the increased depth that Techflash can provide.

The layoffs in Silicon Valley have started and will likely continue for some time.

Friday on Techcrunch, Arrington asserted that some of the layoffs weren’t being done because of the economic conditions, but because the companies were utilizing the changing public sentiment to trim underperforming staff.

This is the wrong approach to reducing staff. The two forms of staff reductions are significantly different and confusing them provides a mixed message to employees that destroys morale.

Reductions In Force (RIFs) are layoffs that abolish positions. They are not performance-related and typically result from a company that downsizes or restructures. Many states have legal guidelines that govern RIFs, but in general they offer more protection to employers than performance-related firings. Nearly all layoffs you read about are technically RIFs.

Performance-related firings require much greater documentation on behalf of the employer. Lazy managers may not counsel or document poor employee performance properly. This leaves companies vulnerable to lawsuits. So, some companies choose to fire poor-performers en-masse and describe the action as a RIF.

I think we went through 3 layoff cycles on our way to stabilizing Quova. The first cycle was truly a layoff - we had built the company far faster than our customer base. We lost some very good people, but our burn rate was way too high and startup economics were different in 2002 than they were in 2000. In general, morale survived intact.

However, we began to mix layoffs and performance-related reductions in the next two cycles. After each layoff, the message would typically be that the company was stable now and people didn’t need to fear for their jobs. This was a true statement and it remained largely true throughout, but it felt hollower after each successive layoff. Morale plummeted and took at least two years and nearly full turnover for it to recover.

If you are disguising a mass-firing as a RIF, you cannot provide open and honest communications to your employees. This breeds mistrust and all of the bad things that accompany it.

The bottom line is fire your underperformers for underperformaing. If you are firing several of them at the same time you’ve already fucked up. You need to be asking why you didn’t fire them individually earlier. Don’t be lazy and don’t allow your managers to be lazy.

I’ll be speaking at PubCon this year on trademark monitoring issues and Affiliate-based PPC Issues and Options. One of the benefits of that engagement is that I’m able to pass on a 20% off coupon. I did some quick searching and found mostly 10% off coupons so I thought that this was worth contributing. Use this coupon code before Nov 5:

• na-84420

I’ve been to Pubcon two years in a row and have found the content in particular to be very good.

————-
Disclosure: This coupon is the equivalent of an affiliate link, so I’ll receive a small share of the registration (I don’t really post affiliate links, but there wasn’t a way to undo that since it is based on a coupon code). Let me know if you use it and I’ll buy the next round.

Iva recently received an 80 GB Zune as a token of appreciation for her work on a project. The first thing that I did once she unpacked it was to plug it into the computer (running Vista). The setup process that greeted me was horrific. The experience was so bad, that I presumed I had gotten into some error state. This weekend, I duplicated the process on my own laptop (running Vista). Here are the screenshots (note, I have UAC turned off so it could easily have been worse).

After a decent amount of installing, I presumed that the Zune was installed. Instead I got this message.

There was no disc in the box.

Two error messages this time.

A roughly 30 MB download…

The process that started everything was when I plugged the Zune into the computer. Fortunately I caught the warning that I need to unplug the Zune. I wonder what would have happened if I hadn’t unplugged it.

I can’t imagine that anyone at Microsoft is happy about this process. I’m assuming that it is the result of either a real or perceived threat of a monopoly lawsuit.

I’d be incredibly cautious if I were Google. Similar encumbrances would be disastrous.

In a 10 day span, $16.7 Billion was withdrawn in deposits from Washington Mutual (5% of $307 Billion in assets). In 11 days, depositors withdrew $1.3B of IndyMac’s $18.9B in deposits (~7%). Both bank runs were stimulated by (correct) concerns about the financial conditions of the banks. Both banks were FDIC insured.

FDIC Purpose

In my limited understanding of the FDIC, it fulfills two main purposes:

1. Provides federal insurance for depositors with less than $100K in any single account at any FDIC-insured institution.
2. Prevent bank failure. There are essentially two components of its efforts to prevent failure:
   1. Require adequate reserves: All FDIC insured institutions are required to maintain certain levels of capital reserves. If an institution falls below certain thresholds, the FDIC can change management or take over the bank entirely.
   2. Prevent bank runs: The federal insurance and reserve requirements provide depositors with comfort knowing that they cannot lose their money. This comfort should prevent rumors from becoming reality and depositors from simultaneously making withdrawals.

How the FDIC Failed

With both failures, the FDIC served one of its two purposes - it ensured that depositors didn’t lose money. However, it failed to prevent the bank runs that actually triggered the failures.

So, why the failure? I’ve got three theories:

• The effort required to move money between institutions is trivial. The FDIC was created in 1933. Most consumers today can move money between banks with less than five minutes of effort.
• Consumers don’t understand the FDIC. Bank failure means you lose your money. To the mattresses!
• Consumers don’t trust the government. They simply don’t believe that their money is protected.

I’d love to see polling data on this, but I’d be willing to bet that the second reason is the likely answer. A common notion that I see/hear popping up is that some believe that Fed has 99 years to repay their insurance. Here is FDIC’s take on that myth:

Misconception Number 3: If a bank fails, the FDIC could take up to 99 years to pay depositors for their insured accounts.

This is a completely false notion that many bank customers have told us they heard from someone attempting to sell them another kind of financial product.

The truth is that federal law requires the FDIC to pay the insured deposits “as soon as possible” after an insured bank fails. Historically, the FDIC pays insured deposits within a few days after a bank closes, usually the next business day. In most cases, the FDIC will provide each depositor with a new account at another insured bank. Or, if arrangements cannot be made with another institution, the FDIC will issue a check to each depositor.

I can understand liquidity concerns, but I’d hope that most of us can survive a day or two of illiquidity. In fact, WaMu debit cards continued to work as normal the day after the failure.

I thrilled that the government retained Suze Orman on Sep 22 to launch an ad campaign informing the public. They need to think bigger with more advertising. I’d love to see the candidates incorporate some of this messaging into their ubiquitous advertising.

However, technology is beginning to antiquate some of the FDIC legislation. Bank runs are far easier to trigger now than they were during the S&L crisis and certainly back in 1933. Some of this legislation needs to be rethought to provide mechanisms to account for the sheer speed with which a run can occur. And the FDIC limit set in 1980 needs to be raised.

Then again, I may be the last person with my money still in a bank…