Philip Greenspun started six companies and buried three. He has the proud boast of having the same email address since 1976, and of having developed open source software since 1982. He has taught at MIT, written four computer science textbooks, numerous journals and many magazine articles. He is a well-known photographer, a qualified airline transport and helicopter pilot and instructor. He has three MIT degrees (including a Ph.d).

Philip Greenspun is, however, probably most famous for founding ArsDigita in 1997. The business is famous in the start-up world as both the incarnation of a new model for software consulting and as a striking example of the dangers of accepting venture capital.

As with Google, programmers reigned supreme at ArsDigita and with this base of skills, the company grew extremely quickly; by 2000 the business was turning over $20 million a year. That same year Greenspun and his co-founders accepted venture capital of $38 million, little knowing where that would lead.

RM:

“Philip, if I remember right, you were a grad student at MIT and then wrote a travel/photography book called Travels with Samantha, which seems to have kick-started ArsDigita. Can you run me through the process because I think it’s a fascinating story of how to develop a product. “

PG:

“In 1993 the computer science professors at MIT were telling me that what I wanted to work on, internet applications, was not an interesting topic. The hard problems had all been solved in the 1960s and they didn’t see the web as being used for anything more than straightforward one-way publishing, so why bother researching the challenge of computer-supported collaboration? I took the summer off to drive to Alaska and back, writing a long letter every week to send to friends and family – that way they’d have something to respond to. When I returned, I collected up the letters and added photos to make what is today at philip.greenspun.com, one of the first heavily photo-illustrated web sites. The book generated a lot of questions, but not the ones that I expected. I thought people would ask about Alaska, philosophy, literature, and the other topics touched on in the book. Instead people would ask “How did you take that picture of a bear?” or “How can I get a portrait with a blurred background like that?”

After answering about a hundred of these emails I decided to write up a “photo tips” web page that would answer all future questions. But photography is an open-ended topic so the more that you teach the more questions you’ll get. So I started up a question-and-answer forum figuring, that if people could see their question already asked and answered, they wouldn’t keep sending me email. I built it so that I could answer, but also so that other readers could add additional answers. Inadvertently I created the first two elements for a sustainable online community: magnet content and means of collaboration. Photo.net was born and grew like a weed.

Anxious to minimize the amount of time that I was putting into photo.net, I developed what today is known as content management software and means of delegating discussion forum moderation to volunteers. Starting in 1995, thanks to a contract with Hearst Corporation, I began getting a lot of assistance from fellow MIT students such as Jin S. Choi, Tracy Adams, Ben Adida, Terence Collins, and Brian Tivol. They were soon joined by Eve Andersson, from Caltech. By 1997 or so, we had a substantial toolkit for building online communities and began formal releases of the software as the open source “ArsDigita Community System”. “ArsDigita” was a Pig Latin term coined by Terence.
The company, ArsDigita, grew accidentally. I probably hung up on the first five customers. A big company would call and ask for assistance with adding some features to the software. “I gave you the software and documentation. You’ve got 10,000 programmers. Why are you bothering me? I’m trying to finish my PhD!” I resisted incorporating, but our first customers were Oracle, Siemens, Levi Strauss, and America Online. These big companies had been in conflict with the Internal Revenue Service regarding the hiring of contract programmers, with the IRS saying that they should have been W2 employees rather than 1099 consultants. So they refused to make contracts with individuals. That’s how we ended up as a company instead of a loose band of individuals.”

RM:

“Much of what ArsDigita offered in the early days was driven by the company’s needs rather than what people asked you for. Was the philosophy to innovate for your customers rather than have them driving your innovation?”

PG:

“Above-normal returns on investment, in my opinion, usually comes from either (1) having a lower cost of capital than everyone else, or (2) knowing customer needs better than anyone else. We didn’t have rich parents or connections so our only way to make money was to know what customers needed better than our competitors. This was easy because we had photo.net. We would build software for, what was at the time, about 100,000 registered users (more than 600,000 today). If there was a performance problem, a user interface problem, a spam problem, or a cost-of-administration problem with the new software, we would find out about it within hours. At a traditional company like Microsoft it might take a year to do what we did in a day. They’d have to burn the software onto CD-ROM, send it out to the field, have product managers survey the customers, write up what the customers said, send a new feature set to the programmers, wait for the next release to make it through QA, and then send out another CD-ROM. Having programmers who were also publishers of several online communities is what enabled us to innovate, not a particular philosophy.

Another thing that helped was that we generally hosted applications for customers. Today this is called “software as a service” but we just called it “freeing the customer from having to install Oracle and maintain and monitor the server.” Again, if something wasn’t right we would find out about it immediately.”

RM:

“I was reading an interview with you where you say customers were stunned that you managed to deliver on deadline. Was overall customer service really that bad in the 1990s?”

PG:

“Talk to anyone who has purchased software development services lately and I think you’ll find that programmers are still among society’s most hated individuals! I remember in the 1980s I was proudly showing off a computer-aided mechanical engineering application to an executive at Babcock and Wilcox. The software we’d built would take specifications for a big steel structure and generate a 3D model and then blueprints automatically. It did a person-year of work in about one hour of Lisp Machine time. The demo was going well until I talked about a feature planned for the next release, due out in a month or so. The executive said “Did you hear about the IBM salesman’s wife who was still a virgin after 15 years?” I responded that I had not. “Every night he would sit on the edge of the bed and tell her how great it was going to be.”

Even today programmers are still overestimating their capabilities, implementing stuff that they think is fun instead of stuff that the users and customers need, missing deadlines, failing to document, etc. It is a rare custom software development project that comes in on time, on budget, and with the promised features.”

RM:

“What was the company’s biggest turning point?”

PG:

“Macmillan published my book Database Backed Web Sites in 1997. Bill Pease, an Environmental Defense Fund executive for whom we had done a project called scorecard.org (still running) as volunteers, insisted that we get it done before the book came out because he said that we would be too busy to take his phone calls afterwards. He was right. The book, plus some public lectures that I gave at Edward Tufte’s suggestion, enabled us to find customers very easily.

The early customers were critical as well, particularly as they were agreeable to letting us keep all of the rights to any software that wasn’t specific to their site. Hearst, Levi’s, Oracle, AOL, Hewlett Packard, and Siemens paid for us to get our bodies into an office and our servers into a co-location facility. It is amazing how far you can get by being straightforward with customers. I would open a negotiation with a Fortune 500 customer by saying “We don’t have any money so we need you to pay for the development of this module and that big server” and the customer would say “Okay.””

RM:

“You had a novel culture, for the time, which was that your programmers interacted with customers and went through the whole process; from seeing a problem, to coming up with a cost-effective solution. So you’re bringing on a generation of people who understand efficiency and responsibility for the final product. Looking back are you surprised that many more companies weren’t doing this?”

PG:

“Not really. Most corporate managers think that they have above-average management skills and therefore feel confident that they can run a command-and-control operation from the headquarters. I didn’t want to take on this level of management risk so I pushed profit-and-loss responsibility down as low in the hierarchy as I could. Separately, I had been the teacher at MIT of some of these young people and I wanted them to build skills that they could use throughout their careers. I wanted them to be able to talk to a customer, plan a product, lead a group, write up the results, etc.

It wouldn’t have been consistent with my role as a teacher to have taken these folks from my software engineering class at MIT and put them into a dark cubicle to just code all day. The proof that our approach was successful is, in my opinion, the great career success that most ArsDigita alumni have experienced. Most came in with great coding skills, but now they are also creating products, managing groups, founding companies, etc. I’m sure they would have gotten there eventually, but I like to think that their ArsDigita experience helped them get there a few years sooner.”

RM:

“There was a common aim which you adopted of making code simple, but these days everything seems so complex. Is this because when programmers come up against a problem, they don’t solve it but instead walk around it and invent another process?”

PG:

“It is hard to say why programmers are so drawn to complexity. Part of it seems to be based on experience. Young programmers have never had to maintain software that they developed a decade earlier, so they don’t understand about designing for maintainability. Young programmers are irresistibly drawn to creating new computer languages and frameworks (the Haydns!) whereas old programmers understand that we already have plenty of languages and being a virtuoso is more important (the Mozarts!).”

RM:

“You bootstrapped ArsDigita, put in the grunt work, and then way down the line accepted VC money. Was there a point mid-way when you thought ‘this really isn’t working out; they just do not understand the company culture’?”

PG:

“We accepted the VC money because people at ArsDigita wanted to go public and the underwriters told us that first we needed to have a venture capitalist behind us. Almost immediately the VCs decided that they hated me and they wanted me, as well as 4 of my 5 co-founders, out. Most of the disputes were based on a lack of common experience and vocabulary. The people that General Atlantic Partners and Greylock put on our board had been employees their whole lives. One had worked as a management consultant at Bain, and the other had been a middle manager at a bank. Their work lives revolved around making the boss happy, which might involve dressing in a nice suit and speaking in soothing tones. The customer could hate them, the shareholders could be losing money, but if the boss liked them, they would get promoted. Neither of these guys had ever held profit-and-loss responsibility. I, on the other hand, had always needed to think about the customer. The executives at HP and Siemens who hired us didn’t care about our clothing or whether we were good at smooth-talking while showing PowerPoints. They had thousands of people who maxed out in these areas within their own organizations. My focus was on getting the customer, keeping the customer happy, getting the customer to pay, not spending too much while doing all of this, and getting the customer to sign up for more work. This is stuff that the manager of any McDonald’s restaurant understands but a lot of people inside a big company don’t.

There were some direct “culture” issues, I suppose. The VCs were irresistibly drawn to models of success such as IBM. They said that I had set everything up wrong because it wasn’t how IBM did things. Programmers shouldn’t sell projects, gather requirements, code, keep the schedule, test, write up results, and sell the next project. Nor should programmers have P&L responsibility. The programmers should just code and report to the head of programming in the headquarters office. They hired professional sales people to sell (and report to the head of sales in headquarters), project managers to keep the schedule (and report to the head of project management in headquarters), and “client services” people to talk to the client after the sales person had moved on.

I objected shallowly by pointing out that this would require a tremendous improvement in management and accounting that we had never demonstrated. My deeper objection was that IBM was still in business with an excellent brand and billions of dollars in cash. If our customers wanted to hire a company to do things the IBM way they could simply hire IBM. If we tried to do everything the IBM way, we would probably end up performing worse than IBM because we didn’t have as much money or as many capable people.

But really the most reckless things that the venture capitalists did were in sales and product design. I had done all of the selling for the company. I wrote the books and the articles that caused people to learn about our product. I sat down at the conference table at the World Bank and got them to sign a $1 million contract with a company that was 1/100th the size of the vendors they normally dealt with. The VCs fired me before they had any proven means of selling other than me writing and talking. By the time they found out that a salesman in a shiny suit representing a company with $20 million in sales is outgunned by a salesman from IBM Global Services, they’d already sealed the company’s fate.

The VCs and the silver-tongued managers that they brought in were equally reckless when it came to product design. In the software engineering classic Mythical Man Month, Fred Brooks describes “second system syndrome”. Programmers faced with an existing “first system” that sells well and solves a lot of problems will write down 100 things that they wish it could do better/differently and then promise to solve all 100 with a big bang “second system.” Brooks says that the inevitable result is that the project will be late and that most of those 100 improvements will fail to be made. Once the founders of ArsDigita had been pushed out, the VCs let the remaining programmers do whatever they wanted and, as Brooks would have predicted, they came up with a glorious “second system” plan for the 4.0 version of our product. They told customers to stop adopting the 3.4 version because the new thing was just a few months away.

A year later, ArsDigita Community System 4.0 finally limped into public release and it turned out to prove Brooks right in almost every prediction. The new system was promised to be faster, yet the pages that were performance-critical, such as the discussion forum, ran as much as 100 times slower. The new system was supposed to have an API that enabled features to be added without anyone having to go into Oracle and alter a table by adding a column. This way customer installations could be upgraded without any customizations having to be reapplied, as was conventional with database-backed applications such as SAP. The first customer project using ACS 4.0, however, required the programmers to go underneath the fancy new API and alter tables. On balance, ACS 4.0 was so complex and took so long to learn that customers could get a project done faster by using no toolkit at all, i.e. just starting with whatever tools were delivered as standard with a Unix or Microsoft Windows server.

[In the years since ArsDigita, by the way, I’ve learned that my experience was fairly typical. At helicopter school at the Robinson factory in Torrance, California in March 2013, for example, I talked to a guy who had set up a fast-growing chain of IT schools in the UK. His business was acquired by one of the global leaders in publishing and for-profit education. After a year, the MBAs in suits had been forced to shut down the formerly profitable business. “It didn’t surprise me that they wanted to do a lot of things differently than we had,” he explained. “But it did surprise me that they never asked me or my wife a single question about how we had run the company.”]”

RM:

“On a different subject you’re well known as a Lisp programmer, is this something you picked up at MIT?”

PG:

“Yes, as a 15-year-old at MIT, back in 1979, I fell in love with the Lisp Machine, one of the world’s first personal computers. It had a big bitmap display, a keyboard with 7(!) shift keys, a mouse and a window system. Just like your desktop computer today except that the Lisp Machine was the size of a refrigerator, cost $100,000, and had to live in a machine room. The “console” on your desktop was connected via a coax cable feeding video from the backplane. The flexibility of programming this machine is, in some ways, yet to be matched. You could be viewing your source code in the Emacs text editor, position the customer next to a function defined by the operating system, type “meta-.”, and the source code for that function would appear in a new buffer. You could edit that function, type a single keystroke command to have it compiled, and the modified version would be installed and running immediately. (Note that I’m not sure such a system could survive today in our world of Malware. It might be a good thing that it isn’t so easy to make on-the-fly modifications to a Unix or Windows kernel!)”

RM:

“We’re finally seeing Lisp and Smalltalk being factored into modern languages. Some people argue that we’d be better off if we just threw out everything we’re working on now and went back to Smalltalk, Scheme and Lisp. Do you think that’s an option? “

PG:

“I would be happier, certainly, and I do think the world has been held back by the Tower of Babel that we have constructed. Why do we have C# and Java? Why are there 10 frameworks in Java that all do the same thing? Though it was a contested choice 30+ years ago, the database management world gets a lot more work done, I think, because almost everyone uses SQL.

Sadly, as a Lisp proponent, I think the verdict of the marketplace is clear on Lisp: it does not confer a huge advantage. If Lisp is so great, you’d think that programs written in Lisp would dominate their respective categories. But where is the popular DBMS written in Lisp? The market-leading word processor? The spreadsheet? The photo editing application? If all of the programs that you use every day are written in C, Java, SQL, Python, and PHP, does it make sense to get up on a soapbox to denounce those languages?

[Paul Graham talks about how his Viaweb application, which became Yahoo! Store, was successful because it was coded in Lisp. But roughly at the same time a friend of mine who was acquired into America Online built a very similar system, enabling small merchants to have an Amazon-like Web store that they maintained from a browser, using SQL and Tcl scripts running inside AOLserver. He did it by himself in just a few months and there is no evidence that he worked any harder than Graham and his Viaweb co-founders. If Graham enjoyed more technical success than most of his competitors, I would attribute that success to Graham being a better software engineer and/or working harder, not to Graham getting a huge boost from Lisp.]”

RM:

“For the people who are reading this article and are going to be writing some of the software of the future, is there a way of avoiding the painful historical warts? Is there a way we can be smarter? Or is it just the nature of evolutionary design?”

PG:

“The most painful historical wart is programmers working on tools for other programmers instead of working on applications for customers and users. If Lisp programmers had built an application to manage a car dealership, a photo editor, or a spreadsheet for Microsoft Windows, instead of the 100th implementation of Lisp itself, the language would probably be a lot more popular (the mostly true joke is that at least 50 percent of Lisp programmers work on Lisp compilers).”

RM:

“As someone with an MIT background, you know that academic computer science is very mathematical. How important is it for working programmers to understand the maths in Knuth as opposed to flipping through Knuth’s work picking the best algorithm and implementing it?”

PG:

“I try to remember that there is always someone (anyone?) in Russia or China who is smarter than I am. So the important thing is not that I can do everything myself, but that I know when I’ve reached my limits and how to collaborate. An algorithms expert as a consultant or design reviewer can be a huge asset and a basic course in algorithms should be sufficient to be able to talk to that person (i.e., work your way through Cormen, Leiserson, and Rivest’s Introduction to Algorithms and then stop, unless you have developed a passion for the material). Andrew Grumet and I wrote up design review to try to encourage more companies, especially smaller ones, to make use of external design reviewers. I don’t think that the idea has caught on though. Programmers can’t seem to resist trying to do everything themselves.”