What Startups can Learn from UNIX

unix.pngWhy has UNIX enjoyed such a tremendous run, and what can today’s startup companies learn from it? It occured to me the other day that there are actually a lot of parallels between the success factors behind UNIX, and successfully building a new startup.

The UNIX family of operating systems (including SVRx, SunOS/Solaris, HPUX, AIX, Linux, FreeBSD, et al) continues to be successful nearly 40 years after its inception. 40 years! There aren’t many technological innovations that hang around more than four (4) years after they arrive, much less forty. The same can be said of most tech startups, the vast majority of which never make it to their guaranteed promise of “1% of all the people in China drinking our Kool-aid.”

Warning – this is going to be perhaps the longest post I’ve ever published here at The Pothole. There is a lot to talk about! Even if you aren’t a UNIX fanatic, or even if you have no idea what UNIX is, I hope that you will find some nuggets of insight here that will help you in your quest to build a great new company.

Before I launch off into my long-winded diatribe, I will share a personal observation. I think a lot can be said for the adaptability of the UNIX operating system. Over the years, it has seen line duty in just about every conceivable IT scenario; from developer’s playground to transaction processing to desktop publishing. No matter the challenge, UNIX offered a flexible enough framework to get the job done. Something to keep in mind.

But what else … ? To make the requisite analogies, we’ll need to dig into what is known as the “Unix philosophy.”

The so-called “UNIX philosophy” originated with Ken Thompson’s early meditations on how to design a small but capable operating system with a clean service interface. It grew as the UNIX culture learned things about how to get maximum leverage out of Thompson’s design. It absorbed lessons from many sources along the way.

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity – Dennis M. Ritchie

Do one thing and it do it very well

a-quarter-century-of-unix.jpgIn Peter Salus’ 1994 seminal work, “A Quarter Century of UNIX” he summarized what Doug McIlroy (the inventor of UNIX pipes) was saying at the time.

This is the UNIX philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Over the years, the philosophy” has been generally reduced to the first tenet: do one thing and do it very well. Sound familiar? It should.

One of the biggest trends right now among technology startups is the continued focus on smaller, tighter things. Startups are no longer purporting to take over the world within 5 years. They are now saying “this piece of the puzzle is what we do, and we want to do it better than anyone else.”

The other day I was in my office rifling around through some old papers. I came across a business plan that I was handed about 5 or 6 years ago (flee! run away! flee!). Before you start laughing, this company is actually still around. I flipped through their business plan and chuckled to myself as I saw their revenue projections and their “master plan” for taking over the free world by creating online markets in 3 dozen different places. Today, the company is profitable, and doing well. Their focus however, is on one very tightly focused vertical market. It is much easier to become a best-in-class, as opposed to a “everything-to-everyone.”

Write programs that work together

Looking at Salus’ other two tenets, there are also parallels to startups. Niche startups tend to blossom when they have an effective array of partners (write programs to work together). An integral part of any good business plan is a firm partnership strategy. Who will we partner with in order to bring our value to the market? Who can we partner with that will augment the thing that we do so well? You can be the best widget maker in the world, but if you don’t partner with people to get them to consumers (distributors, retailers, catalogs, etc.), then you may as well call the coroner – your business is dead. As you plan your new business, spend some time figuring out who is adjacent to you in your space, and who can help you get move vertically or horizontally as desired.

The Universal Interface

On a side note, the “universal interface” of text streams that Salus refers to could also be made analagous to the many standards by which technology startups have to abide (XHTML, W3C, open-this, open-that). Better to be compliant out of the gate, than have to go back and re-engineer. Users today are a helluva lot smarter than they were even 5 years ago. When my grandmother asked me which RSS news reader I recommended, all bets were off. So, keep an eye toward the standards, and get involved with the proposed standards that might affect your particular industry.

Hmm, okay, so all of this sounds great, but is there more? You bet!

unixphil.gifMike Gancarz, the author of The UNIX Philosophy, published his list of tenets as well. Among them we find these nuggets of wisdom:

  1. Small is beautiful.
  2. Make each program do one thing well.
  3. Build a prototype as soon as possible.
  4. Choose portability over efficiency.
  5. Use software leverage to your advantage.

I don’t think I have to explain the first tenet at all, and the 2nd one we’ve already discussed. The other 3 warrant a little discussion, though.

Build a prototype as soon as possible.

This tenet developed because it is extremely difficult to predict the results of a software development project without first developing the software.

This idea runs counter to many software engineering methods which state that a majority of the design must be completed before any code is written. It is really an extreme form of prototyping and is intended to aid in the development of the final system. Prototyping is used to learn about the system and to reduce the risk of major problems in the final system.

I am a huge fan of Guy Kawasaki. Not that I have posters of the guy on my wall, but he speaks the plain truth (or as Guy would say, no “bull shiitake”). In his must-read book, The Art of the Start, Guy states that entrepreneurs are either “prototypers” or “typers”:

I think the world is essentially divided into two groups: the prototypers, the people who build stuff, and the typers, the people who think the key to entrepreneurship and innovation is Microsoft Office. If you think that the key to innovation and entrepreneurship is Microsoft Office, something is wrong with you. If you’re thinking, “I have to write a business plan with Word; I need to create a pitch with PowerPoint; I need to build a 30-page financial model with Excel,” you’re on the wrong track. The key to all of this is to prototype, not type.”

I will add that there is a time for proper “business planning” using all of the implements that Guy describes. However, “getting something” up there should be goal number one. Of course, you need to ensure that what you “throw against the wall” will stick – in other words, it is functional enough to show your value. This is one of the key driving forces behind the current generation of web plays (no, I am not going to say Web 2.0 … damn, I just did!) In fact, it has been my experience that prototyping can actually help you refine your vision, and subsequently, your business planning around it.

Choose portability over efficiency.

Software which is written specifically for one architecture is limited in its marketability and is usually quite difficult to port.

  1. Next year’s hardware will run faster — performance may not be an issue in a short amount of time.
  2. Don’t spend too much time making programs run faster — tuning a program is expensive and the gains are often not worth the time.
  3. The most efficient way is rarely portable — programs tied to hardware are rarely portable. Hardware which is state-of-the-art when you create a program will soon be outdated and the worth of the program will drop quickly. It is better to have drivers for hardware which take advantage of advanced features but which also provide a consistent/stable programming interface.
  4. Portable software reduces the need for user training.
  5. Good programs will be imitated by others if you cannot port them.

In the world of software engineering, efficiencies can lead to deep vertical paths. Back in “the day” when I used to write C code, optimizations often included inline assembler code that fiddled with registers and opcodes specific to the platform we were working with. Efficient? Very! Portable? Hell no.

In this day and age, portability, or the ability to move horizontally with a solution is far more valuable than most efficiencies. Stay focused while you build your company, but always do so with an eye towards tomorrow.

Use software leverage to your advantage.

Only so much can be done by one individual or group and a great deal has already been done.

  1. Good programmers write good code; great programmers “borrow” good code — incorporating other people’s modules and programs into your project has several advantages. It frees large amounts of development time, the obtained code is tested and debugged by the author, and it makes you look efficient.
  2. Avoid the not-invented-here syndrome — there is no reason to reconstruct software which already exists. Most common applications are now standardized and produced by companies which specialize in their production.
  3. Allow other people to use your code to leverage their work — the most successful software is the one which appears on the most computers. Proprietary software is usually more difficult to integrate into a system and if your product is too much trouble to use then competitors will develop a better version.
  4. Automate everything — simply put, take advantage of the computing environment to do as much work for you as possible. Learn the shortcuts which the shell and many commands provide.

As Gancarz states above, “Good programmers write good code; great programmers borrow good code.” It was true back in 1968 and it is true today – probably even more so today, given the drastic complexity in our application demands. As I have mentioned before, in a startup, time is currency. Don’t reinvent the wheel. There is simply no need for it in this day and age of open source.

There are some damn good free solutions out there. And I’m not just talking about the enterprise stuff (SugarCRM, for example). As any good programmer knows, if you poke around Google long enough, you’ll eventually find 10 other guys that have solved the same problem you are currently facing. Don’t spend hours or days spinning your wheels. Go to Google, Usenet, CPAN, DevShed, et al and download the code that has already been written. You’ll thank me later when you are my age and still have all of your hair.

Those who do not understand UNIX are condemned to reinvent it, poorly. — Henry Spencer

Gancarz offered a number of “lesser tenets” as well. Among them, we find these winners:

  1. Allow the user to tailor the environment.
  2. Make operating system kernels small and lightweight.
  3. Use lowercase and keep it short.
  4. Save trees.
  5. Silence is golden.
  6. Think parallel.
  7. The sum of the parts is greater than the whole.
  8. Look for the 90-percent solution.
  9. Worse is better.
  10. Think hierarchically.

Allow the user to tailor the environment.

Empowering users is perhaps the largest driving force behind Web 2.0 plays. In the new iteration of the web, the user is king. In a UNIX environment, the user largely controls the show. It is this same way with the customers of today’s startup companies. Users have hyper-expectations now, so you’d better feed ’em what they need.

Make operating system kernels small and lightweight.

The core of the UNIX system (the kernel) is relatively lightweight (when compared to the brains of “other” operating systems – ahem.) Smaller is better. The more complexity you introduce into the kernel, the higher the likelihood that something will go catastrophically wrong.
The same goes for the management team of a startup. Think flat governance – keep things small and efficient – dont deploy too many cooks in your kitchen. Every friend you have doesn’t need to be a Vice President.

Use lowercase and keep it short.

Most UNIX commands are short, sweet, and simple, and consist of nothing more than a brief sequence of letters. For example, to list the files in a directory, you type “ls.” To view the status of processes, you type “ps.” To create a new directory, you type “mk.” Sure beats “list_files”, “process_status”, or “make_directory!” Motto here? KISS (Keep-It-Simple-Stupid). Think efficiency, efficiency, efficiency.

On a humorous note, when I used to teach my UNIX Essentials course down at the University of South Florida, I would spin a yarn about the so-called “Limited Keystroke Theory.” This ficitious theory purported to tie the length of one’s career as a programmer to the number of “keystrokes” a person had in them. Each person was born into this world with a set number of keystrokes. Once those keystrokes were used up, your career was over. By making all of the UNIX commands as succinct as possible, we could conserve keystrokes, thus elongating our careers. Ha!

Save Trees.

Sneaker-net is a bad thing, Virginia, despite what your friends tell you. Automation is key for a startup. Automation is not a dirty word. Many things can be automated with very little effort. If you are still manually performing a lot of your processes, and haven’t at least begun thinking about ways to automate things, you are in for a long road. This includes printing out reams of paper. Don’t do this. Words on paper are great if you are in the john, doing some “strategic planning”, but you can’t leverage the information. When possible, strive to keep information in electronic form, where you can harvest and leverage it. The benefit is that you get to save some trees as well!

Silence is Golden.

In the UNIX world, generally speaking, if a command doesn’t have anything important to report, it simply exits with no output. It is done this way because every program is designed to be a “filter”, and used in conjunction wih piping data, so sometimes, you don’t want any output. What can startups learn from this tenet?

Well for starters, learn to fly under the radar. Remember the old saying that states if an idea is good enough to be doing, then somewhere out there are 20 guys in 20 different garages who are thinking about it as well? There is some truth to this – so don’t feed them info via the media until you are ready. And if you do decide to put out information, be cognizant of this reality.

Additionally, avoid falling into trap of thinking that a voluminous amount of press releases will scare your competition away. It won’t, and it will only make you look silly. Unless you have something important to say, don’t say anything.

Think Parallel.

In a UNIX environment, the CPU is seldom busy for long. Therefore, in order to get the most out of the CPU, it should be kept busy with parallel tasks whenever possible. In a startup environment, everyone needs to wear multiple hats. Additionally, the motor always needs to be running – if you have downtime in one area, shift your focus to something else. Never stop moving forward. Pausing wastes time. And again, in a startup, time is currency.

The sum of the parts is greater than the whole.

One of the great things about UNIX is that if a solution to a problem isn’t readily apparent, the tools are there to cobble something together very quickly. By taking the many smaller programs and combining to produce a greater program, most problems can be tackled fairly quickly. For example, if I want to create a sorted list of all of the records in a file that contain my name, I can use the “grep” and “sort” tools together.

grep "Scott Burkett" datafile | sort

In the startup world, scarcity of resources is almost always an issue. Field-expedience and resourcefulness are two key attributes of the successful entrepreneur. You must always look to take the resources you have and make the most of them. Irrespective of the problem you are facing, f you close your eyes, take a deep breath, and focus on what you do have, rather than what you wish you had, you'll be surprised at the innovation that will invariably ensue.

Look for the 90 percent solution.

In the UNIX mindset, solving 90% of the pain is just as good as solving 100% (most of the time). It is easier to solve most problems by ignoring the most difficult 10% of the problem. As a new startup, your immediate goal should not be to solve the whole problem, just most of it. You can get to market much faster with a 90% solution, and then drive towards the reminaing 10% over the long-term.

If you have a pounding headache, would you rather have an aspirin that got rid of 90% of the pain now, or wait a year until you can get one to get rid of 100% of the pain?

Worse is better.

While amazingly powerful today, UNIX was never intended to play at the high-end of the server market. In fact, it was only really meant to be a developer's sandbox. Nevertheless, it adapted, improvised, and overcame, as it were. It grew to fill the low end minicomputer, and later, the workstation market. You now see it everywhere, even on the desktop in some cases. You can read more about the "worse is better" philosophy at Wikipedia, but basically it boils down to a belief that the simplicity of both interface and implementation is more important than any other system attribute (including correctness, consistency, and completeness).

As long as the initial program is basically good, it is easier to port to new machines and situations, and will take much less time and effort to implement initially. Thus, its use will spread rapidly, long before a program developed using [a traditional approach] has a chance to be developed and deployed. Once it has spread, there will be pressure to improve it by improving its functionality, but users have already been conditioned to accept worse than the "right thing". "Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better."

So what does mean if applied to a startup context? In a way, it is a combination of 90% solution, keeping things lightweight, and choosing portability over efficiency. Start small, and build out a 90% solution, while keeping your eyes on ways to move that 90% solution to the masses. The market will do the rest.

Think hierarchically.

The method of ordering items from a more general description (top or "root" level) to a very specific one (node level) is a powerful way to arrange things. It is prevalent in so many aspects of our lives. From Windows "folders" to UNIX "directories" to company organizational charts to those org charts the police have on the walls when they track the Mafia figures.

Remember the 90% solution? Thinking hierarchical is the path to it. Start at the top and work your way down into the appropriate level of detail, remembering to reign in the desire to screw around with that last 10%.

artunix.gifEric Raymond, in his book The Art of Unix Programming, summarizes the Unix philosophy as the widely-used engineering philosophy, "Keep it Simple, Stupid" (KISS Principle). He then offers his own rules/tenets for the UNIX philosophy:

  1. Rule of Modularity: Write simple parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Composition: Design programs to be connected to other programs.
  4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
  6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  8. Rule of Robustness: Robustness is the child of transparency and simplicity.
  9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  10. Rule of Least Surprise: In interface design, always do the least surprising thing.
  11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
  13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  16. Rule of Diversity: Distrust all claims for "one true way".
  17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

This blog post is already ridiculously long, so I am not going to analyze each of these. However, you should see some recurring themes here. Many of these revolve around the KISS principle. However, I want to provide a quick blurb on five of the more fitting of Raymond's tenets.

Rule of Parsimony

"Big" here has the sense both of large in volume of code and of internal complexity. Allowing programs to get large hurts maintainability. Because people are reluctant to throw away the visible product of lots of work, large programs invite overinvestment in approaches that are failed or suboptimal.

In the startup world, this is something akin to throwing good money after bad. If an idea stinks, so be it. If the product sucks, oh well. Sometimes, cutting bait and moving on is the better approach. Continuing to sit out in the sun at the same tired old fishing hole may not result in the catching of fish, but may just result in a sunburn.

Rule of Least Surprise

This is also widely known as the Principle of Least Astonishment. The easiest programs to use are those that demand the least new learning from the user — or, to put it another way, the easiest programs to use are those that most effectively connect to the user's pre-existing knowledge.

Therefore, avoid gratuitous novelty and excessive cleverness in interface design. If you're writing a calculator program, "+" should always mean addition! When designing an interface, model it on the interfaces of functionally similar or analogous programs with which your users are likely to be familiar. Pay attention to your expected audience. They may be end users, they may be other programmers, or they may be system administrators. What is least surprising can differ among these groups.

In the startup context, I think this tenet applies 100%. Pay attention to your audience, and solve their pain. And when you do solve it, don't do it in an overly nebulous way. KISS, again.

Rule of Repair

Software should be transparent in the way that it fails, as well as in normal operation. It's best when software can cope with unexpected conditions by adapting to them, but the worst kinds of bugs are those in which the repair doesn't succeed and the problem quietly causes corruption that doesn't show up until much later. Therefore, write your software to cope with incorrect inputs and its own execution errors as gracefully as possible. But when it cannot, make it fail in a way that makes diagnosis of the problem as easy as possible.

When trying to change the world through your startup company, "failing noisily" is an imperative, not a nicety. When something doesn't work, the culture that you've fostered needs to be facilitative of recovery.

In the Army, we used a tool called the AAR, or the After Action Report. I'm not suggesting that you have a "form" that you fill out every time something goes wrong (although you could make an argument for a knowledge-base solution here). However, even an informal "pow-wow" will suffice. What went wrong? Why did it happen? How can we avoid this in the future? These are the things that everyone needs to focus on when something goes awry.

Rule of Diversity

Even the best software tools tend to be limited by the imaginations of their designers. Nobody is smart enough to optimize for everything, nor to anticipate all the uses to which their software might be put. Designing rigid, closed software that won't talk to the rest of the world is an unhealthy form of arrogance. Therefore, the UNIX tradition includes a healthy mistrust of "one true way" approaches to software design or implementation. It embraces multiple languages, open extensible systems, and customization hooks everywhere.

This is a nice segue into ...

Rule of Extensability

If it is unwise to trust other people's claims for “one true way”, it's even more foolish to believe them about your own designs. Never assume you have the final answer. Therefore, leave room for your data formats and code to grow; otherwise, you will often find that you are locked into unwise early choices because you cannot change them while maintaining backward compatibility.

This is a chess game. By always keeping one eye focused on the next few moves, you will be in a much more advantageous position.

Look at what happened with Apple. Who would have dreamed that the iPod would single-handedly resurrect the company? When Apple realized the impending success they had on their hands, they shifted into high-gear. Of course, they could start climbing even higher on the growth curve if they opened up their API (Application Programming Interface) to third party developers, but that is another story. The iPod is clearly an extensible device.

Perhaps a better example might be the IBM MicroChannel Architecture (MCA). Back in the 1980s, IBM marketed their "PS/1" and "PS/2" desktop computers. Unlike the machines cranked out by other manufacturers (including IBM's original line of PCs), they did not deploy the more traditional "ISA" architecture. The end result was that the machines were incompatible with a host of hardware and software add-ons. As a result, well ... Gateway, Dell, HP, COMPAQ, the list goes on.

I should point out that all three books, Gancarz' The Unix Philosophy, Peter Salus' A Quarter Century of Unix, and Eric S. Raymond's The Art of UNIX Programming, remain three of my favorite reads. Am I sick or what?

As an added bonus, here is a link to an online version of Eric S. Raymond's fantastic opus, The Art of UNIX Programming:


Good luck!


1 Comment

  1. Pingback: Unix Simplicity

Leave a Comment

Your email address will not be published. Required fields are marked *