This document is steve-projects/doc/When-I-Go.html,
from the steve-projects.git. It can also
be found on the
web; that version may change over time.
I've had a lot of fun here, learned a lot, and met a lot of wonderful people. I'll miss you all.
I've learned PHP and Python, and gone up a level in shell programming. I've probably gone up two levels in git points. I've learned quite a few things about marketing and management, too, just by observation.
And I've done my small part toward building a product that we can all be proud of. That's huge; I really appreciate having had the opportunity. The eQuill/eWriter system really is a ground-breaking product, and I think we've done (and are doing) a great job with it.
First of all, I want to apologize to everyone I've offended over the course of the last year and a half -- I sometimes have a real talent for putting my foot in my mouth.
I also want to apologize for git-sync. All I can say is that it seemed like a good idea at the time, and on the whole I think it works better than rsync ever did. The implementation, though, was complicated by some flawed assumptions about the efficiency of ssh, the extreme difficulty of communicating the basic idea to people not familiar with git, and most of all by my failure to adequately oversee its progress in the early stages when it would have been easier to fix things.
For that matter, I want to apologize for rsync -- that was another of my "seemed like a good idea at the time" ideas.
And I want to apologize for not getting to know more of you better.
Keep in touch!
Somewhat in the spirit of the song quoted above, here are a few remarks about where we went wrong. Please take them as warning-signs pointing away from the pitfalls and traps, and toward what could be done better in the future.
The schedule was impossible to begin with. Not merely unrealistic -- impossible. If we had built continuously on the existing research prototype, achieved our staffing goals, and had nothing at all go wrong, we might have been able to pull it off. Probably not.
Conventional wisdom (as I've observed over 40 years in Silicon Valley) is that bringing out a radically new product with software and hardware components takes 2-3 years. The fact that we might pull it off in under two is astonishing. One was impossible.
So let's talk about building on the existing prototype, which was a REST implementation written in Perl (Alexandria). We also had a Memphis document library written in Python. We actually spent several months building on this base, while at the same time working on a total replacement for both the web front end and the Memphis library in PHP. And we spent many months testing the API server with fake Memphis documents that the (experimental) tablet software didn't accept, and building a sync layer that fell apart as soon as the tablet tried to talk to a real API server. Not to mention not having a web front end -- not even the limited one provided by Alexandria -- for uploading and viewing documents.
Things weren't much better on the tablet side, where the display server and clipboard application were both ripped apart and rewritten at least once.
And in between, the Memphis document format went through its own series of incompatible revisions, and there were long stretches during which the tablet and the web software were using incompatible versions.
There were good reasons for all this thrashing -- there were serious, show-stopping design flaws. But the schedule never changed, and there were long gaps when we didn't have anything that worked. Problems are now turning up that would have been noticed quickly if we'd ever had more than a handful of people in the company using our own system.
The bottom line is that we're probably going to release 6 months behind our original impossible schedule, with at least another 6 months of testing, QA, and tuning left undone. Not so good.
Now let's talk about staffing. If we were going to pull this off at all according to the original schedule, we would have had to bring in a large number of the very best programmers available, with a wide range of specialties. We never caught up to where we needed to be in terms of staff, and, again, we never adjusted the schedule.
We ended up getting some very good people, and I like you all a lot, but it took us a lot longer to get here than it needed to, we made some serious mistakes in hiring (as witness the recent DNS hijacking fiasco), and some very good people hung on for a while and then left. More very good people undoubtedly looked us over and walked quickly in the other direction.
Working conditions had a lot to do with that. Insane "core hours" and cubicles rather than offices don't make for a good working environment for people like programmers and engineers who require long periods of concentrated, uninterrupted thought. That's just engineering management 101. Of course, a lot of upper management hadn't taken engineering management 101. Or read The Mythical Man-Month.
Speaking of management, there were a couple of decisions that were simply baffling. One of those was being so inflexible about core hours that our director of engineering, John Barrus, had to leave. Let's be more specific: the only person who had intimate knowledge about how the web services and device sides of the product fit together, was forced out over something that had nothing to do with whether he was doing a good job.
Another one was promoting some of our brightest and most productive engineers to management while they were in the middle of implementing the product. And while we were already understaffed for the job we were trying to do. Yes, they deserved a salary increase. Promotion isn't the only way to do that.
Having our CTO spend full time on writing and supporting user trials and demos, while the software was being re-designed from top to bottom, probably wasn't the best use of resources, either. I filled in where I could, but inevitably there were some design decisions that were made by default and ended up having to be done over.
Steve Savitzky <steve@rii.ricoh.com>; August 31, 2011