Skedsheet Blog

Sitting around a conference table is one way to talk about company strategy, but there’s another way.  I like to take a hike.

Getting out of the office is a good way to shake things up.  As time goes by, we are learning that we should actually plan to be out – doing something active really gets our creative thoughts working better.

A few years ago, when we had our sales meeting for JobTracker, we planned to have a little time off to go to the beach, boogie board, and hang out.  It was just half a day out of the whole time we had allotted to get together.

At the beach, while we were all floating in the water, we came up with a new product, new pricing, and talked about new approaches to selling our products.  We didn’t even realize it at the time, but I think we made some fundamental changes to the business – figuring out that we need to keep trying to  undercut our existing products with new ones that are cheaper and easier to use.

About a year ago, Ted and I were trying to hammer out some features – sitting in my office, getting bored and hungry, and not making any progress.  So, we decided that it’d be a good idea to walk to lunch and think about it when we got back. 

Instead, we kept talking through a problem that had been frustrating our customers and making support hard.  And, on that walk we came up with a different approach.  Looking back, we radically improved one of the hardest parts of our software.

Now we just came back from our strategy meeting – and we walked or hiked the whole time.  And once again, we planned some radical changes to our business, marketing and sales.  And once again, my to-do list has 15 new things on it.

I’ve been cheating, and it’s time to come clean.

Despite our whole marketing pitch, product, and general company philosophy of centralizing information, I’ve been secretly using a whiteboard to help me manage my job and schedule some of my activities.

Well, maybe it’s not so secret, since the board is about 5’x4’, so anyone who’s been in my office sees it takes up about a third of one wall.

Here’s a picture of it – yes, it’s a mess.  What works about it is that it’s a place I can easily go and have a daily reminder of what I need to do. 

What’s bad about using whiteboard is that it’s hard to move activities, I’ve accidentally erased parts, and since I like to doodle while I talk on the phone – it’s filled with little notes that are out of context or completely unreadable.

How is my whiteboard being used?

30%: Kid’s scribbling.  I work at home and I occasionally allow the kids into my office.  They need the part of the whiteboard they can reach in order to do their artwork. 

30%: To-do list.  There is a giant list of things that I should be doing, but they’re hard to get to on a day-to-day basis.  About once per month I get the satisfaction of erasing something from this list.  Of course, in that time I’ve added four more items.

5%: Sales pitch.  I have 4 sentences on my whiteboard that remind me that when I talk to customers my conversation should be centered around them: “What are you doing today?  What works about that?  What doesn’t? What’s the consequence if you don’t change what you’re doing?”

35%+ Unreadable.  I have no clue what most of this stuff is.  I know I wrote it because it’s in my handwriting, but beyond that there’s no information.  My favorites are the time “3:30” and the ominous number “2365”.

I don’t have any plans to get rid of my whiteboard – but the reason I can have it is that it’s not the only place I have my information.  At least 70% of what’s there has no value after I write it down, but since I’m a pretty visual person, I need to write as I talk or think.  It’s more of a doodle pad than a calendar or a spreadsheet.

Today is a great day! I finally finished moving all our data to the new servers. I love finishing a project — especially one that involves working until midnight every night until it’s done.

As part of this migration, I outsourced our email hosting to Rackspace, and I couldn’t be happier. They have much better spam filters than we had on our server, and I don’t have to think about it anymore. It’s not that hosting our own email was difficult, but it was a pain to migrate to a new server because you have to time everything just right so you don’t lose mail, or have it directed to the wrong location. Rackspace does it better, and it’s one less thing for me to think about. Well worth the money.

For the new server setup, we’ve got a couple dedicated file servers, and we use Windows distributed file system replication (DFS) to continuously replicate files between them. It’s wonderful! I’ve been trying to get to this point for many years, but I was using the wrong tools. Previously I used rsync or SyncBack, but the problem was always the time it takes to scan all the files for changes. (We currently have 700,000 files, so this is a big deal.) DFS instead uses the NTFS change journal to track all the changed files, and doesn’t have to scan the file system to be sure things are synced up. If there’s another 3rd party tool that does this, I’d love to know about it, because the only problem I have with DFS is it requires all the servers to be on the same domain (or in the same forest on a WAN.) The other tools I’ve seen that use the NTFS change journal still say you have to scan all the files periodically to make sure you haven’t lost any changes somewhere along the way.

When we started out many years ago, we had only one server. To backup the data, we first created a database backup, which involves reading in the entire database and writing out a backup file. Then we copied all the files (or just changes) to a backup, so at a minimum it’s scanning all files for changes, then reading all the changed files to send to the backup. That’s a very disk-intensive process, so while the backup was running, it hurt performance of the application. While it would be nice to have frequent backups, the performance penalty meant we could only take backups during off-peak hours.

For our second generation of servers, we bought the fastest drives we could, which doubled the cost of the servers, but meant the backups didn’t hurt application performance as much. That worked OK, but we still had other problems around disaster recovery. If a server failed and took all its data with it, we’d have to recover from backup, which involved moving hundreds of GBs of data, which is slow no matter how fast the drives are.

Now we’re on the third generation of servers, and we’ve taken a different approach. Now the application servers are only responsible for creating database backups to a file server periodically. That’s much less disk-intensive, and has minimal impact on application performance. We’ve shifted all the backup processing to the file servers, and even that is spread out over a couple servers to make sure it doesn’t impact application performance. So this not only improves performance, but it gives us more redundancy, and allows us to do more frequent backups during the workday.

So does this fix all our problems? No way. But it changes things so much, I don’t know what the next problem is going to be. This week I’ll be using the excellent PAL tool from Clint Huffman to analyze the server performance, and start designing the next iteration of the server architecture. Some days it’s hard to tell I’m in the software business.

Politeness and civility are the best capital ever invested in business. Large stores, gilt signs, flaming advertisements, will all prove unavailing if you or your employees treat your patrons abruptly. 
     –P.T. Barnum

My washing machine is leaking.  It’s under warrantee and I’ve left two messages and sent an email…today.  All I want is a call back or some kind of response.  It’s okay if you can’t come out to fix it this week and I don’t mind if  there’s going to be a charge. 

But, every minute I wait I get frustrated for no reason.  On top of that, I’m cursing, getting worked up, and won’t recommend you to my friends.

I understand why this can happen – I’ve been guilty of not following up when I say I will, not being clear about what I’m doing, and mostly taking on more things than I should.

We try to treat our customers as we’d like to be treated.  No matter how you slice it, most of the time it comes down to one thing:

Set the expectations from the beginning and keep communicating.

We keep improving how we set expectations, but it really comes down to being organized enough to tell your customers what’s going on.  If you’re selling something, you need to end every conversation with a plan for what will happen next. 

If you promise to make a phone call, you need to follow through – especially if it’s uncomfortable or bad news.  Even if you don’t know the answers you’re being asked, just be honest – rather than making up excuses, most people are happy with the answer:  “I’m really sorry.  I don’t know.  I’ll try to help.”

After four calls, I finally caught someone live on the phone.  “Didn’t you know?  Our tech is scheduled to come to your house to fix your machine at 10 tomorrow”.

Now that we’ve got a working skedsheet (even though we’re still hiding it for a while) I’ve spent some time playing to see how (and if) things work.  I’m really excited about the way it’s shaping up – and despite the fact that it’s really ugly, it actually does a big part of what we want to do.

I’m starting to feel good because skedsheet is going to bring value to the people and companies we know well – construction subcontractors.  And, I think it’s more widely useful than that.

So, I want to figure out a way to use it for myself – I guess the entrepreneurially correct phrase is “eat our own dog food”.  For JobTracker, we ended up using it almost immediately as a CRM system, even though that was a bit of a stretch…it turned out that using our own software on a day-to-day basis was very useful, especially early on.  What can I do?

1) Marketing calendar.  I have a spreadsheet of things that need to be done marketing-wise.  Trade shows, ads, articles, mailings.  One of the problems I run into with my marketing spreadsheet is that it’s hard for me to follow what needs to get done today or this week.  I think having a calendar would help.

2) Supporting customers. I’m wondering if there’s another level of detail that skedsheet could help with in managing some support tasks.  Probably not, since we already have an system for managing this.  But maybe, a calendar spreadsheet would be good in helping our JobTracker customers plan their implementations.  “here’s a schedule with dates, who’s supposed to do what, and what are the milestones or prerequisites.”

3) Personal stuff. I’ve got a spreadsheet for a workout schedule, and a spreadsheet of some of my kid’s activities.  I think the kid activity spreadsheet would be really cool if I can convince some friends to read, edit, and add to it, too.

I had lunch with a friend who’s a “product innovation” consultant, and although we try not to talk about work too much, that’s inevitably the topic that comes up.

My friend’s premise is that making and showing off paper (or PowerPoint) mock-ups is worth it.  Because…before you spend a minute of development time, you’ll want to make sure that the product you’re planning is worth it. 

Now some people disagree, and I’ve personally believed you need a product to show before you can talk about it – the opposite is just vaporware.  But there are some good arguments for trotting out your ideas on paper before you build.

So, why should you show a paper design to a prospective customer?

1. Get immediate feedback, before you spend time writing code.  If an idea isn’t worth anything to a customer, you get away with a much smaller investment – drawing out a design on paper could take hours or days, but writing code could take months.  Or more.
2. Don’t set the expectation that it’s real, so customers don’t get hung up on faults.  If you see real software, even with the disclaimer that it’s a prototype, you’re going to be drawn to the worst parts or repulsed by how ugly it is.
3. Prevent yourself from falling in love with your design.  There’s a tendency to value the work that you do and not be willing to throw it away.  We’ve managed to steer clear of that in the past, but once you’ve got a framework built for a particular design, it’s painful to give up.
4. Start getting the word out, before your product is ready to show.  Through the skedsheet blog, we’ve tried to explain what we’re doing and why, but we’re not talking about the specifics or making promises about features.  We could take it to the next level by showing a bit of what we have in mind…today.

I’m still torn, but I spent a few hours last night mocking up a design, purely to practice a demo.  Almost everything I wanted to show could have been done in the prototype we’ve got running already, but it felt more honest doing it with just a sketch.  Will I show it to anyone?

We reached a milestone today. We moved Skedsheet from the development servers to the production servers at http://www.skedsheet.com/

This doesn’t mean it’s done or ready for public viewing. We’re just putting everything on the public site so we can have an outside web designer help us make it look better. (At this point, it couldn’t look any worse. So I think she’s set up for success.)

After installing the software, Harry and I signed up as the first users and created a few Skedsheets. We also confirmed our email addresses (to prove we are the rightful owners of them) so we can now share these Skedsheets with each other.

If we lived in the same state, we might have raised a toast to this little milestone. Instead, I wrote a blog post.

The Big Switch by Nicholas Carr tries to be a business book, a history book, and a warning about the future.  Unfortunately, by trying to bite off so many topics, none of them really get a chance to shine.

Punchline: Google is to computers as Edison was to electricity.  There are some interesting parallels between how electricity became popular and the internet showing up everywhere.  I had no idea how fast electricity took off and how influential Edison was as a businessman, founding what became GE and licensing technology (and his name) to various power companies like Consolidated Edison.

What’s good: The first half of the book gives a snapshot into the time when electricity evolved from being virtually nonexistent to becoming the primary power in businesses, transportation and homes.  What’s hard to believe is that all of this happened in a span of 30 years (between 1880-1910). There’s a similar story showing the beginnings of the internet – briefly touching on the PC, ARPA, and finally Google.

There are some interesting, but unsubstantiated, claims about how the promise of the internet (democratizing information) might not be true – rather that it’s concentrating wealth and power in a few companies, more than other technologies in the past.

What’s bad: It felt like the author wasn’t sure who the audience should be, so at times it seemed overly dumbed-down.  But that didn’t really bother me too much because while he’s explaining technology (both electricity and internet) the story is interesting enough to see beyond it.

The first real problem is that there’s no focus to the book – it’s like each chapter was an article written on it’s own without a strong overall theme.  The second, and bigger problem is that when Carr tries to speculate about the future I totally lose interest.  Maybe because I disagree on his conclusions that the internet will kill all kinds of culture, make us all vulnerable to terrorists, and maybe destroy our way of life.

What I learned: Our scheduling software was built around the idea of being a web service from the beginning, but I never considered the scale of this kind of technology.  I live about hundred miles from a Google data center that was one of the first huge ones; power consumption – around 100 MW – similar to a city like Tacoma, WA.  This switch to “utility computing” is going to make software and hardware cheaper and more accessible for a long time.

Would I recommend?: Probably not.  If you want to go to the library and only read the first third, that might be okay, but I think the payoff for the rest of the book isn’t there.

I have been shocked a few times when I see how some of our customers take care of their own data, when they install JobTracker on their own servers. They usually think they’re fine, until their server crashes after running 24×7 for 4 years, and they suddenly realize they don’t know if they have any way to recover.

I think I have the opposite problem. No matter how much effort we put into designing and implementing our backup process, I’m always worried that it’s not enough. I’m just a glass half-empty kind of guy.

When designing a backup process, the only thing that matters is how you’re going to recover data. So you have to think backwards and design a recovery process first, then make sure you have a backup process to support it.

We just bought a new set of servers and much of the decision for what to buy was based on our desired recovery process. Our previous server setup left us with a few scenarios where it would just take too long to recover from a disaster, because we had to move too many GB of data across the network. The new setup spreads the data out more, so there is more redundancy and recovering from any single failure will be much quicker.

The two primary measures of the recovery process are how long will the system be down, and how much data will be lost. Ideally both these numbers would be zero, but you can always dream up a scenario that causes downtime or data loss, even if it’s extremely rare or violent. So the best you can do is make these numbers small, but the smaller you want them, the more it costs, and the more it can hurt performance.

Once you accept that there’s the possibility of downtime and data loss, then you can map out various scenarios, and design a process to get the right $ cost vs. performance vs. risk trade-off.

We have done just that, and below is a summary of how much downtime and data loss we expect from various disasters, under our current server configuration.

Some of the reasons we can recover quickly are:

• Our servers are in a data center that’s staffed with experts 24×7x365 with tons of spare parts sitting around to fix any hardware problem within 30 minutes.
• We have a bunch of identically configured servers. If there’s a problem with one, we can easily move the data to another server that’s ready to go.
• We use a combination of database full & log backups, file replication, on-site backups, and off-site backups.
• Every piece of data gets stored on at least 5 servers, across 10 drives. Keeping 30 days of full backups means once it’s a month old there are over 90 copies of that data! (Luckily our new servers have 18TB of disk space to handle this.)

We’re always improving our process, so I expect we’ll get these numbers down over time. But it also depends on how much money we’re willing to spend, which is based on our revenue going forward.