Lincoln was talking about fooling people in his famous quote, but over the years the quote has been contorted to be applicable to customer satisfaction. In it’s current version I think it goes something like this
“You can please all of the people some of the time, some of the people all of the time, but you can’t please all of the people, all of the time”
In that context at least it’s a quote just crying out to be used with software. Over on our boards there’s a bunch of people that I’m fairly certain we please all of the time. These are the people who rely on PayPerPost for a supplemental income, an income that would otherwise mean they have to work outside the comfort of their home, pulling some crazy hours doing crazy work just to stay afloat. These are the small business advertisers that want to get some really good exposure on the Internet but who can’t financially stomach a huge AdSense or DoubleClick campaign.
I’m fairly certain we make absolutely everyone happy, some of the time. I know the re-introduction of Captcha for example unanimously made pretty much all the posties that had been fighting system cheats happy. I know that when we introduced PPP Direct bloggers and advertisers alike hailed it.
But of course, you can’t keep everyone happy forever. Some people love Captcha for example, while others now loathe it. Many people love the country segmentation stuff, but many don’t and see it as a way of filtering them out of taking opportunities.
Over on the boards I often see threads asking for new features, for changes, for subtle nuances in the way the system behaves to be fixed. I also see people complaining vehemently about how some aspects of the system are just bad. Some of these are software items, some are infrastructure items (speed and performance on busy days). I’ve been pushing back quite hard against a lot of requests for change recently, and I wanted to take some time to explain why, and also to explain how we got where we are from a technology standpoint, and where we’re going in the future.
PayPerPost was originally developed by one very talented guy working at another company. He was learning Ruby on Rails, the technology that powers PayPerPost, at the time and with that in mind did a stunning job. PayPerPost.com was a very small and simple system back then and the developer did a sterling job keeping up with a huge raft of requests and enhancements coming in from the community and Ted. But, it was always a very reactive way of working, not a proactive one with a lot of up front design. About a month after launching we started to hire the dev team at a rate of 1 or 2 people a month. We grew very rapidly because we needed to. We had an even larger raft of features that needed to be developed, bugs that needed to be fixed, and users that needed supporting. We tried to be proactive with some things and were largely successful, but the majority of work continued to be reactive in nature.
The end result is that PayPerPost.com (the website) experienced some very organic growth. We tried very hard to stay on top of bugs and other issues and at times we didn’t do too well. Thankfully today we are well ahead of the bug list. We tried to refactor the code as much as we could as well, striving to maintain as elegant a set of code (elegance in code = ease of maintenance) but the need to continually innovate and maintain our market lead (we are a startup after all) left us on the back foot quite a lot in that arena as well.
While it’s a difficult position to be in, it’s not unusual. There are literally reams of printed articles and books talking about software entropy as it’s known, and how to deal with it. There are tens of thousands of consultants out there that will help gain control of software that has evolved organically, and I used to be one of them. Obviously the goal would be to never arrive in a position where you have to deal with it, but the best laid plans of mice and men….
Earlier this year something wonderful happened. Ted went on vacation. It gave the dev team a chance to step back, really assess where we are at, and where we want to be. It also gave us a chance to just toss around some ideas and try some of them out. In the midst of this I came up with a way to not only pull all those ideas together into a single cohesive system, but also a clear road forward in terms of not only stabilizing the app, but also scaling it to support massive growth.
Ted returned from Europe and was almost instantly dragged into a conference room where myself and two of the senior developers, Trevor and Daniel, sat him down and told him where we thought we should be heading, from a technology perspective.
You know the result of that meeting as “Argus”, a name given in honor of Scott’s now deceased but much loved dog, but which also was the name given to a mythological hundred-eyed, all knowing, all seeing Titan.
We have 3 clear goals with Argus. The first is obviously competition. There’s a feature set in Argus that will just blow your mind. The second goal was to fix those parts of the app that we, the dev team, don’t like. The third goal is to make it trivial for us to deliver new features, updates, and fixes in the future. It’s not trivial now – very far from it in fact.
The problem is that we need to keep PayPerPost.com as it currently stands running. We can’t just abandon the application as it is currently, and go hide in a coccoon until the Argus butterfly emerges. So, the dev team have been driving incredibly hard to get the bug count to zero, and provide a set of quick new features to free us from a lot of the internal support work we have to do. We’ve also prioritized a set of absolutely vital changes that need to happen to PayPerPost.com fairly rapidly and we’ve delivered most of those over the past couple of weeks.
The focus now though is well and truly on Argus. We have just 2 months to get together the most amazing overhaul you’ve ever seen and bind in a bunch of new technology we have that we feel you guys desperately need. For everyone this is a fantastic opportunity to right wrongs, and to make PayPerPost.com everything we always dreamed it would be.
We’ve done a lot of up front design work, planning and architecture. We’ve done what should have been done before the site launched in the first place. The end result will be a fast, highly scalable application that can cope with massive growth of the user-base. The resulting application will also be highly maintainable, and uses an architectural design we’ve come up with that will also allow us to scale up and down the dev team on demand without suffering a productivity hit. We’re talking here about a system that is free of bugs, that is snappy to use, that does pretty much everything most of you have asked for it to do, and then some. We’ve streamlined a number of processes that drive people crazy. We’ve wiped out unnecessary cruft where we can. We’ve tightened up the user experience where we’ve found you guys have a less than optimal experience. Above all else though, we’ve listened to you. You want hundreds of opps. You want a higher quality network. You want more opportunities to get your brand out (if you’re an advertiser) and more ways to make money (if you’re a postie). Argus addresses those desires.
We need to remain focussed. We need to keep driving towards our delivery date. We’ve got a short date because we have to get this done, have to get it out, and have to get you guys using it as fast as reasonably possible. It’s everything we all want PayPerPost.com to be, you lot included.
What this means though is that between now and then I have to be ruthless with new features in the existing system. Of course we’ll fix bugs. Of course we’ll keep providing support to the Customer Love team when we’re called on. But as far as new stuff is concerned I have to guard the team. ‘Simple’ things like adding a link to the boards on all the pages in the app sound trivial, and really they are. But if I give in to one, I have to give in to two, then three, and so on. Every change, however small, also has to go through QA, and then has to be scheduled for a full deployment. The changes also have to be made to somewhat icky source code and then merged down into the Argus source trees. That slows us down, a lot. It’s much easier for us just to plan the changes you’re asking for into Argus and get them done right. We’re also staying a small cohesive team. Every ‘small’ feature I put a member of the team onto means I lose at least 1/10th of the manpower I have available for Argus.
So, I hope that explains a little of where we are and where we are going. More to the point I hope it explains a little of why I have been so resistant to building in yet more changes between now and November.
But, November’s a long way off right? How can you wait that long? I can tell you right now that we will be hand picking between 50 and 100 posties to start beta testing features at the end of September. We’ll also be showing a similar number of advertisers. You will get the system you want.
