raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Wednesday, July 28, 2004
  How To Write Software With Art, Independence and Spirit


Everybody is talented because everybody who is human has something to express
Are you working on a personal project right now? Are you working on something that will have an unmistakable stamp of you in it? If not, why not?

Are you holding back because you don't have that million-dollar idea that will change the world?

This is a subtle way of beating yourself down, of not giving yourself credit for the talents you already possess. You are talented, you have something that should be shared. It may not be a big hit. Of course, it may be a big hit no matter how zany it sounded when it started.

Dave Winer started a company to sell a scripting environment. He ended up with a company that helped launch the weblog revolution. This shouldn't have surprised him: he once wrote a Pascal-specific programming editor and ended up with MORE than he expected, inventing the outliner. And don't get me started talking about the guy who created a web site for selling Pez dispensers.

Wait a second, what about the millions of metric tons of books published with the advice to research, research, research before you start your business?

I have a longer answer about market research below. But the short version is that your estimate of the value of the market for your idea is in no way related to the talent you have to express that idea in software. So express yourself: write your software.
Teachers, critics, parents and know-it-alls, when they see you have written something, become at once long-nosed and finicking and go through it gingerly sniffing out the flaws. AHA! a misspelled word! as though Shakespeare could spell!
Absolute crap sells when it brings a new idea to the world. The quality of the idea is more important than the quality of the software. Don't horde your software, polishing it for years lest someone file a bug report or tell you that you can't code anything.

Worse is Better: release early, release often. Get it into the world and refine it with feedback. It's easier for critics to find flaws than to appreciate the enormity of the change you are proposing. When Apple released Macintosh, what did people say? How about "It sucks, it only has 128k." Only 128k? Well, of course they had to add more memory. Didn't the first PC come out with 64k? That isn't the point.

The point is that the most important thing is to ship your software. Start it. And then release it. You'll have many chances to polish it later. Look at Open Source: the number one thing people look for in freely available software is that it is maintained, that it received regular attention from its authors.

If you wait until your software is perfect, there will be nothing left to add, and it will sit on the shelf gathering dust like a precious gem that is too valuable to wear daily. Get it out early, don't worry about the criticisms, and let it surprise you.
A great musician once told me that one should never play a single note without hearing it, feeling that it is true, thinking it beautiful
Consider everything in your software. Make a list of requirements and features. So much to do! And it always feels like making your software better will take more time. What to do?

This one's easy. Go over your list of requirements. How many are there because they capture some essential truth in the software? And how many are there because there's some 'should' or 'ought to' that drove the decision?

For example, if you're writing a web application, does it really need to be .NET or J2EE? What's with the XML/XSLT layer? Do you really need XML/XSLT to implement skins? Or would XHTML+CSS get the job done faster and simpler? There's a whole debate on faster, lighter development. Let's skip over that. The point is, unless the core of your idea is about XML and XSLT, you don't need it.

You may choose it if it helps you express your fundamental idea more succinctly. But if it's a lot of extra work, what are you writing? Your software? Your business plan? Or your resume? Stick to the core ideas that are true, that are beautiful, that will make your software sing like a Stradivarius.
Men spend their lives adding and subtracting and dictating letters when secretly they long to write sonnets and play the violin and burst into tears at the sunset
Remember the question about market research? Why shouldn't you do market research before you write your software?

By all means research the market when you're ready to sell. And maybe at that moment you'll make some changes. But don't start with the research. Market research will kill any idea and furthermore, you'll get depressed thinking about how spectacularly useless your ideas might be.

Another reason to skip the market research is that anything worth doing creates its own market. Pretend it's 1979. Microcomputers have been around since 1977. What's the market for another micro to go head to head with Apple Computer? Good thing you didn't do your homework, because you're IBM and if you start now, in 1981 your new micro coupled with 40% of your entire worldwide marketing budget will revolutionalize the business.

Okay, it's 1982. What's the market for a mouse and bit-mapped graphics? Good thing you skipped the market research, because you're Apple Computer and in 1984 you will change the world with Macintosh. It's the third kick at the can: Xerox's customers have voted thumbs down on their Star workstation and your own customers have told you that "Lisa Technology" sucks.

Anyways, here's the real issue: market research is adding and subtracting and dictating letters. It's trying to fit in with the business world so that you can feel like you're part of the herd, one of the crowd, so that you don't stick too far out.

I'll give you a hard, hard truth to face: when you try to write a piece of software around market research, you're subtly trying to justify your own failure. You're making excuses in advance.

What happens when you research the market? Well, one possibility is that you don't write your software ("nobody wants to pay for it"). But you take solace in the fact that it wasn't your fault: it's the market. And if you tweak and pull and twist your ideas to fit the research, then you've got another excuse: it wasn't your fault the program failed, that wasn't your original idea, but the market research said you had to do things that way.

Forget the market research. Forget the analysts. Write what's in your heart, and let's find out.

This post was inspired by a chapter in Guy Kawasaki's book The Computer Curmudgeon. That chapter reprinted a magazine column he wrote that was inspired in turn by Brenda Ueland's book If You Want To Write. The quotations in bold are taken from Brenda's Book. If you'd like more inspiration, buy Guy's book The Macintosh Way, where he shares his feelings about beautiful software and beautiful companies.

If you like this, please try If You Want To Write Software, where I tried to express how I feel about writing software, using Brenda Ueland's quotes to introduce the ideas.

Labels:

 

Comments on “How To Write Software With Art, Independence and Spirit:
Are you working on a personal project right now? Are you working on something that will have an unmistakable stamp of you in it? If not, why not? Are you holding back because you don't have that million-dollar idea that will change the world?No, I'm holding back because any idea, piece of software, invention, or fruitcake recipe I create, on my own time or not, relevant to my employer's business or not, belongs to my employer. (And it wasn't a matter of negotiating the contract at the time of hiring - it was a matter of being presented with the contract in order to keep my job with my wife 8.5 months pregnant at the time. New corporate owners and all that.)

So far as I can tell, the cycle of debt and medical expenses are destined to lock me behind the corporate wall for the foreseeable future. I'm simply much too risk-adverse to strike out on my own with virtually no savings cushion and a family to support.

Of course, they do make it very nice and comfortable back here in we-own-you land; my work schedule is incredibly sane for the industry and my salary looks good on paper. I even get what is apparently for the American employment market a reasonable number of vacation days. Still, on days like today when the order comes down from on high that everyone will be migrated over to the corporate MS exchange server, I look out the window and wonder...
 
This post has been removed by a blog administrator.
 
Very inspirating, thanks!
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /