Paul Graham, “Hackers and Artists,” Chapter 5: The Other Road Ahead, continued
“Investors and analysts asked us about what we planned for the future. Our real answer would be: "We have no plans at all."
- Paul Graham, developer, investor, essayist.
I was curious to get acquainted with the forecast of the founder of the most influential business incubator in Silicon Valley (Y combinator). 15 years after the publication of Paul Graham's essay, thanks to Edison and great people from Habr, hands reached the translation. For those who are interested in how the birth of the new product took place and how the three programmers were butting with the giants of the industry, welcome to Cat.
')
September 2001
Original - The Other Road Ahead
(For the translation, thanks to Shchekotova Yana)
Read the first part of the chapter.
Having the ability to release a program immediately is a significant motivator. Often, on the way to work, I thought about the changes I wanted to make to the application, and made them the same day. This also worked for larger features. Even if it took two weeks to write something (and on some projects even more), I knew that I could see the result as soon as everything was done.
If I had to wait a year before the next release, I would put most of these ideas in the back box, at least for a while. The fact is that, after all, ideas lead to other ideas. Have you ever noticed that as soon as you sit down to write something, half of the ideas embodied in the work are those ideas that visited you in the process? The same thing happens with programs. Working on the realization of one idea gives you even more ideas. Therefore, for postponing, you pay not only a delay in the implementation of your idea, but also all the ideas that you come to at this stage. In fact, postponing prevents the emergence of new ideas: as soon as you start thinking about some new functionality, you remember your “box” and think: “But I already have a bunch of chips to implement in the next release.”
Large companies instead of implementing features plan them. For this reason, we sometimes encountered difficulties in Viaweb. Investors and analysts asked us about what we planned for the future. Our real answer would be: "We have no plans at all." We had a general idea of what we would like to improve, but if we knew how, we would have done it a long time ago. What are we going to do with the next six months? Everything that could lead us to the most advantageous position. I don’t know if I would ever dare to answer that, but that was the truth. Plans are just a synonym for the word "ideas." When we were visited by good ideas, we implemented them.
In Viaweb, as in many other software development companies, most of the code has one particular owner. But if something belongs to you, then you really did have it: no one, except for the owner of a part of the program, can give permission for its release (or even know about it). As such, there was no protection against breakdowns, except for the fear of looking like an idiot in front of their colleagues, but that was more than enough. I may have created the false notion that we were just quietly moving forward creating the code. We really moved fast, but we thought it through carefully before putting the application on the servers. In terms of reliability, attention is more important than slow progress. It is thanks to the increased attention paid to the process that a military pilot can land a 40,000-pound aircraft at a speed of 140 miles per hour on the carrier’s swaying deck at night, and there will be less risk than an average teenager cutting the bread.
Of course, this way of writing programs is a double-edged sword. It works much better in small teams of good, reliable programmers, and not in large firms with mediocre workers, where bad ideas are eliminated at meetings, and not by the people they come to.
Fortunately, web applications require fewer programmers. One day, I worked in a medium-sized desktop application development firm, in which the technical department generally had more than a hundred people. Only 13 of them were involved in product development. Everyone else worked on releases, porting, etc. With web applications, all you need (for the most part) is 13 people, because there are no releases, no porting, nothing.
Viaweb was written by just three people. [7] I tried hard to hire more, because we wanted to be bought, and we knew that it would not be easy to convince customers to pay a high price for a company with three programmers. (Solution: we hired more people, but created new projects for them.)
When you write programs with fewer programmers in the state, you save more than just money. As Fred Brooks noted in his book Mystical Man-Month, an increase in the number of people in a project leads to its slowdown. The number of possible relationships between developers grows exponentially with the size of the group: the larger it is, the more time will be spent discussing how applications will work together, and the more errors will appear due to unforeseen dependencies. Fortunately, this process also works in the opposite direction: the smaller the group, the higher the exponentially increasing efficiency of the application development process. I cannot recall that the programmers at Viaweb organize real meetings. We never spoke more at a time than we could say on the way to dinner.
If there is any flaw, it is that all programmers to some extent must also be system administrators. When you deploy an application, someone has to monitor the servers and, in practice, the only people who can do this correctly are those who wrote this application. In Viaweb, our system contained so many components and changed so often that there was no clear boundary between the application and the infrastructure. The voluntary assertion of such a boundary would limit us in the choice of design solutions. And so, although we constantly hoped that one day (“in a couple of months”) everything would be stable enough to work so that we could hire someone whose duties would only include taking care of the servers, but this never happened.
I do not think that there is another way out, while you are still actively developing the product. Web applications will never be what you write, save to the repository and go home. It is a living thing running on your servers right now. A terrible bug can not only destroy one of the user processes, but it can also destroy them all. If an error in your code destroys some data on the disk, then you should fix it. And so on. We found out that there is no need to check the servers every minute (after the first year or so), but you definitely want to keep track of what you recently changed. You can not release the code late at night, and then go home.
In the server application, you are in closer contact with your code. And you can also be in closer contact with your users. Intuit is known for introducing customers to retail solutions and requests to visit their website from home. If you've ever watched someone use your app for the first time, then you know what surprises must have been waiting for him.
An application should do what users think it should. But you and the head will not come that in the minds of users, believe me, as long as you do not observe them. And server applications provide you with information about their behavior without any specifics. You are not limited to small, artificial focus groups. You can see every click made by each user. You will have to carefully determine what you are going to look at, because you don’t want to violate people's privacy, but even the most general statistical example can be quite useful.
When there are users on your server, you do not need to rely, for example, on benchmarks that are emulated by users. With server applications you can monitor real users. To decide what to optimize, just log in to the server and see what consumes all the CPU time. And you also know when to complete the optimization. We ended up bringing Viaweb to a point where it depended more on memory and not on processor speed, and since we couldn’t do anything to reduce the size of user data (well, nothing that was considered simple), we knew that we should stop at this.
For server applications, performance matters because you pay for the hardware. The number of users that you can maintain on one server is a divisor of your capital costs, so if you can create a fairly productive application, then you can provide it at a price lower than that of competitors and make a profit. In Viaweb, our capital expenditures per user were reduced to $ 5. And now they could be even less. Perhaps less than sending the bill for the first month. Now equipment costs you nothing if your applications are productive enough.
Monitoring users can lead you to both design and optimization issues. Viaweb uses the RTML scripting language, which allows advanced users to define the style of their personal pages. We found out that RTML has become a kind of magazine of feedback and suggestions, because users used it only when ready-made page styles could not realize what they wanted. For example, the editor initially placed a panel with buttons across the page, but after a number of users used RTML to place the buttons at the bottom left, we implemented this option (by default) in the ready-made page styles.
And finally, by observing users, it is often possible to determine when they are having difficulty. And, because the customer is always right, this is a sign that you need to fix. In Viaweb, the key point in understanding users was a trial launch online. It was not just a sequence of slides compiled by marketers. In our test run, users actually used the application. It took about 5 minutes, and in the end they created a real working store.
It was through this test drive, we realized that we need almost all of our new users. I guess the result would be the same for most web applications. If users can successfully complete the test run, they will love the product. If they get confused or bored, then no. Therefore, everything we could do to attract more people through a test run would increase our growth rate.
I studied the history of clicking on the links of people participating in the test run and found out that at a certain step they got confused and clicked the mouse on the back button of the browser. (If you try to write a web application, you will find that the "Back" button goes into the category of one of the most interesting philosophical problems.) Therefore, I added a message in this place explaining to users that they were almost finished and that they did not click on back button. Another great thing about web apps is that you get an instant response to changes: the number of people who completed the test run immediately increased from 60% to 90%. And since the number of new users depends on the number of completed test-drives, our income has grown by 50% only because of these changes.
In the early 1990s, I read an article in which someone said that software is a subscription-based business. At first this statement seemed very cynical. But then I realized that this reflects reality: software development is a continuous process. I believe that it will be more honest if you openly designate the cost of a subscription instead of forcing people to buy and install new versions so that they continue to pay you. And, fortunately, a subscription is a natural way to pay for web apps.
Application hosting is an area where firms will play a role in a niche that most likely will not be filled with free software. Application hosting is a lot of stress, and you have to spend some money. No one wants to do it for free.
For web application companies, this is an ideal source of income. Instead of starting each quarter from scratch, you will have a periodic income. As your application spins up gradually, you don’t need to worry that the new model will crash; The new model, as such, will not be needed, and if you add something in the application that users will perceive with hostility, then you will immediately find out about it. You have no problems with ineligible bills: if someone doesn’t pay, you simply turn off the service. There is also no possibility for piracy.
This last “advantage” can lead to a problem. Some pirated activity is beneficial to software companies. If any user really would not have bought your application for any price, you would not lose anything from the fact that it uses a pirated copy. In fact, you even benefit from this, because it is another user who helps to make your application a reference, or who can buy a copy of the application later when he graduates from university.
Companies love to discriminate as much as possible, which means giving each customer the highest possible price they can afford. [8] Software is particularly suitable for price discrimination, since marginal costs are close to zero. That is why some applications for running on Sun computers cost more than analogs for Intel: a company using Sun is not interested in saving money and can pay more. Piracy, in essence, is the lowest level of price discrimination. I think that software development companies understand this and deliberately do not notice certain types of piracy. [9] As for server applications, they will come up with another solution.
Web applications sell well, especially when compared to desktop software, because it is easy to buy. You might think that the decision of people to buy something, and the subsequent purchase are two separate steps. So I thought earlier in Viaweb, as I thought about this topic in principle. In fact, the second step can go back to the first: if something is difficult to buy, people will begin to doubt whether they need it. And vice versa: you will sell more if it is easy to buy. I buy more books because there is an Amazon. A web application is simply the simplest thing in the world to buy, especially if you have just done an online demo. Users do not have to perform many actions, but only enter a credit card number. (Forcing them to do more actions at their own risk.)
Sometimes web applications are distributed through Internet service providers acting as resellers. It is a bad idea. You will have to manage the servers, because you need to constantly improve both the hardware and the software. If you miss direct control of your servers, you will miss most of the benefits of developing web applications.
Some of our competitors thus hacked the branch on which they sat. Usually, as I believe, this happened because they had a surplus of board members, who were delighted with such a huge potentially profitable channel, and did not realize that this would destroy the product that they hoped to realize through it. Selling web applications through Internet providers is like selling sushi through vending machines.
Who are your customers? For Viaweb, these were initially individuals and small firms, and, as it seems to me, in web applications this will become a well-established rule. Such users are willing to try something new, partly because they are more flexible, and partly because they want to spend less on new technologies.
Also, web applications will often be considered as the best option for large companies (although they will slowly realize this). The best enterprise computer network is the Internet. If a firm uses real web applications, then applications will work better, servers will be better monitored, and employees will have access to the system from anywhere.
Arguments against this approach are usually closely related to security: if access is simplified for workers, then it will be for attackers as well. Some of the larger sellers were reluctant to use Viaweb because they believed that customer credit card information would be safer on their own servers. It was not easy to solve this by diplomatic means, but in reality, it was almost certainly safer to keep the data on our side and not on them. Who can hire the best people to manage security: a tech start-up, whose business is completely running on servers, or a clothing retailer? We have not only the best people responsible for security, but we ourselves pay more attention to it. If someone hacks into the servers of a clothes seller, then this will affect mainly one trading company, and this business may be closed up, and, in the worst case, they will fire one person. If someone hacks our servers, it will affect thousands of trading companies, and perhaps everything will be in the news on CNet, and we will lose our business.
If you want to save your money, then you keep it under a mattress at home, or give it to the bank? This applies to any aspect of server management: not only security but also uptime, bandwidth, load management, backup, etc. Our existence depends on the proper performance of these things. The presence of problems with the server was absolutely unacceptable for us, as for the creator of toys, dangerous toys are unacceptable, or a flash of salmonellosis for a food processor.
Large companies that use web applications, to some extent, transfer some of the IT functions to outsourcing. No matter how harsh it may sound, I believe that, in general, this is a good idea. So firms are more likely to get better service than if they organized their own staff of system administrators who can become wayward and immune because they are not directly subjected to competitive pressure: the seller works with customers, the developer works with competitors, and the system administrator like an old bachelor, there are only a few external factors that keep him afloat. [10] In Viaweb, external factors for keeping oneself afloat were abundant. The people calling us were customers, not just colleagues. If the server got stuck, we were immediately undermined; the very thought of it makes you feel a surge of adrenaline, even after years.
Therefore, usually, web applications will be the right solution for large companies. However, it comes to them last, as was the case with desktop computers. And partly for the same reason: convincing large companies that they need something more expensive will cost a lot of money.
There is always a tendency for rich customers to buy expensive solutions, even when cheap solutions are better, because people who offer expensive solutions may spend even more trying to sell them. We at Viaweb have always been strongly against this approach. We lost a few high-class sales representatives who went to a web consulting company that convinced them that they would be in a better position if they paid half a million dollars for a custom-made online store on their own server. As a rule, they did not fall into an advantageous position, since it was discovered that with the onset of the Christmas shopping season, their server load increased. Viaweb was a much more complex product than that of most sales representatives, but we did not have the opportunity to tell them about it. Working for $ 300 a month, we could not afford to send a team of decently dressed and powerful people to our clients to present the product to our clients.
The main share of what large firms pay an increased price for is the cost of selling them expensive items. (If the Department of Defense pays $ 1,000 for toilet seats, this is partly because it takes a lot of money to sell toilet seats for $ 1000.) And this is one of the reasons why software intranet will continue to flourish, even if and bad decision. It is just more expensive. And you can’t do anything about it, so the best course of action would be to turn your attention first to smaller clients. Everything else will follow at the right time.
There is nothing new in the launch of the application on the server. In fact, this is an outdated model: all applications for supercomputers are server applications. If server applications are such a good idea, why did it lose to others? Why desktop computers overshadowed the supercomputer?
At first, desktop computers were not considered as a direct threat. All the first users were polls by computer experts or enthusiastic people. They liked the microcomputer, because they were cheaper. For the first time you had your own computer. The phrase "personal computer" is now firmly in use, but when it was first used, it had an intentionally bright sound, like the phrase "personal satellite" today.
Why did desktop computers win? I guess because their software was better. And I think that the reason why microcomputer applications were better was because small firms could write them.
I don’t think that many people realize how fragile and unsure startups are at an early stage. Many startups start almost by accident: a couple of young people, either with a permanent job, or schoolchildren, write a prototype of something that could, if it looked promising, turn into a company. In such an embryonic state, any significant obstacle will tightly freeze a startup. Writing software for supercomputers required too many obligations. Software development computers were expensive, and since the clients were large firms, you would need impressive sales staff to sell them. Starting a supercomputer software start-up would be a much more serious matter than just tinkering programs on your Apple II in the evenings. Therefore, there was not a large number of startups to create such software.
The emergence of desktop computers inspired the creation of new applications, because the development of programs seemed to be an achievable goal for "rudimentary" startups. The development was cheap, and customers were individuals with whom it was possible to establish contact through computer stores or even trade by mail.
The application that translated desktops into the mainstream was called VisiCalc, the first spreadsheet editor. Two guys wrote it in the attic, and it did things that no supercomputer application could do. [11] VisiCalc was such a breakthrough at the time that people bought an Apple II just to launch it. And this was the beginning of a new trend: desktops won because startups created applications for them.
It seems that server applications would be most welcome, since startups will write them. Now computers are so cheap that you can start with the same thing as we, i.e. use the desktop as a server. Low-cost processors swallowed the workstation market (you’re hardly likely to hear this phrase now) and mostly through the server market; Yahoo servers that handle the load, like all other servers on the Internet, are all equipped with low-cost Intel processors that are installed on your desktop.And when you wrote the app, all you need to sell is a website. Almost all of our users came directly to our site via word of mouth and press links. [12]
Viaweb was a typical “embryonic” startup. We were scared to organize a company, and, during the first few months, we calmed ourselves, taking it all as an experiment that we could interrupt at any time. Fortunately, there were other problems besides technical issues. During the writing of the application, our web server played the role of a desktop PC used in the development process and was connected to the rest of the world via a telephone line. Our only expenses at this stage were food and rent.
Now for startups there are even more reasons for creating web applications, because developing software for desktop computers is no longer so interesting. If you now want to write applications for desktop computers, then you do it under Microsoft conditions, calling their API and working with their buggy OS. And if you manage to write something that shoots, you might find that you were just doing marketing research for Microsoft.
If a firm wants to create a platform on the basis of which start-ups will be implemented, then it must be such that the programmers themselves would like to use it. Which means that it should be inexpensive and well designed. When Mac first appeared, it was popular among computer professionals, and many of them wrote applications for it. [13] In the case of Windows, this was less noticeable, since programmers did not use it. Now, people who are good at application development tend to use Linux or FreeBSD.
I do not think that we would organize a startup for creating software for desktop computers, because such software must run on Windows, and before writing software on Windows, we would have to use it. The web allows you to bypass Windows, and provide software that runs on Unix, directly to users through a browser. This is a great chance to get rid of addictions, which is very similar to the appearance of a PC 25 years ago.
Long ago, when desktop computers appeared, IBM was a giant everyone was afraid of. It is difficult to imagine now, but I remember this feeling very well. Right now, Microsoft is an intimidating giant, and I don’t think they don’t understand the threat looming in front of them, as IBM did. In the end, Microsoft deliberately began to run its business in the IBM blind zone.
I once mentioned earlier that, for example, my mother does not need a desktop computer at all. And, probably, most users do not need this either. That's the problem with Microsoft, and they know it. If applications run on remote servers, no one needs Windows. What will Microsoft do? Will they be able to use their control over the PC to prevent or limit this new generation of applications?
I will assume that Microsoft will develop some sort of hybrid server and desktop application, where the operating system works in conjunction with the servers they manage. At a minimum, files will definitely be available to users who need it. I don’t think that Microsoft will go to extremes and organize calculations on the server, where only the browser will act as a client if they can avoid it. If you only need a browser as a client, then you don’t need Microsoft on the client machine, and if Microsoft doesn’t manage the client, they will not be able to force users to switch to their server applications.
I believe that it will be difficult for Microsoft to keep technology within tight boundaries. There will be too many different types of clients to control them all. And if Microsoft applications work only with some clients, competitors will be able to jump them, offering applications that run on any client. [14]
In the world of web applications for Microsoft there is no automatically allocated space. They can succeed in creating it on their own, but I don’t think they will hold a leading position in this new world, as they did in the world of desktop applications.
The point is not only that competitors will furnish them, but also that they dig a hole for themselves. As web applications develop, they will face not only technical problems, but also their wishful thinking. They need to absorb their current business, and I can not imagine that they will go for it. The same sense of purpose that has led them so far will now work against them. IBM was in exactly the same position and could not handle it. IBM made a belated and indecisive entry into the microcomputer market because they experienced an ambivalent feeling endangering their cash cow — the use of a supercomputer. Similarly, Microsoft will be constrained in their actions, wanting to save desktop solutions. A reliable source of money can turn into a rather heavy burden.
I do not claim that no one will be able to dominate in the field of server applications. Probably in the end, someone will do it. But I want to say that it will take quite a lot of time amusing confusion, just like at the dawn of the microcomputer. It was a good time for startups. Many small firms have flourished, creating cool stuff.
A classic startup is organized quickly and without unnecessary formalities, with a small staff and budget. These few people work hard, and technology enhances the effect of their decisions. If they win, they win big.
In a web application startup, everything that you associate with startups is taken to the extreme. You can create and launch a product with even fewer people and even a smaller budget. Only you will have to be even faster and reduce the level of formalities. You can run the product in the literal sense of the word, with three people in the living room of someone's apartment, and a server from an Internet provider. We have all been so.
Over time, the teams became smaller, faster, and more relaxed. In 1960, software development meant a room full of people wearing horn-rimmed glasses with narrow black ties, who were hard at writing 10 lines of code a day in IBM coding. In 1980, it was a team of 8-10 people coming to the office in jeans and typing in vt100 terminals. Now this is a couple of guys sitting in the living room with laptops. (And jeans turned out to be not the last point in providing an atmosphere of ease and freedom.)
Startups have a lot of stress, and, unfortunately, this is also brought to the extreme in the field of web applications. Many software development companies, especially at the beginning, had moments when developers slept under tables, etc. The alarm may be the fact that nothing can prevent the transition of this phenomenon into constant practice. Stories about how someone sleeps under the table usually end like this: and finally, we saved all the changes and went home, and slept all week. In web applications, you cannot take and make all changes. You can work 16 hours a day for as long as you want. And sincecan you, and your competitors too, you already have to do it. You can, therefore you should. Parkinson's law is the opposite.
The worst is not the number of hours worked, but responsibility. Programmers and system administrators have traditionally different concerns. Programmers should think about bugs, and system administrators should think about infrastructure. Programmers can spend the day after spending it buried in the source code, but at some point they will have to go home and forget about all this. System administrators never leave work for later, but when they receive a message at 4 am, they usually don’t have to do anything quite complicated. In the world of web applications, these two types of stress are combined. Programmers become system administrators, but without well-defined boundaries, which usually make work tolerable.
In Viaweb, we spent the first 6 months just writing a program. We worked a typical extended working day of a startup in the early stages of development. If we were in a desktop application development company, we would tell you how hard we work, but it feels comparable to a vacation, if we take in comparison with the next stage, where we let users onto our server. The second big advantage (after money) from the sale of Yahoo's Viaweb to Yahoo was the ability to shift all responsibility for all this onto the shoulders of a large company.
Desktop applications force users to become system administrators. Web applications are forcing programmers to become such. The total amount of stress is less, but its share is higher for programmers. This is not always bad. If you started a startup and compete with a large company, then this is good. [15] Web applications offer a direct way to outperform your competitors. And startups don't need more.
The only thing that can scare you from creating web applications is the wretchedness of web pages when used as a user interface. I admit, this is a problem. We really wanted to add a couple of things in HTML and HTTP. But in fact, what matters is that web pages are so good.
An analogy with the first microcomputers is traced here. The processors in these machines were not really intended to be used as central processing units. They were intended for use in traffic lights, etc. But people like Ed Roberts, the creator of Altair, realized that they were well suited for this purpose too. It was possible to combine one of these chips with some kind of memory (in the first Altair there were 256 bytes of memory), add the front panel of switches, and now you have a working computer. The ability to assemble your own computer was such an exciting idea that there were a lot of people who wanted to buy them, although their number was limited.
Web pages were not created to serve as an interface to web applications, but they are so good. And for a significant number of users of applications that can be used from any browser, it will be enough to really overcome the rejection of some sluggishness in the UI. You may not be able to create the most beautiful spreadsheet using HTML, but you can create a table that several people can use at the same time from different places without special client software, or which can combine real data, or which can send you a notification when certain conditions are triggered. More importantly, you can create new kinds of applications that have no names yet. VisiCalc was not just a supercomputer application with a microcomputer version, after all,It was a new type of application.
Of course, server applications are not required to be web applications. You could have some other customer. But I'm sure this is a bad idea. It would be very convenient if you could assume that everyone will install your client. It is so convenient that you could easily convince yourself that they will all do so, but if they do not want it, then you will be tied hand and foot. Since web applications do not make any assumptions about the client side, it will work wherever the web works. And this is a great advantage, and it will only increase as new web devices spread. Users will like you, because your application just works, and your life will become easier, because you do not have to customize it for each new client. [sixteen]
I have a feeling that I looked at the evolution of the web scope in the same detail as any of us, but I cannot predict what will happen with the client content. Probably convergence is coming, but at what point? I can not determine the leader. The only thing I can predict is the disagreement between AOL and Microsoft. Whatever the resultant Microsoft .NET technology is, it will most likely include the PC connection to the server. Until AOL starts downloading the rights, they will either be pushed aside, or turned into a layer between the Microsoft client and the server software. If Microsoft and AOL start a war for a client, the only thing that will work for both is browsing the web, i.e. Web applications will be the only software that runs everywhere.
How is all this resolved? I dont know.And you do not need to know if you make a bet on web applications. No one can break this trend without limiting the very possibility of browsing the web. Probably the web is not the only way to implement applications, but it is now the only working version that will continue to work for a long time. Web applications are cheap to develop and easy to distribute even to the smallest startup. You need to work a lot on them and experience a lot of stress, but this only increases the chances of a startup.
E. B. White was amused by the fact that, as a farmer friend told him, many of the electric current hedges were not really energized. When the cows learned to stay away from them, there was no longer any need to pass current through the hedge. “Get up, cows! - he wrote, - Go to freedom, while your tyrants snore! ”
If you are an IT person who has already thought of starting a startup once, then you are probably holding back two things. First, you know nothing about business. Second, you are afraid of competition. But none of these barriers are not connected to an electric current.
Here are two things you need to know about business: do what users love and earn more than you spend. If you learn this well, you'll be ahead of most startups. In all other respects you will understand along the way.
Perhaps at first you will not be able to earn more than you spend, but as soon as this gap starts to narrow enough quickly, everything will work out for you. If you start with less cash, this will at least contribute to the development of the habit of thrift. The less you spend, the easier it is to earn more of your expenses. Fortunately, launching a web application can be very cheap. We started with a budget of less than $ 10,000, and today it is even cheaper. We had to spend thousands on a server, and a few thousand more on SSL. (The only firm selling SSL software at the time was Netscape.) Now you can rent much more powerful servers, already with SSL, and pay less for it than you had to pay only for bandwidth. You could now launch a web application for a cost,lower cost of a good office chair.
Regarding the creation of what users will love, here are some general tips. Start by creating something clear and simple that you yourself would like to use. Quickly release version 1.0, and then continue to improve the application, carefully listening to users as they go. The customer is always right, but different customers are right about different things; the least experienced users will show what needs to be simplified and explained, while the most experienced ones will indicate what functionality they need to add. The best that an application can do is to be simple, but in order to achieve this, you need to rightly identify all the “default” work scenarios right away, and not restrict users from choosing. Do not bother if the competitor’s application is bad; the benchmark with which you need to compare your application is what it could be, and not whatwhat happened to the competitors. Use your software all the time. Viaweb was designed as an online store designer, but we also used it to create our own website. Do not listen to marketers, designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.
And now let's discuss the competition. What you are afraid of is not supposed groups of programmers like you, but real companies, with offices and business plans, vendors, etc., right? Well, they are more afraid of you than you, and they are right. It is much easier for a pair of hackers to figure out how to rent an office space or hire people to conduct sales, than to write an application for a company of any size. I have been on both sides of the barricades, and I know what I'm talking about. When Viaweb was bought by Yahoo, I suddenly discovered that I was working for a large company, and this was tantamount to running to the waist in the water.
I do not want to belittle Yahoo. They had some good specialists; top managers were real monsters. For a large company, this is rare. But still, they are productive only a tenth of a small startup. And no large firm can do better. What scares Microsoft is that such a large company can even develop applications. They are like a mountain that can move.
Do not let yourself be intimidated. You can do what Microsoft can't do, and they can do what you can't do. And no one will stop you. You do not need to ask anyone for permission to develop web applications. You do not have to deal with issues with licensing, or request a place on the shelf of retail stores, or kowtow to the owners of the OS, so that your application will be included in its composition. You can provide the application directly through the browser, and no one can come between you and potential users without closing the web.
You may not believe it, but I guarantee that Microsoft is afraid of you. Complacent middle managers, maybe not, but Bill surely, because he was once in your place, back in 1975, when the last time a new way of software distribution appeared.
[7] Robert Morris wrote an ordering system that buyers used to place orders. Trevor Blackwell wrote an image generator and a manager that sellers used to view orders, statistics, domain name settings, etc ... I wrote an editor that sellers used to create their sites. The ordering system and image generator were written in C and C ++, the manager was mainly written in Perl, and the editor was written in Lisp.
[8] Price discrimination is so common (how often have you heard a retailer say that their purchasing power would mean lower prices for you?) That I was very surprised when I learned that in the US, the Robinson-Patman Act of 1936 she declared illegal activity. By the adoption of such a law, it seems, is not particularly forced.
[9] Naomi Klein of No Logo says clothing brands that are popular with “urban youth” are not particularly trying to prevent shoplifting because shoplifters are also leading fashion players in their target market.
[10] Firms often wonder what to outsource and what not. One possible answer: to outsource any work that is not directly exposed to competitive pressure, because, therefore, its outsourcing will put it under this very pressure.
[11] The two guys were Dan Bricklin and Bob Fraxton. Dan wrote a prototype on Basic for a couple of days, then over the next year they worked together (mostly at night) to create a more powerful version written in the 6502 computer language. Dan was studying at the Harvard Business School at that time, and Bob officially had a permanent work where he wrote the application. “There were no major risks in the conduct of your business,” Bob wrote, “If it does not work out, then it will not work out. Nothing special".
[12] It's not quite as easy as I voiced it. It will take a lot of painful time for word-of-mouth radio to work, and we didn’t have frequent press coverage until we hired a PR firm (and really the best in the business) for $ 16,000 a month. However, the truth is that the only significant channel was our own website.
[13] If the Mac was so cool, why did it lose? Again, the point is the price. Microsoft focused on software development, and released a crowd of suppliers of cheap components for Apple hardware. But it also did not help, that suits during the critical period.
[14] The only thing that would help web applications and keep the next generation of applications from being overshadowed by Microsoft is a good open-source browser. Mozilla is an open-source browser, but seems to have suffered from staying too long in the role of a corporate application. A small fast browser that would actively support, in itself would be great, and also, perhaps, would inspire companies to implement small web devices.
In addition, a suitable open-source browser would be the reason for the further development of HTTP and HTML (such as Perl, for example). This would greatly help web applications recognize the selection of a link and the passage through it; all that is needed for this will be a banal HTTP extension, which will allow you to contain several URLs in the request. A cascading menu would also be good to implement.
If you want to change the world, write a new Mosaic. Think too late? In 1998, many people thought it was too late to launch a new search engine, but Google proved the opposite. There is always room for something new if current solutions are pretty poor. First make sure that it works on all free operating systems, since new begins with their users.
[15] Trevor Blackwell, who, perhaps from his personal experience, knows more about this than anyone, writes: “I would add that, because server applications are too harsh with programmers, it causes a significant economic outflow from large firms. Programmers need some energy and dedication, which they can show only when it is their own firm. Software development firms can hire experienced people to work in a less demanding environment, and they can hire inexperienced people to experience difficulties, but they cannot hire highly qualified people to get rid of their jobs. Since capital investments have ceased to be a mandatory element, large firms may have little interest. "
[16] In the original version of this essay, I advised to avoid Javascript. Such a plan was good for 2001, but Javascript now works.
Hackers and artists
- Paul Graham, developer, investor, essayist.
I was curious to get acquainted with the forecast of the founder of the most influential business incubator in Silicon Valley (Y combinator). 15 years after the publication of Paul Graham's essay, thanks to Edison and great people from Habr, hands reached the translation. For those who are interested in how the birth of the new product took place and how the three programmers were butting with the giants of the industry, welcome to Cat.
')
September 2001
Original - The Other Road Ahead
(For the translation, thanks to Shchekotova Yana)
Read the first part of the chapter.
Approach to business
Having the ability to release a program immediately is a significant motivator. Often, on the way to work, I thought about the changes I wanted to make to the application, and made them the same day. This also worked for larger features. Even if it took two weeks to write something (and on some projects even more), I knew that I could see the result as soon as everything was done.
If I had to wait a year before the next release, I would put most of these ideas in the back box, at least for a while. The fact is that, after all, ideas lead to other ideas. Have you ever noticed that as soon as you sit down to write something, half of the ideas embodied in the work are those ideas that visited you in the process? The same thing happens with programs. Working on the realization of one idea gives you even more ideas. Therefore, for postponing, you pay not only a delay in the implementation of your idea, but also all the ideas that you come to at this stage. In fact, postponing prevents the emergence of new ideas: as soon as you start thinking about some new functionality, you remember your “box” and think: “But I already have a bunch of chips to implement in the next release.”
Large companies instead of implementing features plan them. For this reason, we sometimes encountered difficulties in Viaweb. Investors and analysts asked us about what we planned for the future. Our real answer would be: "We have no plans at all." We had a general idea of what we would like to improve, but if we knew how, we would have done it a long time ago. What are we going to do with the next six months? Everything that could lead us to the most advantageous position. I don’t know if I would ever dare to answer that, but that was the truth. Plans are just a synonym for the word "ideas." When we were visited by good ideas, we implemented them.
In Viaweb, as in many other software development companies, most of the code has one particular owner. But if something belongs to you, then you really did have it: no one, except for the owner of a part of the program, can give permission for its release (or even know about it). As such, there was no protection against breakdowns, except for the fear of looking like an idiot in front of their colleagues, but that was more than enough. I may have created the false notion that we were just quietly moving forward creating the code. We really moved fast, but we thought it through carefully before putting the application on the servers. In terms of reliability, attention is more important than slow progress. It is thanks to the increased attention paid to the process that a military pilot can land a 40,000-pound aircraft at a speed of 140 miles per hour on the carrier’s swaying deck at night, and there will be less risk than an average teenager cutting the bread.
Of course, this way of writing programs is a double-edged sword. It works much better in small teams of good, reliable programmers, and not in large firms with mediocre workers, where bad ideas are eliminated at meetings, and not by the people they come to.
Brooks theory is the opposite
Fortunately, web applications require fewer programmers. One day, I worked in a medium-sized desktop application development firm, in which the technical department generally had more than a hundred people. Only 13 of them were involved in product development. Everyone else worked on releases, porting, etc. With web applications, all you need (for the most part) is 13 people, because there are no releases, no porting, nothing.
Viaweb was written by just three people. [7] I tried hard to hire more, because we wanted to be bought, and we knew that it would not be easy to convince customers to pay a high price for a company with three programmers. (Solution: we hired more people, but created new projects for them.)
When you write programs with fewer programmers in the state, you save more than just money. As Fred Brooks noted in his book Mystical Man-Month, an increase in the number of people in a project leads to its slowdown. The number of possible relationships between developers grows exponentially with the size of the group: the larger it is, the more time will be spent discussing how applications will work together, and the more errors will appear due to unforeseen dependencies. Fortunately, this process also works in the opposite direction: the smaller the group, the higher the exponentially increasing efficiency of the application development process. I cannot recall that the programmers at Viaweb organize real meetings. We never spoke more at a time than we could say on the way to dinner.
If there is any flaw, it is that all programmers to some extent must also be system administrators. When you deploy an application, someone has to monitor the servers and, in practice, the only people who can do this correctly are those who wrote this application. In Viaweb, our system contained so many components and changed so often that there was no clear boundary between the application and the infrastructure. The voluntary assertion of such a boundary would limit us in the choice of design solutions. And so, although we constantly hoped that one day (“in a couple of months”) everything would be stable enough to work so that we could hire someone whose duties would only include taking care of the servers, but this never happened.
I do not think that there is another way out, while you are still actively developing the product. Web applications will never be what you write, save to the repository and go home. It is a living thing running on your servers right now. A terrible bug can not only destroy one of the user processes, but it can also destroy them all. If an error in your code destroys some data on the disk, then you should fix it. And so on. We found out that there is no need to check the servers every minute (after the first year or so), but you definitely want to keep track of what you recently changed. You can not release the code late at night, and then go home.
User Monitoring
In the server application, you are in closer contact with your code. And you can also be in closer contact with your users. Intuit is known for introducing customers to retail solutions and requests to visit their website from home. If you've ever watched someone use your app for the first time, then you know what surprises must have been waiting for him.
An application should do what users think it should. But you and the head will not come that in the minds of users, believe me, as long as you do not observe them. And server applications provide you with information about their behavior without any specifics. You are not limited to small, artificial focus groups. You can see every click made by each user. You will have to carefully determine what you are going to look at, because you don’t want to violate people's privacy, but even the most general statistical example can be quite useful.
When there are users on your server, you do not need to rely, for example, on benchmarks that are emulated by users. With server applications you can monitor real users. To decide what to optimize, just log in to the server and see what consumes all the CPU time. And you also know when to complete the optimization. We ended up bringing Viaweb to a point where it depended more on memory and not on processor speed, and since we couldn’t do anything to reduce the size of user data (well, nothing that was considered simple), we knew that we should stop at this.
For server applications, performance matters because you pay for the hardware. The number of users that you can maintain on one server is a divisor of your capital costs, so if you can create a fairly productive application, then you can provide it at a price lower than that of competitors and make a profit. In Viaweb, our capital expenditures per user were reduced to $ 5. And now they could be even less. Perhaps less than sending the bill for the first month. Now equipment costs you nothing if your applications are productive enough.
Monitoring users can lead you to both design and optimization issues. Viaweb uses the RTML scripting language, which allows advanced users to define the style of their personal pages. We found out that RTML has become a kind of magazine of feedback and suggestions, because users used it only when ready-made page styles could not realize what they wanted. For example, the editor initially placed a panel with buttons across the page, but after a number of users used RTML to place the buttons at the bottom left, we implemented this option (by default) in the ready-made page styles.
And finally, by observing users, it is often possible to determine when they are having difficulty. And, because the customer is always right, this is a sign that you need to fix. In Viaweb, the key point in understanding users was a trial launch online. It was not just a sequence of slides compiled by marketers. In our test run, users actually used the application. It took about 5 minutes, and in the end they created a real working store.
It was through this test drive, we realized that we need almost all of our new users. I guess the result would be the same for most web applications. If users can successfully complete the test run, they will love the product. If they get confused or bored, then no. Therefore, everything we could do to attract more people through a test run would increase our growth rate.
I studied the history of clicking on the links of people participating in the test run and found out that at a certain step they got confused and clicked the mouse on the back button of the browser. (If you try to write a web application, you will find that the "Back" button goes into the category of one of the most interesting philosophical problems.) Therefore, I added a message in this place explaining to users that they were almost finished and that they did not click on back button. Another great thing about web apps is that you get an instant response to changes: the number of people who completed the test run immediately increased from 60% to 90%. And since the number of new users depends on the number of completed test-drives, our income has grown by 50% only because of these changes.
Payment
In the early 1990s, I read an article in which someone said that software is a subscription-based business. At first this statement seemed very cynical. But then I realized that this reflects reality: software development is a continuous process. I believe that it will be more honest if you openly designate the cost of a subscription instead of forcing people to buy and install new versions so that they continue to pay you. And, fortunately, a subscription is a natural way to pay for web apps.
Application hosting is an area where firms will play a role in a niche that most likely will not be filled with free software. Application hosting is a lot of stress, and you have to spend some money. No one wants to do it for free.
For web application companies, this is an ideal source of income. Instead of starting each quarter from scratch, you will have a periodic income. As your application spins up gradually, you don’t need to worry that the new model will crash; The new model, as such, will not be needed, and if you add something in the application that users will perceive with hostility, then you will immediately find out about it. You have no problems with ineligible bills: if someone doesn’t pay, you simply turn off the service. There is also no possibility for piracy.
This last “advantage” can lead to a problem. Some pirated activity is beneficial to software companies. If any user really would not have bought your application for any price, you would not lose anything from the fact that it uses a pirated copy. In fact, you even benefit from this, because it is another user who helps to make your application a reference, or who can buy a copy of the application later when he graduates from university.
Companies love to discriminate as much as possible, which means giving each customer the highest possible price they can afford. [8] Software is particularly suitable for price discrimination, since marginal costs are close to zero. That is why some applications for running on Sun computers cost more than analogs for Intel: a company using Sun is not interested in saving money and can pay more. Piracy, in essence, is the lowest level of price discrimination. I think that software development companies understand this and deliberately do not notice certain types of piracy. [9] As for server applications, they will come up with another solution.
Web applications sell well, especially when compared to desktop software, because it is easy to buy. You might think that the decision of people to buy something, and the subsequent purchase are two separate steps. So I thought earlier in Viaweb, as I thought about this topic in principle. In fact, the second step can go back to the first: if something is difficult to buy, people will begin to doubt whether they need it. And vice versa: you will sell more if it is easy to buy. I buy more books because there is an Amazon. A web application is simply the simplest thing in the world to buy, especially if you have just done an online demo. Users do not have to perform many actions, but only enter a credit card number. (Forcing them to do more actions at their own risk.)
Sometimes web applications are distributed through Internet service providers acting as resellers. It is a bad idea. You will have to manage the servers, because you need to constantly improve both the hardware and the software. If you miss direct control of your servers, you will miss most of the benefits of developing web applications.
Some of our competitors thus hacked the branch on which they sat. Usually, as I believe, this happened because they had a surplus of board members, who were delighted with such a huge potentially profitable channel, and did not realize that this would destroy the product that they hoped to realize through it. Selling web applications through Internet providers is like selling sushi through vending machines.
Customers
Who are your customers? For Viaweb, these were initially individuals and small firms, and, as it seems to me, in web applications this will become a well-established rule. Such users are willing to try something new, partly because they are more flexible, and partly because they want to spend less on new technologies.
Also, web applications will often be considered as the best option for large companies (although they will slowly realize this). The best enterprise computer network is the Internet. If a firm uses real web applications, then applications will work better, servers will be better monitored, and employees will have access to the system from anywhere.
Arguments against this approach are usually closely related to security: if access is simplified for workers, then it will be for attackers as well. Some of the larger sellers were reluctant to use Viaweb because they believed that customer credit card information would be safer on their own servers. It was not easy to solve this by diplomatic means, but in reality, it was almost certainly safer to keep the data on our side and not on them. Who can hire the best people to manage security: a tech start-up, whose business is completely running on servers, or a clothing retailer? We have not only the best people responsible for security, but we ourselves pay more attention to it. If someone hacks into the servers of a clothes seller, then this will affect mainly one trading company, and this business may be closed up, and, in the worst case, they will fire one person. If someone hacks our servers, it will affect thousands of trading companies, and perhaps everything will be in the news on CNet, and we will lose our business.
If you want to save your money, then you keep it under a mattress at home, or give it to the bank? This applies to any aspect of server management: not only security but also uptime, bandwidth, load management, backup, etc. Our existence depends on the proper performance of these things. The presence of problems with the server was absolutely unacceptable for us, as for the creator of toys, dangerous toys are unacceptable, or a flash of salmonellosis for a food processor.
Large companies that use web applications, to some extent, transfer some of the IT functions to outsourcing. No matter how harsh it may sound, I believe that, in general, this is a good idea. So firms are more likely to get better service than if they organized their own staff of system administrators who can become wayward and immune because they are not directly subjected to competitive pressure: the seller works with customers, the developer works with competitors, and the system administrator like an old bachelor, there are only a few external factors that keep him afloat. [10] In Viaweb, external factors for keeping oneself afloat were abundant. The people calling us were customers, not just colleagues. If the server got stuck, we were immediately undermined; the very thought of it makes you feel a surge of adrenaline, even after years.
Therefore, usually, web applications will be the right solution for large companies. However, it comes to them last, as was the case with desktop computers. And partly for the same reason: convincing large companies that they need something more expensive will cost a lot of money.
There is always a tendency for rich customers to buy expensive solutions, even when cheap solutions are better, because people who offer expensive solutions may spend even more trying to sell them. We at Viaweb have always been strongly against this approach. We lost a few high-class sales representatives who went to a web consulting company that convinced them that they would be in a better position if they paid half a million dollars for a custom-made online store on their own server. As a rule, they did not fall into an advantageous position, since it was discovered that with the onset of the Christmas shopping season, their server load increased. Viaweb was a much more complex product than that of most sales representatives, but we did not have the opportunity to tell them about it. Working for $ 300 a month, we could not afford to send a team of decently dressed and powerful people to our clients to present the product to our clients.
The main share of what large firms pay an increased price for is the cost of selling them expensive items. (If the Department of Defense pays $ 1,000 for toilet seats, this is partly because it takes a lot of money to sell toilet seats for $ 1000.) And this is one of the reasons why software intranet will continue to flourish, even if and bad decision. It is just more expensive. And you can’t do anything about it, so the best course of action would be to turn your attention first to smaller clients. Everything else will follow at the right time.
Son of server
There is nothing new in the launch of the application on the server. In fact, this is an outdated model: all applications for supercomputers are server applications. If server applications are such a good idea, why did it lose to others? Why desktop computers overshadowed the supercomputer?
At first, desktop computers were not considered as a direct threat. All the first users were polls by computer experts or enthusiastic people. They liked the microcomputer, because they were cheaper. For the first time you had your own computer. The phrase "personal computer" is now firmly in use, but when it was first used, it had an intentionally bright sound, like the phrase "personal satellite" today.
Why did desktop computers win? I guess because their software was better. And I think that the reason why microcomputer applications were better was because small firms could write them.
I don’t think that many people realize how fragile and unsure startups are at an early stage. Many startups start almost by accident: a couple of young people, either with a permanent job, or schoolchildren, write a prototype of something that could, if it looked promising, turn into a company. In such an embryonic state, any significant obstacle will tightly freeze a startup. Writing software for supercomputers required too many obligations. Software development computers were expensive, and since the clients were large firms, you would need impressive sales staff to sell them. Starting a supercomputer software start-up would be a much more serious matter than just tinkering programs on your Apple II in the evenings. Therefore, there was not a large number of startups to create such software.
The emergence of desktop computers inspired the creation of new applications, because the development of programs seemed to be an achievable goal for "rudimentary" startups. The development was cheap, and customers were individuals with whom it was possible to establish contact through computer stores or even trade by mail.
The application that translated desktops into the mainstream was called VisiCalc, the first spreadsheet editor. Two guys wrote it in the attic, and it did things that no supercomputer application could do. [11] VisiCalc was such a breakthrough at the time that people bought an Apple II just to launch it. And this was the beginning of a new trend: desktops won because startups created applications for them.
It seems that server applications would be most welcome, since startups will write them. Now computers are so cheap that you can start with the same thing as we, i.e. use the desktop as a server. Low-cost processors swallowed the workstation market (you’re hardly likely to hear this phrase now) and mostly through the server market; Yahoo servers that handle the load, like all other servers on the Internet, are all equipped with low-cost Intel processors that are installed on your desktop.And when you wrote the app, all you need to sell is a website. Almost all of our users came directly to our site via word of mouth and press links. [12]
Viaweb was a typical “embryonic” startup. We were scared to organize a company, and, during the first few months, we calmed ourselves, taking it all as an experiment that we could interrupt at any time. Fortunately, there were other problems besides technical issues. During the writing of the application, our web server played the role of a desktop PC used in the development process and was connected to the rest of the world via a telephone line. Our only expenses at this stage were food and rent.
Now for startups there are even more reasons for creating web applications, because developing software for desktop computers is no longer so interesting. If you now want to write applications for desktop computers, then you do it under Microsoft conditions, calling their API and working with their buggy OS. And if you manage to write something that shoots, you might find that you were just doing marketing research for Microsoft.
If a firm wants to create a platform on the basis of which start-ups will be implemented, then it must be such that the programmers themselves would like to use it. Which means that it should be inexpensive and well designed. When Mac first appeared, it was popular among computer professionals, and many of them wrote applications for it. [13] In the case of Windows, this was less noticeable, since programmers did not use it. Now, people who are good at application development tend to use Linux or FreeBSD.
I do not think that we would organize a startup for creating software for desktop computers, because such software must run on Windows, and before writing software on Windows, we would have to use it. The web allows you to bypass Windows, and provide software that runs on Unix, directly to users through a browser. This is a great chance to get rid of addictions, which is very similar to the appearance of a PC 25 years ago.
Microsoft
Long ago, when desktop computers appeared, IBM was a giant everyone was afraid of. It is difficult to imagine now, but I remember this feeling very well. Right now, Microsoft is an intimidating giant, and I don’t think they don’t understand the threat looming in front of them, as IBM did. In the end, Microsoft deliberately began to run its business in the IBM blind zone.
I once mentioned earlier that, for example, my mother does not need a desktop computer at all. And, probably, most users do not need this either. That's the problem with Microsoft, and they know it. If applications run on remote servers, no one needs Windows. What will Microsoft do? Will they be able to use their control over the PC to prevent or limit this new generation of applications?
I will assume that Microsoft will develop some sort of hybrid server and desktop application, where the operating system works in conjunction with the servers they manage. At a minimum, files will definitely be available to users who need it. I don’t think that Microsoft will go to extremes and organize calculations on the server, where only the browser will act as a client if they can avoid it. If you only need a browser as a client, then you don’t need Microsoft on the client machine, and if Microsoft doesn’t manage the client, they will not be able to force users to switch to their server applications.
I believe that it will be difficult for Microsoft to keep technology within tight boundaries. There will be too many different types of clients to control them all. And if Microsoft applications work only with some clients, competitors will be able to jump them, offering applications that run on any client. [14]
In the world of web applications for Microsoft there is no automatically allocated space. They can succeed in creating it on their own, but I don’t think they will hold a leading position in this new world, as they did in the world of desktop applications.
The point is not only that competitors will furnish them, but also that they dig a hole for themselves. As web applications develop, they will face not only technical problems, but also their wishful thinking. They need to absorb their current business, and I can not imagine that they will go for it. The same sense of purpose that has led them so far will now work against them. IBM was in exactly the same position and could not handle it. IBM made a belated and indecisive entry into the microcomputer market because they experienced an ambivalent feeling endangering their cash cow — the use of a supercomputer. Similarly, Microsoft will be constrained in their actions, wanting to save desktop solutions. A reliable source of money can turn into a rather heavy burden.
I do not claim that no one will be able to dominate in the field of server applications. Probably in the end, someone will do it. But I want to say that it will take quite a lot of time amusing confusion, just like at the dawn of the microcomputer. It was a good time for startups. Many small firms have flourished, creating cool stuff.
More than just a startup
A classic startup is organized quickly and without unnecessary formalities, with a small staff and budget. These few people work hard, and technology enhances the effect of their decisions. If they win, they win big.
In a web application startup, everything that you associate with startups is taken to the extreme. You can create and launch a product with even fewer people and even a smaller budget. Only you will have to be even faster and reduce the level of formalities. You can run the product in the literal sense of the word, with three people in the living room of someone's apartment, and a server from an Internet provider. We have all been so.
Over time, the teams became smaller, faster, and more relaxed. In 1960, software development meant a room full of people wearing horn-rimmed glasses with narrow black ties, who were hard at writing 10 lines of code a day in IBM coding. In 1980, it was a team of 8-10 people coming to the office in jeans and typing in vt100 terminals. Now this is a couple of guys sitting in the living room with laptops. (And jeans turned out to be not the last point in providing an atmosphere of ease and freedom.)
Startups have a lot of stress, and, unfortunately, this is also brought to the extreme in the field of web applications. Many software development companies, especially at the beginning, had moments when developers slept under tables, etc. The alarm may be the fact that nothing can prevent the transition of this phenomenon into constant practice. Stories about how someone sleeps under the table usually end like this: and finally, we saved all the changes and went home, and slept all week. In web applications, you cannot take and make all changes. You can work 16 hours a day for as long as you want. And sincecan you, and your competitors too, you already have to do it. You can, therefore you should. Parkinson's law is the opposite.
The worst is not the number of hours worked, but responsibility. Programmers and system administrators have traditionally different concerns. Programmers should think about bugs, and system administrators should think about infrastructure. Programmers can spend the day after spending it buried in the source code, but at some point they will have to go home and forget about all this. System administrators never leave work for later, but when they receive a message at 4 am, they usually don’t have to do anything quite complicated. In the world of web applications, these two types of stress are combined. Programmers become system administrators, but without well-defined boundaries, which usually make work tolerable.
In Viaweb, we spent the first 6 months just writing a program. We worked a typical extended working day of a startup in the early stages of development. If we were in a desktop application development company, we would tell you how hard we work, but it feels comparable to a vacation, if we take in comparison with the next stage, where we let users onto our server. The second big advantage (after money) from the sale of Yahoo's Viaweb to Yahoo was the ability to shift all responsibility for all this onto the shoulders of a large company.
Desktop applications force users to become system administrators. Web applications are forcing programmers to become such. The total amount of stress is less, but its share is higher for programmers. This is not always bad. If you started a startup and compete with a large company, then this is good. [15] Web applications offer a direct way to outperform your competitors. And startups don't need more.
And so good
The only thing that can scare you from creating web applications is the wretchedness of web pages when used as a user interface. I admit, this is a problem. We really wanted to add a couple of things in HTML and HTTP. But in fact, what matters is that web pages are so good.
An analogy with the first microcomputers is traced here. The processors in these machines were not really intended to be used as central processing units. They were intended for use in traffic lights, etc. But people like Ed Roberts, the creator of Altair, realized that they were well suited for this purpose too. It was possible to combine one of these chips with some kind of memory (in the first Altair there were 256 bytes of memory), add the front panel of switches, and now you have a working computer. The ability to assemble your own computer was such an exciting idea that there were a lot of people who wanted to buy them, although their number was limited.
Web pages were not created to serve as an interface to web applications, but they are so good. And for a significant number of users of applications that can be used from any browser, it will be enough to really overcome the rejection of some sluggishness in the UI. You may not be able to create the most beautiful spreadsheet using HTML, but you can create a table that several people can use at the same time from different places without special client software, or which can combine real data, or which can send you a notification when certain conditions are triggered. More importantly, you can create new kinds of applications that have no names yet. VisiCalc was not just a supercomputer application with a microcomputer version, after all,It was a new type of application.
Of course, server applications are not required to be web applications. You could have some other customer. But I'm sure this is a bad idea. It would be very convenient if you could assume that everyone will install your client. It is so convenient that you could easily convince yourself that they will all do so, but if they do not want it, then you will be tied hand and foot. Since web applications do not make any assumptions about the client side, it will work wherever the web works. And this is a great advantage, and it will only increase as new web devices spread. Users will like you, because your application just works, and your life will become easier, because you do not have to customize it for each new client. [sixteen]
I have a feeling that I looked at the evolution of the web scope in the same detail as any of us, but I cannot predict what will happen with the client content. Probably convergence is coming, but at what point? I can not determine the leader. The only thing I can predict is the disagreement between AOL and Microsoft. Whatever the resultant Microsoft .NET technology is, it will most likely include the PC connection to the server. Until AOL starts downloading the rights, they will either be pushed aside, or turned into a layer between the Microsoft client and the server software. If Microsoft and AOL start a war for a client, the only thing that will work for both is browsing the web, i.e. Web applications will be the only software that runs everywhere.
How is all this resolved? I dont know.And you do not need to know if you make a bet on web applications. No one can break this trend without limiting the very possibility of browsing the web. Probably the web is not the only way to implement applications, but it is now the only working version that will continue to work for a long time. Web applications are cheap to develop and easy to distribute even to the smallest startup. You need to work a lot on them and experience a lot of stress, but this only increases the chances of a startup.
Why not?
E. B. White was amused by the fact that, as a farmer friend told him, many of the electric current hedges were not really energized. When the cows learned to stay away from them, there was no longer any need to pass current through the hedge. “Get up, cows! - he wrote, - Go to freedom, while your tyrants snore! ”
If you are an IT person who has already thought of starting a startup once, then you are probably holding back two things. First, you know nothing about business. Second, you are afraid of competition. But none of these barriers are not connected to an electric current.
Here are two things you need to know about business: do what users love and earn more than you spend. If you learn this well, you'll be ahead of most startups. In all other respects you will understand along the way.
Perhaps at first you will not be able to earn more than you spend, but as soon as this gap starts to narrow enough quickly, everything will work out for you. If you start with less cash, this will at least contribute to the development of the habit of thrift. The less you spend, the easier it is to earn more of your expenses. Fortunately, launching a web application can be very cheap. We started with a budget of less than $ 10,000, and today it is even cheaper. We had to spend thousands on a server, and a few thousand more on SSL. (The only firm selling SSL software at the time was Netscape.) Now you can rent much more powerful servers, already with SSL, and pay less for it than you had to pay only for bandwidth. You could now launch a web application for a cost,lower cost of a good office chair.
Regarding the creation of what users will love, here are some general tips. Start by creating something clear and simple that you yourself would like to use. Quickly release version 1.0, and then continue to improve the application, carefully listening to users as they go. The customer is always right, but different customers are right about different things; the least experienced users will show what needs to be simplified and explained, while the most experienced ones will indicate what functionality they need to add. The best that an application can do is to be simple, but in order to achieve this, you need to rightly identify all the “default” work scenarios right away, and not restrict users from choosing. Do not bother if the competitor’s application is bad; the benchmark with which you need to compare your application is what it could be, and not whatwhat happened to the competitors. Use your software all the time. Viaweb was designed as an online store designer, but we also used it to create our own website. Do not listen to marketers, designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.designers and product managers just because of the name of their posts. If they have good ideas, use them, but that’s up to you; Applications should be developed by specialists who understand what design is, and not designers who know a little what applications are. If you can neither design an application nor implement it, do not start a startup.
And now let's discuss the competition. What you are afraid of is not supposed groups of programmers like you, but real companies, with offices and business plans, vendors, etc., right? Well, they are more afraid of you than you, and they are right. It is much easier for a pair of hackers to figure out how to rent an office space or hire people to conduct sales, than to write an application for a company of any size. I have been on both sides of the barricades, and I know what I'm talking about. When Viaweb was bought by Yahoo, I suddenly discovered that I was working for a large company, and this was tantamount to running to the waist in the water.
I do not want to belittle Yahoo. They had some good specialists; top managers were real monsters. For a large company, this is rare. But still, they are productive only a tenth of a small startup. And no large firm can do better. What scares Microsoft is that such a large company can even develop applications. They are like a mountain that can move.
Do not let yourself be intimidated. You can do what Microsoft can't do, and they can do what you can't do. And no one will stop you. You do not need to ask anyone for permission to develop web applications. You do not have to deal with issues with licensing, or request a place on the shelf of retail stores, or kowtow to the owners of the OS, so that your application will be included in its composition. You can provide the application directly through the browser, and no one can come between you and potential users without closing the web.
You may not believe it, but I guarantee that Microsoft is afraid of you. Complacent middle managers, maybe not, but Bill surely, because he was once in your place, back in 1975, when the last time a new way of software distribution appeared.
Notes
[7] Robert Morris wrote an ordering system that buyers used to place orders. Trevor Blackwell wrote an image generator and a manager that sellers used to view orders, statistics, domain name settings, etc ... I wrote an editor that sellers used to create their sites. The ordering system and image generator were written in C and C ++, the manager was mainly written in Perl, and the editor was written in Lisp.
[8] Price discrimination is so common (how often have you heard a retailer say that their purchasing power would mean lower prices for you?) That I was very surprised when I learned that in the US, the Robinson-Patman Act of 1936 she declared illegal activity. By the adoption of such a law, it seems, is not particularly forced.
[9] Naomi Klein of No Logo says clothing brands that are popular with “urban youth” are not particularly trying to prevent shoplifting because shoplifters are also leading fashion players in their target market.
[10] Firms often wonder what to outsource and what not. One possible answer: to outsource any work that is not directly exposed to competitive pressure, because, therefore, its outsourcing will put it under this very pressure.
[11] The two guys were Dan Bricklin and Bob Fraxton. Dan wrote a prototype on Basic for a couple of days, then over the next year they worked together (mostly at night) to create a more powerful version written in the 6502 computer language. Dan was studying at the Harvard Business School at that time, and Bob officially had a permanent work where he wrote the application. “There were no major risks in the conduct of your business,” Bob wrote, “If it does not work out, then it will not work out. Nothing special".
[12] It's not quite as easy as I voiced it. It will take a lot of painful time for word-of-mouth radio to work, and we didn’t have frequent press coverage until we hired a PR firm (and really the best in the business) for $ 16,000 a month. However, the truth is that the only significant channel was our own website.
[13] If the Mac was so cool, why did it lose? Again, the point is the price. Microsoft focused on software development, and released a crowd of suppliers of cheap components for Apple hardware. But it also did not help, that suits during the critical period.
[14] The only thing that would help web applications and keep the next generation of applications from being overshadowed by Microsoft is a good open-source browser. Mozilla is an open-source browser, but seems to have suffered from staying too long in the role of a corporate application. A small fast browser that would actively support, in itself would be great, and also, perhaps, would inspire companies to implement small web devices.
In addition, a suitable open-source browser would be the reason for the further development of HTTP and HTML (such as Perl, for example). This would greatly help web applications recognize the selection of a link and the passage through it; all that is needed for this will be a banal HTTP extension, which will allow you to contain several URLs in the request. A cascading menu would also be good to implement.
If you want to change the world, write a new Mosaic. Think too late? In 1998, many people thought it was too late to launch a new search engine, but Google proved the opposite. There is always room for something new if current solutions are pretty poor. First make sure that it works on all free operating systems, since new begins with their users.
[15] Trevor Blackwell, who, perhaps from his personal experience, knows more about this than anyone, writes: “I would add that, because server applications are too harsh with programmers, it causes a significant economic outflow from large firms. Programmers need some energy and dedication, which they can show only when it is their own firm. Software development firms can hire experienced people to work in a less demanding environment, and they can hire inexperienced people to experience difficulties, but they cannot hire highly qualified people to get rid of their jobs. Since capital investments have ceased to be a mandatory element, large firms may have little interest. "
[16] In the original version of this essay, I advised to avoid Javascript. Such a plan was good for 2001, but Javascript now works.
Hackers and artists
Chapters and translations
www.paulgraham.com/hptoc.html
- Why Nerds Are Unpopular
Their minds are not on the game.
original translation part 1 part 2 - Hackers and painters
Hackers are makers like painters or architects or writers.
original , translation part 1 , part 2 , alternative - What you cant say
How to think with them.
original translation - Good bad attitude
Like Americans, hackers win by breaking rules.
original translation - The other road ahead
Web-based software offers the largest since the arrival of the microcomputer.
original translation part 1 - How to Make Wealth
The best way to get rich. And startups are the best way to do that.
original translation - Mind the gap
Could "unequal income distribution" be less than a problem than we think?
original translation - A plan for spam
Till recently most experts thought spam filtering would not work. This proposal has changed their minds.
original translation - Taste for Makers
How do you make great things?
original translation - Programming Languages Explained
What is a programming language?
transfer - The Hundred-Year Language
How will we program in a hundred years? Why not start now?
original translation - Beating the Averages
For web-based applications. So can your competitors.
original translation - Revenge of the Nerds
In technology, "industry best practice" is a recipe for losing.
original translation 1 , 2 , 3 - The dream language
A good programming language is hackers have their way with it.
original translation part 1 part 2 - Design and Research
Research has to be original. Design has to be good.
original translation
Source: https://habr.com/ru/post/283262/
All Articles