Closer To The Ideal

I am curious about Mobicules weblog. Some of their posts are self-serving, but they seem to be trying to get some real information out, which is more than what I’ve seen so far from most of the sites of Indian firms that I’ve looked at. How should I read this post on which platform to use for a massive social site that can scale to tens of millions of users?

ELGG: Due to a very flat and normalized database structure, the only way to scale horizontally with ELGG is to duplicate the database using MySQL replication on multiple servers. The negative with this approach is that it ends up duplicating the complete database, with the result that each machine running a copy of the replicated database will have to be very powerful server, rendering the solution expensive. (MySQL clusters is a standard way of doing it)

Drupal: Similar problems as ELGG with Drupal, but database is not as flat and normalized as ELGG. Scaling up in a similar manner as described for ELGG wity MySQL clusters would probably be cheaper with Drupal.

Symfony: Allows us to use a custom database structure. We can design the database and replicate it as we like. Symfony also uses its own query/object caching mechanism, which is efficient. As an example, the Yahoo bookmarks site supports 20 million users on Symfony.

…Our recommendation in a case where you are looking to scale up to 10s of millions of users would be write everything from scratch (and not use a ‘platform’ like ELGG/Drupal), that allows you to customize and tweak anything and everything. Symfony seems to have a good reputation for enabling creation of very large websites, and so, we would recommend using Symfony as a framework.

I actually agree with their conclusions.

When I wrote “How much do websites cost” I made this comparison:

Imagine you hire a carpenter to build a deck on the back of your house. You tell the carpenter that you want the deck to be 10 by 20 feet, and to be built of oak. The carpenter goes out and buys the needed wood. Now you change your mind, and you tell the carpenter that you want the deck to be 8 feet by 18 feed, and to be built of mahogany. The carpenter has to charge you for all the oak that they bought. Changing your mind is expensive!

When it comes to home renovations, people have an easy time understanding why changes drive up costs. However, for some reason, when it comes to the web, people lack this understanding. It is true that the web is a fluid medium, but still, once work commences, the time invested needs to be paid for. If you hire a web design firm and tell them “I want a simple site that lists the services my company offers” then they will start to build one kind of website. If you change your mind and say “I really need a site where everyone in my company can document their work, so I can track what they are getting done” that is a completely different site and needs completely different code. The work on the first site would be thrown out (but you would need to pay for it) and work would begin on your second idea.

It is hard to get this across to clients, so I love this: If architects had to work like software developers.

Dear Mr. Architect:

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

[Update:]

One reason I prefer design lead development is that it reveals assumptions and makes things visually explicit. No one gets everything right the first time, therefore there needs to be a way to iterate through ideas, without great expense. The client and designer and developer need to avoid the illusion of agreement that comes from working with words. Thus, it is better to iterate with visuals. The mockups should be the source of agreement. You want to iterate through a lot of ideas fast, so you can fail fast, so that you can get to success fast. Iterative design processes help lower risk.

Changing your mind is expensive. Also inevitable. The goal has to be to keep costs as low as possible while experimenting with different ideas.

I recently oversaw a project that had me working with a distributed team (in the US, Europe and India). The same project also worked exclusively with independent contractors, whose work was hired on an assignment basis. The work was for a new web-startup. I have some concerns about such an arrangement being used for a new, innovative project. I’m going to attempt to explain my concerns in this essay.

First, I’ll talk about using freelance, independent contractors for a web start-up. The seeming advantage of having no permanent employees is that the operation has no fixed costs. An advantage? It depends. If you really want to avoid all fixed costs, simply close your business. Being in business means having expenses, the real issue is whether you are making a profit – does the labor you hire help you make more money than the cost of the labor?

The project I oversaw moved slowly, and some of the slowness can be attributed to the freelance nature of the labor we hired. The programmers would do whatever we asked them to, and they all did high quality work. However, because we made no long term commitment to them, they of course had to keep busy with other work. Sometimes we needed them but they were busy with their other clients. Also, they were not part of the conversations we were having in New York City, so they lacked a broad overview of the project and its goals, so they could not easily take the initiative to move ahead on their own.

If a project has no particular deadline, or if it is simple, then working with independent contractors is a great way to keep fixed costs low. However, if a project is suppose to move fast, or if it needs to achieve certain deadlines, and especially if it is very complex, then I would recommend against the use of this kind of arrangement. For fast moving, complex projects, you need full-time, committed programmers.

Now I’ll offer some thoughts about agility, and the importance of physical proximity.

Agile practices have 2 main hopes:

1.) to allow a fast-forming team to quickly become highly-productive.

2.) to control costs by ensuring discipline in regards to goals and deadlines.

I used the word “hopes” instead of “goals” because the ultimate aim of agile practices is more of an ideal to be aspired to rather than a reality that can be achieved, and by that, all I mean is that we are constantly learning more about what these practices truly mean, and in the future we can reasonably hope to do better than we are doing today. I’m speaking for the entire profession of computer programming when I say this.

I am in the United States, in New York City. I’ve been working on websites since 1996. I’ve worked on many small teams, and over the years I’ve used some agile practices, such as frequent iterations, frequent in-person consultations with the client, and unit tests. When I started on this last project, I first thought it would offer the chance to experiment with a fuller range of agile practices. However, I came to realize that most agile practices depend on physical proximity. The programmers need to be able to meet, preferably every day (”every day” in the sense of casual conversation, not “every day” in the sense of “let’s have a formal meeting”). Consider some of these practices:

1.) pair programming (two people looking at the same screen, checking for errors)

2.) the use of index cards to map objects

3.) stand up meetings (meetings kept short and lively because everyone is standing)

None of these make any sense if the programmers are in different countries.

I’d also add code reviews. One can do a code review at a distance, but I think in person is much more effective. And code reviews don’t make much sense when you are working with independent contractors. Code reviews are meant to develop each programmer’s long-term abilities, and also they are useful for helping the whole team agree on certain programming habits. But one would have to have a long-term relationship with the programmers before doing such a thing would make sense.

Programming is an art, and art needs passion. Many agile practices are aimed at soliciting a greater emotional commitment from the programmers. I might write “For an agile project to go well, the programmers need to emotionally commit to it” but that isn’t quite right. What would be more correct would be “For an agile project to go well, the programmers need to emotionally commit to their own professional ideal.” That is, they need to care about the craft of programming. They need to be constantly pushing themselves to always be better programmers.

I would never argue that agile practices are needed on every project. If a project is routine, then long-distance, non-agile practices might be perfect. For instance, suppose you decide to launch a new online magazine. After researching your options, you decide you will use WordPress as the software that powers your site. I’d suggest you find a good designer, local to you, and work with them to come up with the design. Once you have the design, the rest of the process is mundane. You could certainly hire a team in India to install WordPress and implement your design for you. And you would not need agile practices for such a project. In fact, you do not even need great programmers for such a task. Mediocre programmers can do a reasonable job with tasks that are standard, routine and mundane.

However, I would argue that agile practices are needed at projects that need to be fast moving (this would include most start-ups), or at any project where the aim is to create something altogether new and unique. If your project is venturing out into the great unknown, if you are going where no one has ever gone before, you will need a team of excellent, committed adventurers to go along with you.

Let’s look at the history of agile practices, going back centuries.

In the 1990s, DARPA invested some money in agile research, which lead to such books as that by Goranson: Agile Virtual Enterprises.

Goranson looks back at the whaling industry of the mid-1800s and examines how 2 small towns in Massachusetts were able to capture 90% of the whaling industry, when most of the actual hunting was done in the South Pacific. He found that the patterns of hiring and team building had much in common with what start-ups aspire to nowadays – a tight-knit, fast-forming team of highly competent professionals held together by a commonly understood body of professional ethics and expectations.

Goranson emphasizes the role of geographical concentration (and therefore physical proximity), to the evolution of culturally unique traits, leading to competitive advantages:

Geographical and professional isolation allowed for the evolution of a unique and very effective system which for many years put a brand new, fairly high risk/high payoff, virtual enterprise in the water at the rate of one every two weeks. The return of each whaling expedition triggered the formation of another. It was considered an invitation to bad luck to reuse the same combination of partners, so during the six to nine months it took to recondition the ship for another voyage, the owner of the boat assembled a new group of key players who would join him in setting up the basic physical and social conditions needed for a successful venture.

The primary partners required to launch a voyage consisted of a ship owner, an insurer (of the ship cargo), a provisioning financier to supply the expedition with food and other consumables, a captain, and often a manufacturer who agreed to buy the oil at a set price. This component of the partnership was formed in the first couple of months, the partners being determined partially by availability.

A month or less before the ship was ready to sail, a secondary group of partners, the crew, was formed. They shared a distinct cultural background; almost none of them had, or would ever, serve in the navy or the merchant marine. This professional distinctiveness, coupled with an intense geographical concentration, fostered the development of a unique culture based on the virtual enterprise.

Goranson uses the word “agility” to refer to fast forming supply chains, and also (relatedly) the ability to overcome the administrative costs that might keep a new supply chain from forming (in the early 90s, when DARPA funded Goranson’s work, one problem seemed especially prevalent: the fact that the most innovative technologies in America were being developed at small start-ups, and yet large Fortune 500 companies were having difficulty integrating small start-ups into their supply chains, because of the administrative hassles of developing relationships with a multitude of small companies). He uses the word “virtual” to refer to an organization that is project-specific and not meant to last. For instance, in the modern context, the best examples of agile, virtual enterprises are in the movie industry. Each movie is its own independent business, and the production of each movie entails the fast formation of a team of highly competent professionals who understand they are being hired to work on a specific, time-limited project, which will disband as soon as the project is done.

Whaling ships and modern web start-ups share certain traits::

Every voyage included a team of skilled craftsmen – carpenter, blacksmith, cooper, and a sailmaker (often a boatwright, a rigger and a cook were also in this class) – whose combined expertise allowed the enterprise to respond effectively to a broad range of situations. Each of these professionals, along with the tools, supplies, and sometimes apprentices they brought abroad, formed an essentially self-contained business which was integrated into the enterprise as a whole. In these cases, it was not just the person who signed up for the voyage, but their business. From the shipowner to the cook, everyone was paid with a pre-arranged percentage of the take.

In other words, every ship was its own little agile, fast-forming start-up.

Goranson’s use of the word “agility” is somewhat different than the way the word “agility” is used by its proponents in the software industry, but the meaning of the word overlaps for both groups in the sense of “the ability to get supply from a new source quickly”. Consider the words of the Agility Manifesto:

We have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

With only minor tweaks of the wording, you could use the above as a statement of the professional culture that pervades Hollywood. The emphasis is on doing what is necessary to get something working into production fast. By contrast, the slow moving process of low trust, heavily documented, laborious negotiated, carefully vetted contracts are anathema in this context.

(Stephen M. R. Covey has a written a book called The Speed Of Trust, which does an excellent job explaining how much a project speeds up when the participants can trust each other, and therefore how important it is to work toward facilitating the long-term development of trust in any business relationship.)

Goranson emphasized that one of the legal traditions that the whaling industry and movie industry share is a very strong reliance on verbal contracts, as opposed to written contracts and detailed documentation. Goranson points to the bankruptcy of Kim Bassinger as an outstanding example of the importance given to verbal contracts in the movie industry. (Bassinger met some producers for dinner to discuss the possibility of her starring in their movie Boxing Helena. She promised, over dinner, to star in the movie. When she later backed out of her promise, they were able to sue her for $8 million.) The Agility Manifesto de-emphasizes contracts, but still puts a heavy emphasis on the importance of verbal communication, a point made clear by “Customer collaboration over contract negotiation”.

Goranson emphasizes the role that geographical concentration played in allowing this culture of virtual enterprises to flourish. I believe that geographic concentration still plays the predominate role in allowing the continued evolution of unique agile practices.

I’ve had it suggested to me that the cheapness of overseas programmers (in places like India) can speed a project up, simply because, since they are cheap, you can hire a lot more of them. This is flatly contradicted by Fred Brooks thesis in The Mythical Man-Month. When the System 360 project was running late at IBM, Brooks tried to speed up the project by adding more programmers to the team. But he found that the additional programmers actually slowed the project down. Each new programmer became one more person who needed to be kept up to date with the latest documentation – and every few additional programmers required that a new manager be brought into the project to manage them. The growing complexity of communication across a growing mass of workers helped to slow the project down, rather than speed it up.

In this sense, the cheapness of overseas programmers actually encourages bad habits. Because they are cheap, you may get tricked into thinking that you can hire a lot of them. But the more you hire, the more time you will need to invest trying to keep everyone unified in their understanding of what the code is suppose to do. And after a certain number, you’ll need to start hiring additional managers.

If you are a project manager, and you rely on the cheapness of your programmers to keep a project’s costs under control, then you need to fire yourself. There is only one correct way to keep costs under control, and that is through disciplined focus on goals and deadlines. Agile practices have evolved to make it easier to keep complex projects on track. To the extent that geography matters to agile practices, then geography matters for the goals and deadlines of your project.

Nicole Radziwill approaches this subject from a different angle, but she makes a similar point about the importance of geography:

Space does matter. We know this when we are designing facilities and plant layouts, for example, because one of our common considerations is to minimize traffic between areas and departments. More often than not, we do this to minimize the time spent moving people or equipment around a plant, so that time is not wasted. But the same concept could apply to our supply chains. Why aren’t we minimizing the time that components or goods spend traveling through the supply chain, when it could lead to reductions in energy costs? Furthermore, why aren’t we shortening our supply chains to strengthen local and regional businesses, and train the next generation of skilled workers (who can actually do something useful for the regional economy)?

The logic has been something like this: energy is cheap, therefore transportation is cheap, and transportation is easily available and accessible through third-party providers like FedEx and UPS. But I can’t shake the feeling that “supply chain status quo” is not good for quality in the long-term – because it encourages us to source the products and components that are most affordable, rather than the ones that might help us cultivate a quality consciousness in our local areas.

To offer a partial answer to the question that Nicole poses, I think the reason why products get sourced to where they are most affordable (at the current moment, in the short term) is that people tend to fear losses more than they value potential gains. There is an abundant literature on this subject. In regards to sourcing, buyers go with what is cheapest in the short-term, rather than developing long-term innovations that might lead to much greater gains in the future. Consider:

Prospect theory… argues that people center their expectations around a variable and moveable reference point. The reference point is most easily thought of as the status quo, though it is not always so. In most situations, people are more likely to ensure that they preserve their current situation, than to risk losses by seeking potential improvements. Indeed, people tend to sacrifice a great deal in order to maintain their current situation. As Levy notes, “people tend to be risk-averse in choices among gains, but risk acceptant with respect to losses.” This is often the problem in intractable conflicts; the risks required to resolve the conflict seem much too great compared to the potential losses. This sort of framing is what leads ultimately to hurting stalemates. Loss-oriented framing is, ultimately, this tendency to minimize losses while missing opportunities to improve one’s situation.

The status quo of any culture, in the short-term, can be regarded as an under-developed blandness, relative to the unknown brilliance of some unknown future innovation. It takes a leap of faith to believe in that unknown future brilliance. It is easier, and safer, to go with what is cheapest in the short-term. This is cowardice, but it is extremely common. True business leadership is rare.

In terms of developing some unknown future brilliance, I’m thinking especially of those cultural traits that, in part, give rise to comparative advantage. There is, at this point, a mountain of literature about the advantages that agile teams have when it comes to fast-forming, fast-moving projects. Agility is a cultural innovation that deserves further refinement, and each nation, depending on its legal traditions and its labor laws, is going to develop agility in a unique direction. The future development of these potential innovations is undermined by the extended supply chains that send work to distant parts of the world. I’m arguing that, just as Goranson stressed geographical isolation as playing a role in the evolution of a uniquely competitive culture in Massachusetts, then the dispersal of work from a geographic center must lead to the opposite – the dissolution of uniquely competitive cultural traits.

I can imagine someone reading this essay and raising certain objections. What about Linux? What about Apache? Certain open source projects have been successful with teams that are scattered all over the world. But then, these were not fast moving projects. Teams that never meet in-person can become highly productive, but it takes years. And by the time these projects hit their strides, much of the core team had, in fact, traveled to different countries and met each other in-person.

One other fact argues for the importance of physical proximity. For a team to be highly productive, it needs to have both high levels of communication and high levels of trust. Body language is important to trust. In a normal, in-person conversation, the bulk of the communication is non-verbal. Below I’m going to quote from an article that is aimed at teaching salespeople how to make more sales. On a start-up, the team members are not trying to sell products to each other, but they are often in the position of having to try to sell a given strategy to each other. One team member may feel that their site should be pitched to consumers, another team member may feel strongly that the site needs to be pitched to businesses. The success of the start-up depends on all of the team members being to able to listen to all points of view, take in the maximum amount of information and opinion, and reach the best decision.

It really doesn’t matter how knowledgeable you are about your product line or how many closing techniques you have mastered, unless you earn your prospect’s trust and confidence you’re not going to make the sale.

…Body language is a mixture of movement, posture and tone of voice. Research indicates that in a face-to-face conversation, more than 70 percent of our communication is nonverbal.

Our body language reveals our deepest feelings and hidden thoughts to total strangers. In addition, nonverbal communication has a much greater impact and reliability than the spoken word. Therefore, if your prospect’s words are incongruent with his or her body language gestures, you would be wise to rely on the body language as a more accurate reflection of their true feelings.

On a slightly humorous note, I’d like to offer a movie review. The best movie ever made about an agile, virtual enterprise was Akira Kurosawa’s 1954 movie, The Seven Samurai. Of course we need to translate the movie into business-speak before the comparison becomes clear. I’m only partly kidding when I write this. I really do believe this movie offers a good example of some of the above ideas.

In the opening scene, we meet the client (poor village farmers). We then come to see their problem: bandits who plan to raid the village as soon as the harvest is in. The villagers then go to a big city to hire a contractor who can solve this problem for them. They meet Kambei, a samurai. Though the villagers can pay very little, he takes pity on them and agrees to help them. He therefore steps into the role of project manager. He must then assemble a team, and this part is pure agile enterprise in practice. The city is full of many samurai, and out of this sea of potential recruits, a group of 6 is selected. These are highly skilled workers with a strong emotional commitment to their own professional ideal – that is, they all strive to be the best samurai that they can be. The 7 samurai then set out for the village. They almost instantly form a tight-knit, highly cohesive team, because they share a commonly understood body of professional ethics and expectations. The enterprise is “virtual” in the sense that Goranson uses the word – it is project-specific, and will disband as soon as the project is complete. At the village, the samurai work in close consultation with the client to ensure the goals of the project (the defense of the village). Finally, after a decisive fight, the goals of the project are achieved – the bandits are defeated. The client is happy. The surviving samurai then disband.

In this movie, the samurai are recruited in the same fashion as sailors might have been recruited for a whaling ship, or the same way that a computer programmer might be recruited for a web start-up.

To recap, my current experience teaches me that:

1.) Agile teams should be small (as per Brooks).

2.) They should meet in person several times a week.

3.) Everyone on the team must be highly competent.

4.) Everyone on the team must be emotionally committed to their own professional ideal.

5.) For the duration of the project, everyone on the team should be full-time

Furthermore, on projects that aim to be unique or innovative, or on projects that are complex, or on projects that need to be fast-moving, I will be discouraging clients from these practices:

1.) part-time, independent contractors

2.) distributed teams, with workers geographically dispersed.

One last point, unrelated to the rest. A number of people have said to me that they feel the cheapness of overseas workers (in places like India) is driving down wages in America. I do not believe this is true. Wages in America have declined over the last 40 years, but that is because the American people have themselves become unwilling to invest in their own country. Consider the fact that in 1955 the average middle class family saved 17% of their income, but in 2000 the US savings rate hit 0%. Wages will decline in any nation that does not invest in itself. By contrast, consider Germany, which has a high investment rate. Not only does Germany have higher average wages than America, it has also had more economic growth over the last 30 years. And right now China is saving and re-investing 40% of its income. I do not know a single American family that saves 40% of its income. Most of my friends, even those with college educations and good paying jobs, only save 10% or 15% of their income. It is wrong for Americans to first engage in an orgy of over-consumption and under-investment, and then blame poor nations like India and China for the obvious problems that must result from such reckless behavior.

One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:

1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.

2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.

It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.

Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.

(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too

I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.

(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming

But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.

(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity

If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.

Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:

(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done

I recall somewhere around 1995 there was a lot of talk about the Internet being a disruptive technology that would lead to the bankruptcy of a large number of older, obsolete firms. The bankruptcies did not materialize with the speed that people had expected, so somewhere around 2000 there were a number of articles explaining how the web wasn’t really a disruptive technology, instead, it was an enabling technology.

But in truth, it was a disruptive technology. And the bankruptices are finally beginning to arrive.

Earlier in the month, I was thinking out loud about the future of publishing online, especially where the news was concerned. Others are having a similar conversation:

Internet news is a classic disruptive technology. At its outset, it was simple, dirt cheap, and in many ways inferior to established journalism. But it improved over time, and once it began to rival traditional journalistic outfits in quality around the middle of this decade, the “dirt cheap” part of the equation began to dominate. When your competition can produce a roughly comparable product for a small fraction of the cost, your days are numbered.

But here’s the really important point that Christensen made that is often missed in these kinds of discussions: it’s often close to impossible for an organization built around an older technology to retool for a new, disruptive one because their cost structures just don’t allow it. The New York Times is an expensive place to run. It’s got writers, editors, typesetters, delivery trucks, an ad sales force, a big building, travel budgets, and so forth. In order to recoup those costs, they have to make a certain amount of revenue per unit of output. The institutional structure of the New York Times makes it almost impossible for it to produce news the way TPM Muckraker or Ars Technica do. The need to make payroll and cover their rent makes it almost mandatory for them to focus on their traditional core competencies because even as those markets shrink they still offer better margins than the emerging businesses.

You can set up a website for free. And Google has spent over $10 billion on its website. So it is safe to say that most websites cost between $0 and $10 billion. How much will your site cost? There is no way to be certain ahead of time, but we can offer some advice.

 All websites fall into two categories:

 1.) they offer content

 2.) they offer a service

 Examples: A blog about computers offers content. A site that lets you put dates into a calendar is offering a service. Many of Google’s websites offer a service: email at Gmail and spreadsheets at Google Docs. If you have an already existing company and you’d like to put up a few pages describing (or selling) your products/services, then you are envisioning a content site. If you’d like to do a magazine style site, then you are still considering a content site.

Price Ranges

 Different kinds of projects have different price ranges. We can only offer very rough guidelines as to the kinds of prices we’ve seen for previous projects. Talk to us about the specifics of the project you are thinking of and we could probably offer you a better idea of how much you need to be prepared to spend.

 1.) A personal or company blog, set up using a free service: $0 (or whatever value you place on one hour of effort). But to keep this going and acquire traffic will probably cost thousands of dollars, at least in terms of your time.

 2.) A small company site that has 5 to 10 pages describing the products/services offered by the company. $500 to $2,000 depending on how prepared you are, and also on how clear in your own head you are about what you want. Disorganization and changing your mind are both expensive.

 3.) A company site describing the products/services offered by the company, and operated by software that allows the staff at the company to continually update the content on the site: $2,000 to $20,000.

 4.) A company site that both describes products/services and also offers some kind of software service. For instance, a real estate firm might allow users to look up listings based on zip code or a manufacturer of skateboards might allow users to design their own skateboard, mixing and matching those variables that can be customized. $10,000 to $40,000 depending on the complexity of the software to be developed. 

 5.) An online store that sells digital downloads of songs or videos: $25,000 to $100,000 depending on the variety of prices/royalties you want to support with your suppliers and how much marketing you want to do. If you want original technology for handling the songs or videos, you might easily burn through another $50,000 on computer programming.

 6.) A company wiki so the staff can document a particular kind of information – perhaps support information for your customers, or technical info for use by your sales people, or a human resources directory aimed at answering common staff questions. This should be on the low end of $2,000 to $30,000. The biggest variable is whether you need some special, custom feature. If you can use unmodified, off-the-shelf software, you can keep things quite inexpensive. But as soon as you get into custom programming, the cost will sky-rocket.

 7.) An online magazine/blog meant to dominate a particular niche: $25,000 to $100,000. For instance, you might want to cover fishing in Alaska. You’ll probably want to establish commercial relationships with 6 or 7 avid fishermen who are also known to be good writers. They might each post something once a week. You might spend $50 or $100 a week on each of them, depending how much news they can commit to delivering. You should also hire a lawyer to create an agreement you want the writers to sign.

 8.) An information resource that, to succeed, must be the best: $500,000 to $5,000,000. One fellow came to us and said “I have $20,000. I’d like to build America’s largest database of foreclosed properties.” We replied: “This is obviously a great idea and, if you can pull it off, the site will surely be a great success. But you should really go out and raise $1 million to get started. You’ll need a team of programmers working constantly to get data into your database, you’ll need a lawyer to work out multiple deals with your sources of information, and you’ll need national marketing. You’ll probably need $2 or $3 million over the first two years, but you probably should not even start unless you can raise $1 million.” The other possibility is to start small and build a database of foreclosed properties for a single metropolitan area. If the site is successful, it should be easy to raise the money to go national.

 9.) An online social network for some demographic niche, for instance, new moms, or hockey fans: $20,000 to $500,000. You can keep costs low by using off-the-shelf software, but you will probably want to customize the look and feel of the site, for the purpose of branding. The more services you offer (upload photos? upload videos? search for other users in the same geographic area?) the more expensive the programming will be. If your target demographic niche is risky (perhaps you want to run a site that offers services to recovering drug addicts) then you’ll want to hire a lawyer to write an air-tight Terms Of Use agreement. Lawyers are expensive, so this will drive up your start-up costs. Also, you’ll need a budget for marketing or you’ll never acquire any traffic.

 10.) A completely original idea for a software service that no one has ever thought of: price unknown. There is a rule in software design that the more original the idea, the harder it will be to accurately estimate the cost of the project. Robert L. Glass has written several books on why this is so. Check out his book “Software Runaways: Monumental Software Disasters”.

 Below are some guidelines about factors that will effect the cost of your website.

How does a site acquire traffic?

 If you are considering a content site, then the site’s most urgent need, and one of your biggest expenses, will the be the effort to acquire traffic.

 Rule #1: a content site, to be successful, needs new material everyday.

 Rule #2: do not underestimate how utterly demanding it is to provide new material daily.

 Rule #3: if you do not yet have the amount of traffic that you want, re-read rules 1 and 2.

 Rule #4: if you find yourself wanting to ask something like “Does the word ‘daily’ include the weekends?” then re-read rule 3.

 Rule #5: providing text-based content is cheaper than providing video, therefore, even if you are focused on video, your site will need at least one writer to provide high-quality, professional content that can act as filler between the videos. Or you need a big budget.

 Rule #6: flows of traffic on the web have become increasingly rigid and hard to change, therefore more effort (and expense) is needed to acquire an audience.

 Rule #7: it is extremely difficult to transfer an offline audience to an online destination. Even authors like Lee Stringer, who’ve spent months on the New York Times best-sellers list, attract little attention when they blog online.

 Rule #8: when you hire a writer who has an already existing online audience, you usually capture a substantial portion of their readership.

 Rule #9: the previous two rules imply that hiring an online writer who already has traffic is a better way to capture traffic than hiring an offline writer, even if they are a star. Sites focused on sales will generally want to aggregate news relevant to whatever is being sold.

What drives software development costs?

 If you are considering a software site, be aware of what drives the costs of software development.

 Rule #1: the more customization you need, the more expensive things become

 Rule #2: the bigger the project, the more customization you’ll need

 Rule #3: when programmers invent things from scratch, the number of bugs increase, and the amount of time that will have to be spent beta-testing

 Rule #4: if you want original technology, then your programmers will need to invent things from scratch

 Rule #5: to control risk, all programmers must live by the “Hit By A Bus” rule, which is, if they are hit by a bus and killed, with a project only half-done, another programmer should be able to easily take their place

 Rule #6: the more original the technology, the harder it will be for other programmers to understand the code (creating possible violations of the “Hit By A Bus” rule)

 Rule #7: cost, risk, complexity and understandability (of the code) can be controlled by the use of a software “framework”. Some of the popular frameworks for web development include Ruby On Rails and Symfony (written in PHP)

 Marketing

There are two main approaches to marketing a site:

1.) The Big Bang (hire a PR agency, buy lots of ads, make a big splash)

2.) Slow and Steady (produce quality material/service, rely on word of mouth)

Slow and Steady is always more cost effective than the Big Bang approach, so the Big Bang approach  should not be pursued unless you have money to burn and you are in a great hurry.

Success

The success of your website will depend on two things:

1.) Clarity

2.) Discipline

In some ways the web is a revolutionary new medium with new potentials and new dynamics, but in many other ways running a website is exactly like running any other kind of business. You must have clarity about what you hope to achieve, and then you must have the discipline to stick to your plan. You should be able to describe the goal of your website in one sentence (and if you can’t, then how will your visitors ever understand what the site is for?). If you are unable to sum up your goals when you are speaking with us, there is a good possibility that you haven’t yet achieved clarity (but we would love to talk to you about your idea – we may be able to help you achieve the clarity you’ll need).

An entrepreneur is in trouble if their description of their idea for a new startup comes out as a confused run-on sentence, such as this: “We’re going to be an agency that puts ads into videos and we’re also going to be funding new video artists with our ad money, because we believe in the possibilities of nurturing these new talents, and we’re going to be an aggregator that accumulates the best new talent in video and our software will offer unique technology to advertisers, such as the ability to keep track of exactly how long each viewer watches each ad.” And yes, this is similar to something that was actually said to us. There are at least 4 different business ideas in that sentence, which is at least 3 too many. (If you have an existing business with many divisions, it is fine to have a site that reflects the diversity of those divisions, but a startup needs to be more focused.)

Clarity controls costs. If you are unsure of what you want to do, you will probably change your mind half way through the project, and that will lead to additional expense.

Imagine you hire a carpenter to build a deck on the back of your house. You tell the carpenter that you want the deck to be 10 by 20 feet, and to be built of oak. The carpenter goes out and buys the needed wood. Now you change your mind, and you tell the carpenter that you want the deck to be 8 feet by 18 feed, and to be built of mahogany. The carpenter has to charge you for all the oak that they bought. Changing your mind is expensive!

When it comes to home renovations, people have an easy time understanding why changes drive up costs. However, for some reason, when it comes to the web, people lack this understanding. It is true that the web is a fluid medium, but still, once work commences, the time invested needs to be paid for. If you hire a web design firm and tell them “I want a simple site that lists the services my company offers” then they will start to build one kind of website. If you change your mind and say “I really need a site where everyone in my company can document their work, so I can track what they are getting done” that is a completely different site and needs completely different code. The work on the first site would be thrown out (but you would need to pay for it) and work would begin on your second idea.

Assumptions to Avoid

Many of our clients have started web projects with (sometimes unconscious) assumptions that, in the end, caused them unnecessary anguish and expense. These are the twelve most common mistaken assumptions that we’ve seen:

1.) I (the client) should be all things to all people.

2.) Feature fetish: “The more features I add, the more popular my site will be.”

3.) If I build it they will come (also know as, “If I have a clever idea, I won’t need a marketing budget, because the site will get mentioned on TechCrunch/Oprah/popular blogs/the local newspaper”).

4.) If one person offers a single piece of off-hand, poorly thought-out, casual feedback, we will immediately re-design the entire site to comply with their feedback. And then tomorrow, when someone else offers some casual, poorly thought-out feedback, we will do the same. And then the next day…

5.) The idea for my site is unique, therefore completing it quickly is urgent. If we are not the very first site that uses this idea, then we will fail. My idea is so good that others will soon imitate it.

6.) Things that move or blink grab my attention, therefore if everything on the page moves or blinks, we will have a truly attention getting site.

7.) Text is boring.

8.) The more unusual and unique the interface, the more interested people will be.

 9.) Websites are fluid so any problems that arise can probably be fixed in a day or two.

 10.) If my site starts off with a narrow focus, then its prospects for growth will be limited. People will pigeon-hole it and I won’t be able to add new content subjects later.

 11.) I can spend my money at an unsustainable rate because 6 months from now my site will be bringing in a huge profit.

 12.) I have no experience on the web, but I have uniquely creative ideas, which I think will be enough for me to build a successful online business.

Disorganization

Disorganization will cost you. If you hire a web design firm to build a site for your company, then they will need certain things from you, such as the company logo, and a description of what you are selling. If you are weeks late delivering these things, you inflict delays on the web design firm. Often, the contract you sign will specify some kind of penalty for the delays you cause. A common penalty is to have your project moved to the bottom of their priority list – which could delay your web site several months (this is how client lateness was handled when we worked at Category4). While there is some text and images that the web design firm can provide on their own, there is usually some core material that only you can provide – a description of what you sell being a good example. Have your images and text ready.

Brainstorming

A gold rush mentality has come to shape expectations of the web. Many people now have the mistaken idea that if they can simply come up with an idea creatively unique enough, they can attain great wealth on the web.

Organizations, like people, can suffer pathologies, and the one we’ve seen most with web ventures is what we call “the endless brainstorm”. While it is fun to engage in a brainstorming session, and while this can be a vital tactic to maintain the innovativeness of an existing business, constantly seeking a new idea can be a waste of resources for a venture that has not yet launched.

We once watched, with a certain degree of horror, as almost $1 million dollars were spent on what turned out to be a year long brainstorming session. Many good ideas were hatched during that year, and each idea was pursued for a few weeks, then abandoned once the first difficulties were encountered. The entrepreneur in this case wanted to find an idea so unique that he would face no competition in the field – but this is not the way the business world works. Generally, any good idea will attract multiple efforts, so competition is to be expected no matter what the basic idea is.

We have a friend who worked at AOL during the early days, and who has since worked with several startups, both successful ones and failures. One of the many good pieces of advice he gave us was: “In a startup, ideas are a dime a dozen. Anyone working at a startup will have 2 or 3 great business ideas a week. The greatness of the idea doesn’t matter. All that matters is execution.”

One of the most common confusions that arises from brainstorming is the desire to build a site that offers both unique technology and unique content. In our opinion, a small firm (less than 25 employees) can either create great content or it can create great software, but never both.

Population dynamics

For the last 3 or 4 years we’ve had clients come to us and talk about building up sites using content contributed by users. This can be a great strategy, but you will find it tough to elicit the kind of participation you seek, so if you are targeting a narrow niche, be aware how the population dynamics will work against you. Not long ago a potential client came to us and said “I’d like to build a video site focused on my hometown of Charlottesville, Virginia, and I’d like most of the content to come from users.” We put together the following estimates to demonstrate the difficulties he would face during the first 6 months of the project.

500,000 people

In the whole extended region (Charlottesville and the surrounding 7 counties), there is only about 500,000 people.

250,000 people

Since your project is focused on video, only those people with broad band connections to the Internet will be able to view your site. And only about half the population has broad-band access to the Internet.

200,000 people

It is reasonable to assume that very small children and many senior citizens will be unable to use your site. Therefore, at most, your target audience will consist of 200,000 people.

20,000 people

If you have some really amazing marketing, maybe 10% of the target population will come check out your site during the first six months.

10,000 people

Assume you’ll have a 50% bounce rate, meaning half the folks who visit you may never visit you again. That is standard. That takes us down to 10,000 people.

100 people

Do you want users to contribute material? That is a high level of interaction, and most sites only get that kind of response from about 1% of their audience. That takes you down to 100 people. Can you engineer your business model to work with 100 active users?

Humility

No one can accurately predict where the stock market will be in 2 years (otherwise they’d already be a trillionaire). For almost the same reason, no entrepreneur can fully know where their startup will be in 2 years: there are simply too many variables. It is important that innovators be humble about the limits of their knowledge. A fantastic insight in one area can carry you a long way, but it will have to adapt to the millions of small facts that will arise, almost daily, and shape the history of your insight as it passes from concept to reality. If you launch a startup, the odds are against you from the start, and you’re only hope of success is to remain open minded about what might work.

If your startup eventually succeeds, it will likely be for reasons you did not initially predict. You must proceed with the attitude of a scientist conducting an experiment, and when you get back the results, you must not argue with them, but rather, you must adjust your mental model of the world. When Sir Alexander Fleming saw that mold on some bread crumbs was keeping bacteria from growing in a petri dish, he said “Astounding! That mold must be producing some substance that kills bacteria! Perhaps that same substance can be used to kill bacteria in humans?” How many of us would be dead right now if he had rejected the evidence, and said simply “That’s impossible! Mold can’t hurt bacteria! Everyone knows that!” Over the previous 60 years, two other researchers had already noted the lack of bacteria in the presence of certain types of mold, yet they failed to reach the conclusion that Fleming did. An entrepreneur would do well to emulate Fleming’s open mindedness.

Peter Drucker, perhaps the greatest business guru of the 20th Century, once remarked that innovators are often disappointed by the manner in which their innovations become popular. In his 1985 book, Innovation and Entrepreneurship, Drucker relates the story of Alfred Einhorn, who invented Novocain, which then became popular with dentists as a local anesthetic. Einhorn held a contempt for dentistry, since it represented such a small niche of medicine. He felt that Novocain should be used by surgeons for all forms of surgery, and so he waged a campaign against the use of Novocain by dentists. In the end, his innovation was successful despite him, rather than because of him. According to Drucker, this pattern, where a product or service is undercut by the entrepreneur who is trying to promote it, is extremely common.

When I first read Drucker’s book I found it hard to believe that an entrepreneur would actively sabotage their own innovation. However, having now spent several years working with startups, I’ve seen that it is, indeed, a common pattern. Many entrepreneurs starts websites at least in part because they consider themselves uniquely creative and insightful, and they want the whole world to see them as they see themselves. The website they launch proves them wrong: their insights are proven false, what works in the end is something unexpected. For instance, in 1992, when Bo Peabody launched Tripod, he was thinking that the site would offer content aimed at college students. His idea failed. The company was saved because some of the programmers at the company had started a side project that allowed anyone to create their own web pages. This then became the future of the company. In his book, Lucky or Smart, Peabody says it is important to be smart enough to know when you are getting lucky. And then, you have to be willing to accept that luck. This takes humility. What’s needed in an entrepreneur is emotional resilience, the kind of strength that allows for openness to the unexpected.

Twice now I’ve seen an entrepreneur sabotage their own website because it became successful for what they felt were the wrong reasons. This emotional resistance to success is nearly always inspired by one of two factors:

1.) The success is with a small niche. The startup was suppose to grow till it was larger than Google, and success with a small niche is, therefore, extremely disappointing. The niche might be big enough to potentially generate several million in revenue, but it won’t ever be enough to catch up with Google.

2.) The success is of a conventional type and, therefore, the entrepreneur regards it as boring. Perhaps the site was suppose to pioneer an altogether new style of interaction among humans, and instead the part of the site that becomes popular is of an old type – for instance, the blog on the site becomes highly successful. The entrepreneur is then disappointed, maybe even angry, to be the owner of a boring success.

Here then, are some fatal traps to avoid. Without open mindedness about the type of success you may encounter, your startup is doomed. And without humility about the limits of your knowledge, your startup is doomed.

Equity

Except for when we were working at Category4.com, every client we’ve worked with has offered us equity in their business. So far, we’ve always turned these offers down. If you have an idea for a web startup, and you’d like our help, I imagine that you too might be thinking of offering of us equity. You’d be injuring your own best interests if you did so. Offering equity means that you’d like enter into a business partnership, and business partnerships are a bit like marriage. Suggesting such a union to people you’ve just met is a lot like proposing marriage on a first date. First of all, it suggests desperation. There is nothing wrong with that in itself – we’ve all read stories in Inc magazine of a venture started with too little money but which succeeds against the odds. However, second of all, and much more seriously, it suggests that you are not thinking very clearly.

A business partnership means that we need to take an interest in every aspect of your business, including all of the flaws. This can be brutal. This is not a good way to make friends.

Recently, an older gentleman approached us with an ambitious idea that he could not finance himself. He already had a successful operation providing hospitality services to movie companies that film on location in Latin America. His idea for a web startup was somewhat related. He suggested that we take equity in the new startup, as a form of payment. We explained to him that a partnership was a bad idea because we hardly knew each other. If we were to take his offer seriously, we’d have to interview his staff and find out if anyone disliked him, and if so, why. We’d have to find out if any of his key people were planning to leave soon. We’d have to talk to his customers and find out if they liked him or hated him. This should not be any of our business, yet if we formed a business partnership it would be, literally, our business.

As it turned out, we were lucky not to form a partnership with this person. We later discovered he was struggling with issues arising from a past history with alcohol, and even though he’d been sober for 20 years, he was still exhibiting some of the behaviors that had sabotaged him before. Incidents such as this are the main reason we are wary of taking equity. But here is the thing – you should be wary too. What about our flaws? What about the stuff we get wrong? If you are offering us equity when you hardly even know us, then you are trusting us too much. And, to us, that indicates that you are not thinking clearly about the risks that your venture will face.

People should know each other at least a year before they think about forming a partnership together. Web startups routinely break this rule, and I suppose that is fine if the company is built to be flipped – that is, you assume that you’ll cash out in a year anyway, so you don’t have to worry about other people’s flaws -  there won’t be enough time for those flaws to come back and haunt you. However, as a general rule, business partnerships should be for people who know each enough that they can trust each other. Even in those scenarios where the company is built to be flipped, you’ll find that having one wrong person on your team, as an equity holder, can significantly hurt your chances of selling the company.

Contact Us

 We have worked on sites that had budgets under $1,000. We have worked on sites that have cost $250,000. We have long associations with a network of professionals which allows us to quickly assemble an agile team with exactly the skillset needed for the construction of your website. Whether your site needs graphic designers, computer programmers, videographers, writers, marketers, photographers or system administrators, we can bring together the talent you’ll need. We can even give you some rough guidance about which situations you’ll need a lawyer for. We are especially able to help web-focused startups whose initial 6 month budget is between $10,000 and $100,000. We can also help with existing sites that have so far failed to attract an audience.

 For every rule we’ve written here, we can think of three qualifiers. If you’d like to hear how the subtleties might apply to your web project, contact us. We are willing to meet once for free, to give you our honest feedback about your idea.

 434-825-7694

contact@teamlalala.com