Wednesday, October 26, 2005
I'm not young enough to know everything
Paul Graham has alluded to the difficulty of doing a startup when you're, well, not young. He puts the upper bound at thirty-eight:
Let's start with a digression. What makes weblog posts popular? Most people say things like "insightful" posts become popular. Or "well-written" posts become popular. Adjectives like that are tautological: if someone likes a piece of writing, they generally will find nice adjectives to apply to it.
One model for popular writing is that it panders to the reader's prejudices. Plain and simple. People like writing that validates them and especially their ideas. I'm no different, and as a result I tend to focus my research on things that I already think I know.
When you're twenty-two this isn't much of a problem because you know you don't know. You're "consciously incompetent." So you're far more likely to find something unfamiliar and try to understand it, to change your way of thinking to match what you learn rather than applying a "bozo filter" to it in advance.
But at forty-two (or three!), it's easy to think you know things. You're at incredible risk of thinking you know things when you've achieved some measure of success, no matter how modest. You become "unconsciously incompetent." You don't know, but you don't know you don't know.
I was personally reminded of this at startup school. As Chris Sacca pointed out:
I immediately made a commitment to myself to let go of things I used to think I knew.
Matz, Jonathan Ives, and A Narrow Road to a Far Province
One commitment was to try Ruby on Rails instead of Lisp. Every time I've looked at Ruby, I've thought "nice, but it doesn't do anything I couldn't do in SmallTalk back in 1980."
I've been the most pompous hypocrite. I mean, I often poke my Windows apologist friends and tell them that efficiency and user interface is not measured with check boxes ("mouse? check. icons? check. well, they must do the same thing.") I've extolled the virtues of design, of the interaction between the parts, of the frictionless user experience of a Macintosh.
As for the Rails thing, it's awfully popular and I have been uneasy about anything so hype-ridden. But how is that different from any of a thousand funny quotes deriding the new new thing? I'm tempted to say that there's a world market for maybe five Rails applications. But maybe there's more to it.
Maybe I should find out.
Thomas Bayes, Joel Spolsky, and Richard Feynman
Joel Spolsky dropped an incredibly provocative anecdote into one of his well-written and insightful posts:
I've known about Bayesian classification for years. And I've always thought of it as a specialized tool. It's incredibly disruptive to think of it as an every-day tool, as a general-purpose tool, as something that can replace the if statement.
There was an "aha!" moment for me when I suddenly grokked polymorphism. When I understood that switch statements were junk. Maybe Bayesian inferences can change programming the same way that polymorphism changed programming.
I need to find out.
And now I'd like to quote the other Steve, the one who isn't a hacker and wasn't presenting at startup school (Psst! Steve! Do you want to sell coloured MP3 players for the rest of your life or do you want to change the world again?)
One more thing
For a very long time I've been carrying a conjecture around. Paul Graham supplied me with the framework for thinking about the conjecture:
The "Graham Question" is: Can we predict the future of a software development project with objective observation?
Let's take a simple example, one that ran through my head this morning. I've worked for several companies that used issue tracking systems. These systems have had a little widget/enumeration for declaring the priority of an issue. I've also worked with Scrum-like teams that maintained priority with a master list or backlog.
You want to know which issues will be fixed/implemented/done by a certain date. What is the significance of the priority?
Well, this is management 101. Start with the number of hours available for development, then take the highest priority issues and estimate how much time is required to do them. Your prediction is that the team will do as many as possible of the highest priority items in the time available.
All well and good, but in reality "Spolsky" isn't in the dictionary and neither is "Braithwaite." For that matter, neither is "p.s.", and why should I have to click "add to dictionary" after the program has watched me type this thing and not correct it hundreds of times?
And lo, if we watch an actual software project we see that over time priorities change and new issues are added to the mix and sometimes low priority items are done first for some reason, and humans just can't seem to follow the damn plan, but software emerges from the other end anyways.
It's easy to say, "your old-fashioned priority is no damn good." But maybe we are not young enough to know everything. Maybe we should ask a question: "what good is the priority if you can't construct a nice if statement around it?"
Maybe this is like Spolsky and Braithwaite and Error IDs and Help Text. Maybe there is no formula up front but we can watch what people do hundreds of times.
Maybe Thomas Bayes knows the significance of the priority.
So who should start a startup? Someone who is a good hacker, between about 23 and 38... I don't think many people have the physical stamina much past that age. I used to work till 2:00 or 3:00 AM every night, seven days a week. I don't know if I could do that now. Also, startups are a big risk financially. If you try something that blows up and leaves you broke at 26, big deal; a lot of 26 year olds are broke. By 38 you can't take so many risks-- especially if you have kids.While what he says is true, lately I've become aware of an even bigger threat to starting a startup. Experience can be a handicap.Paul Graham, How to Start a Startup
Let's start with a digression. What makes weblog posts popular? Most people say things like "insightful" posts become popular. Or "well-written" posts become popular. Adjectives like that are tautological: if someone likes a piece of writing, they generally will find nice adjectives to apply to it.
One model for popular writing is that it panders to the reader's prejudices. Plain and simple. People like writing that validates them and especially their ideas. I'm no different, and as a result I tend to focus my research on things that I already think I know.
When you're twenty-two this isn't much of a problem because you know you don't know. You're "consciously incompetent." So you're far more likely to find something unfamiliar and try to understand it, to change your way of thinking to match what you learn rather than applying a "bozo filter" to it in advance.
But at forty-two (or three!), it's easy to think you know things. You're at incredible risk of thinking you know things when you've achieved some measure of success, no matter how modest. You become "unconsciously incompetent." You don't know, but you don't know you don't know.
I was personally reminded of this at startup school. As Chris Sacca pointed out:
The glow of screens (from a refreshingly Powerbook-dominated audience) revealed an array of real-time collaborative note-taking for a virtually assembling the room's minds in a concurrent recording and discussion of the event.Sitting in that room, I was hyper-aware that I was no longer in Kansas. It struck me that if I didn't want the next generation of hackers to wipe me out like a Tsunami, I needed to stop paddling, climb on my surfboard, and accept the risk of being dashed on the rocks.Chris Sacca, Startup School - An Inspiring Room Full of Hackers
I immediately made a commitment to myself to let go of things I used to think I knew.
Matz, Jonathan Ives, and A Narrow Road to a Far Province
One commitment was to try Ruby on Rails instead of Lisp. Every time I've looked at Ruby, I've thought "nice, but it doesn't do anything I couldn't do in SmallTalk back in 1980."
I've been the most pompous hypocrite. I mean, I often poke my Windows apologist friends and tell them that efficiency and user interface is not measured with check boxes ("mouse? check. icons? check. well, they must do the same thing.") I've extolled the virtues of design, of the interaction between the parts, of the frictionless user experience of a Macintosh.
Do not seek to follow in the footsteps of the wise. Seek what they sought.Ok, Ruby's blocks and classes and closures are the same things that Lisp has given us since 1959 and SmallTalk has given us since 1980. But maybe... Maybe... Maybe Ruby on Rails is easier to use than Lisp in the very same sense that OS X is easier to use than Windows.
Matsuo Basho
As for the Rails thing, it's awfully popular and I have been uneasy about anything so hype-ridden. But how is that different from any of a thousand funny quotes deriding the new new thing? I'm tempted to say that there's a world market for maybe five Rails applications. But maybe there's more to it.
Maybe I should find out.
Thomas Bayes, Joel Spolsky, and Richard Feynman
Joel Spolsky dropped an incredibly provocative anecdote into one of his well-written and insightful posts:
A very senior Microsoft developer who moved to Google told me that Google works and thinks at a higher level of abstraction than Microsoft. "Google uses Bayesian filtering the way Microsoft uses the if statement," he said. That's true. Google also uses full-text-search-of-the-entire-Internet the way Microsoft uses little tables that list what error IDs correspond to which help text. Look at how Google does spell checking: it's not based on dictionaries; it's based on word usage statistics of the entire Internet, which is why Google knows how to correct my name, misspelled, and Microsoft Word doesn't.I have an entire career built on top of experience building applications that manage ontologies, that are built out of objects and classes and tables and relations and all sorts of things that boil down to if statements. Or at least, they boil down to classifying things in advance rather than building systems that learn over time.
If Microsoft doesn't shed this habit of "thinking in if statements" they're only going to fall further behind.
I've known about Bayesian classification for years. And I've always thought of it as a specialized tool. It's incredibly disruptive to think of it as an every-day tool, as a general-purpose tool, as something that can replace the if statement.
"Your old-fashioned ideas are no damn good!"Yet when I step out of my comfort zone, I realize that I've seen this before (experience can be handy at times). Many of you young-uns have never known a programming world where there was no polymorphism (although judging by some of the code that has caused me to say "WTF?", not as many as I would like). Before messages, virtual functions, and method calls there were the switches, cases, and if statements.Richard Feynman
There was an "aha!" moment for me when I suddenly grokked polymorphism. When I understood that switch statements were junk. Maybe Bayesian inferences can change programming the same way that polymorphism changed programming.
I need to find out.
And now I'd like to quote the other Steve, the one who isn't a hacker and wasn't presenting at startup school (Psst! Steve! Do you want to sell coloured MP3 players for the rest of your life or do you want to change the world again?)
One more thing
For a very long time I've been carrying a conjecture around. Paul Graham supplied me with the framework for thinking about the conjecture:
Treating a startup idea as a question changes what you're looking for. If an idea is a blueprint, it has to be right. But if it's a question, it can be wrong, so long as it's wrong in a way that leads to more ideas.Paul Graham, Ideas for Startups
Let's take a simple example, one that ran through my head this morning. I've worked for several companies that used issue tracking systems. These systems have had a little widget/enumeration for declaring the priority of an issue. I've also worked with Scrum-like teams that maintained priority with a master list or backlog.
You want to know which issues will be fixed/implemented/done by a certain date. What is the significance of the priority?
Well, this is management 101. Start with the number of hours available for development, then take the highest priority issues and estimate how much time is required to do them. Your prediction is that the team will do as many as possible of the highest priority items in the time available.
All well and good, but in reality "Spolsky" isn't in the dictionary and neither is "Braithwaite." For that matter, neither is "p.s.", and why should I have to click "add to dictionary" after the program has watched me type this thing and not correct it hundreds of times?
And lo, if we watch an actual software project we see that over time priorities change and new issues are added to the mix and sometimes low priority items are done first for some reason, and humans just can't seem to follow the damn plan, but software emerges from the other end anyways.
It's easy to say, "your old-fashioned priority is no damn good." But maybe we are not young enough to know everything. Maybe we should ask a question: "what good is the priority if you can't construct a nice if statement around it?"
Maybe this is like Spolsky and Braithwaite and Error IDs and Help Text. Maybe there is no formula up front but we can watch what people do hundreds of times.
Maybe Thomas Bayes knows the significance of the priority.
Tuesday, October 18, 2005
Seven Words You Can't Say To A VC
...backed company.
Okay, now that we've got an obscure pun out of the way, David Beisel of Masthead Venture Partners in Cambridge wrote a terrific list of
Seven Questions Employees Should Ask Before Joining a Startup.
Judging by the traffic I get from Google queries, my post Are you thinking of working for a start up? is one of the most popular things I've written. The two posts make for an interesting contrast.
My first take on David's post is that these are some of the questions I've asked when thinking about joining early stage companies. And truth be told, I've found prospective employers are not eager to be transparent. But you ought to know the answers to these questions.
In another blog post, David discussed the importance of being authentic. I'd have to say this is probably the number one thing I've looked for. And when a company starts to nose dive, it's the first thing the company loses. I think the question about replacing the CEO really hits that, especially if the former CEO was a founder and the new CEO is a "professional manager."
Does anyone remember when Billg was the alpha-geek at Microsoft? That was when the company rocked and rolled. Or what's going on at Apple? Wouldn't you say that Jobs may have his faults, but he's authentic down to the ground? How about Google? Notice how the founders are still in control and driving the company to their vision?
Good luck out there. And remember, if you're smarter than the average bear, you may want to seek funding instead of employment.
Okay, now that we've got an obscure pun out of the way, David Beisel of Masthead Venture Partners in Cambridge wrote a terrific list of
Seven Questions Employees Should Ask Before Joining a Startup.
Judging by the traffic I get from Google queries, my post Are you thinking of working for a start up? is one of the most popular things I've written. The two posts make for an interesting contrast.
My first take on David's post is that these are some of the questions I've asked when thinking about joining early stage companies. And truth be told, I've found prospective employers are not eager to be transparent. But you ought to know the answers to these questions.
In another blog post, David discussed the importance of being authentic. I'd have to say this is probably the number one thing I've looked for. And when a company starts to nose dive, it's the first thing the company loses. I think the question about replacing the CEO really hits that, especially if the former CEO was a founder and the new CEO is a "professional manager."
Does anyone remember when Billg was the alpha-geek at Microsoft? That was when the company rocked and rolled. Or what's going on at Apple? Wouldn't you say that Jobs may have his faults, but he's authentic down to the ground? How about Google? Notice how the founders are still in control and driving the company to their vision?
Good luck out there. And remember, if you're smarter than the average bear, you may want to seek funding instead of employment.
Tuesday, October 11, 2005
Fully Engaged by Example
First, a personal note. I'm feeling fully engaged. You know that feeling, when it seems like what you're working on occupies 100% of your attention, when you have to fight to think about anything else.
This weekend I went climbing in Kentucky. On Saturday night I was at a rocking party with some of my most attractive friends dancing up a storm. I was in a corner, writing down thoughts about how my project would help people communicate about software functionality using examples. And I love to dance!
Sometimes a dance is just a dance, but an idea is a dream coming to life. I didn't want to miss the moment. Do you ever feel like the entire Universe is conspiring to move you forward? It isn't really, but it feels that way because you're so positively attuned to your idea that you can find help from even random outside events.
And after a weekend working on examples, what do you suppose I spied on a church billboard driving home?
Okay, now about examples. Here's the pain point in development. How do we communicate about what we're going to build and why over the life of a project, not just in version 1.0?
Jonathan Edwards does a terrific job of explaining the problem:
Jonathan is trying hard to build mechanical ways of getting teams to work together. Have a look at his ideas: he's an original thinker. I'm interested in a slightly different take on the same problem. As he puts it, "They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood."
This weekend I went climbing in Kentucky. On Saturday night I was at a rocking party with some of my most attractive friends dancing up a storm. I was in a corner, writing down thoughts about how my project would help people communicate about software functionality using examples. And I love to dance!
Sometimes a dance is just a dance, but an idea is a dream coming to life. I didn't want to miss the moment. Do you ever feel like the entire Universe is conspiring to move you forward? It isn't really, but it feels that way because you're so positively attuned to your idea that you can find help from even random outside events.
And after a weekend working on examples, what do you suppose I spied on a church billboard driving home?
Okay, now about examples. Here's the pain point in development. How do we communicate about what we're going to build and why over the life of a project, not just in version 1.0?
Jonathan Edwards does a terrific job of explaining the problem:
Programmers in the real world will tell you that specs aren’t worth the paper they are written on. They are half-baked informal descriptions that are too abstract to be understood by the users, and too imprecise to be useful to the programmers. They are full of internal inconsistencies and factual errors, because there is no way to test them. They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood. Things are no better with the other standard commodities of development: project plans, schedules, cost estimates, and documentation.Jonathan Edwards, The Currency of Development
Jonathan is trying hard to build mechanical ways of getting teams to work together. Have a look at his ideas: he's an original thinker. I'm interested in a slightly different take on the same problem. As he puts it, "They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood."
How do we make it easy to rewrite functional specifications? Some cultures try to solve the problem with command-and-control ("thou shalt not make a code change without an accompanying tech spec").
What I've observed is that all the information we want is out there in emails, PowerPoint decks, screen shots, and documents. And that's just the stuff produced by customers/analysts/product managers. What about the comments in the source code and the source code control system that describe how the changes close a specific bug or implementa specific feature?
Everything's fragmented and gets more and more unwieldy as projects move forward.
Using examples as the central communication idea is just part of the solution. We need to make it easy to write examples and read them. We need to track the history of changes. And we need to tie the examples closely to tasks and releases.Labels: passion
Friday, October 07, 2005
Just do it
Eric Sink has some terrific advice:
But really, this principle is so simple we should look for it in far more places. Isn't this the foundation of iterative development? Can you make a wireframe or mockup or prototype faster than you can draw a pretty UML diagram?
What about selling agile practices? Which ones can you just do? Wouldn't it be easy to say "we've been trying X for four weeks and we've achieved Y and Z"? Isn't it far better to risk asking forgiveness than campaign for permision?
Why not just try pair programming? What's stopping you from just doing test-driven development on your own personal tasks? Is there any reason you can't use Cruise Control on your workstation even if the team doesn't buy into continuous integration? What's wrong with writing all of your tests in FITnesse and sharing the results?
I'll make you a deal. I'll stop wasting time writing this blog entry now if you will go ahead and think of one thing you could just go ahead and do.
You've got your idea? Ok, here's my 'end' of the bargain.
You could spend a lot of time trying to figure out if this idea is any good, and at the end, you wouldn't really know. Alternatively, you could spend the same amount of time implementing this idea, after which you will have the opportunity to really find out if it's any good.I could link this over to my own struggle to get my idea out of the garage and (at the very least) sitting in the driveway where my neighbors can think up polite ways to ask "WTF?"
But really, this principle is so simple we should look for it in far more places. Isn't this the foundation of iterative development? Can you make a wireframe or mockup or prototype faster than you can draw a pretty UML diagram?
What about selling agile practices? Which ones can you just do? Wouldn't it be easy to say "we've been trying X for four weeks and we've achieved Y and Z"? Isn't it far better to risk asking forgiveness than campaign for permision?
Why not just try pair programming? What's stopping you from just doing test-driven development on your own personal tasks? Is there any reason you can't use Cruise Control on your workstation even if the team doesn't buy into continuous integration? What's wrong with writing all of your tests in FITnesse and sharing the results?
I'll make you a deal. I'll stop wasting time writing this blog entry now if you will go ahead and think of one thing you could just go ahead and do.
You've got your idea? Ok, here's my 'end' of the bargain.
Labels: passion
Thursday, October 06, 2005
The classic question: end-to-end or point solution?
This has got to be the most basic design question, ever. It's so universal, it applies to everything. Specialist or generalist? Full-service department store or specialty boutique? Integrated application or specialist tool?
I wouldn't count on it. If that was the case, why don't AOL and Microsoft own the Internet? It's not for a lack of trying or paucity of resources. Google seems to be trying to do it by becoming Yahoo. Strange that they aren't dancing with the date they brought to the ball... their success began with laser-like specialist focus.
All in all, I suggest making the very best software you can. That almost always means making a narrower tool that is more focused.
That doesn't mean making a web service that can't do anything until someone mashes it up with another tool. You'll notice that point solutions are still solutions. You still have to solve one problem and solve it well.
Fred does a good job of contrasting the approaches in the web services and web application business. Are point solutions strictly for early adopters and end-to-end solutions (like Yahoo! and AOL) for the mainstream?The fact is that these "point solutions" have a vitality that comes from their authenticity, their simplicity, and their sizable and active user bases.
I heard a user of one of these services talk a couple weeks ago about the "emotional connection" he had to one of these services.
I know what he is talking about. I feel that way about Flickr, Typepad, Google, My Yahoo!, delicious, and many other web services I use on a daily basis.
I have rolled my own web experience and it is unique to me. It is mine.
Fred Wilson, "Point Solutions vs End to End Solutions"
I wouldn't count on it. If that was the case, why don't AOL and Microsoft own the Internet? It's not for a lack of trying or paucity of resources. Google seems to be trying to do it by becoming Yahoo. Strange that they aren't dancing with the date they brought to the ball... their success began with laser-like specialist focus.
All in all, I suggest making the very best software you can. That almost always means making a narrower tool that is more focused.
That doesn't mean making a web service that can't do anything until someone mashes it up with another tool. You'll notice that point solutions are still solutions. You still have to solve one problem and solve it well.
Wednesday, October 05, 2005
Business basics
Okay this post sounds suspiciously like something I ought to write backwards on a post-it note, stick it on my forehead, and read it every time I look in the mirror. It's advice for people starting a business.
But really, it's advice for evaluating a business idea. And if you're thinking about joining a startup, before you evaluate the equity compensation, you ought to decide for yourself if they're onto a good thing.
Here's Don Dodge with a few basic hints:
But really, it's advice for evaluating a business idea. And if you're thinking about joining a startup, before you evaluate the equity compensation, you ought to decide for yourself if they're onto a good thing.
Here's Don Dodge with a few basic hints:
Never get too far ahead of the market. Creating new markets, new business models, and value propositions is very difficult and takes lots of time and money. Pioneers are usually unsuccessful, the fast followers make most of the money.
Understand who your customer is, what problem you solve, and how much they are willing to pay for it. Sounds simple enough but you would be surprised how many start-ups get excited about their technology innovations and forget about the basic business proposition.
Never start a business focused on solving a big company’s problem. They don’t know they have a problem…and they are probably right. That is how they got to be so big in the first place. The record labels didn’t know they had a digital distribution problem and were not interested in our solution to it.
Test your assumptions before spending lots of money. Interview your potential customers. Understand what their top 10 problems are. Don’t try to convince them that you have a solution to a problem they don’t know they have. Take a survey of 100 potential customers. Ask them to list their top 10 problems, without prompting from you. If you don’t see your problem area listed…move on to another problem.—Don Dodge, "Napster - the inside story and lessons for entrepreneurs"
Tuesday, October 04, 2005
Striking up a conversation about my business idea
A personal note:
This post is quite off topic from the theme (if there is a theme) of this weblog. I try to share my experience (good and bad). By experience, I mean things I believe to be the case thanks to having experienced them from concept to action right through to consequences.
Now I'm sharing some of my thoughts as I fashion a concept into a piece of software art. As I haven't suffered the consequences, I have no experience to impart.
All I can say in defense of these posts is:
"Our show may not be fancy, but it's noisy and it's free!"
...
From "Signs of Art":
One decision is to sell from the bottom up (for more about that, here's my rueful explanation). That drives an approach to the product. For example: the product has to provide value to even a single user on a team; it has to integrate with existing tools; and it cannot require a server installation.
The fallout from the bottom-up decision (actually it was a reversal of another decision) has been heavy. Most of the big wins I conjectured for a software development team have been "boil the pond" stories: they only work if the entire team adopts a practice.
When you think of one user at a time, you have to think a lot smaller in some ways. Two things that stand out are helping people organize their own work and communicate clearly. Thus the wiki.
Decisions are at least as much about what a project isn't than what it is. I have a jillion ideas about how wonderful things will be when a critical mass of users on a single project adopt the product. Nevertheless, it isn't about making teams effective, it's about making individuals effective.
I also have strong opinions about the benefits of integrating release management with continuous integration, source code control and automated acceptance testing. Nevertheless, it isn't a build and/or release tool.
I think I have some idea what kind of development software managers want to buy. There's always a workflow component. Nevertheless, it isn't about setting up a process and constraining users' behaviour.
I'll be circulating more detail soon, including the second value proposition. Please feel free to comment publicly or privately: I welcome all feedback.
This post is quite off topic from the theme (if there is a theme) of this weblog. I try to share my experience (good and bad). By experience, I mean things I believe to be the case thanks to having experienced them from concept to action right through to consequences.
Now I'm sharing some of my thoughts as I fashion a concept into a piece of software art. As I haven't suffered the consequences, I have no experience to impart.
All I can say in defense of these posts is:
"Our show may not be fancy, but it's noisy and it's free!"
...
From "Signs of Art":
Art is "the documentation of a thousand interesting decisions". [emphasis mine]
Let's take that apart word by word:
"The documentation..." In order to qualify as art, you've got to be able to share it with others. This means capturing it on some canvas whether it's paper, a DVD, a web page, a city, or your skin. If you can't share your art, it's not art. It's a conversation with yourself and I'm sure you're fascinating, but why not share it with the rest of us?
"... a thousand..." A thousand is a swag. It describes that there needs to be some perception of effort for a work to be art... I'm not suggesting that an outside observer needs to look at art and say, "Gee, that looks hard to do. I couldn't do that." The observer needs to experience something in the piece whether it's the size, weight, or complexity of the work and can't be created with a single trivial decision.
"...interesting decisions..." Now, here's the heart. Art is when someone captures a set of decisions worth remembering. Blue or red? Serif or sans serif? Ruby or Python? ... It's a personal thing. Some decisions will inspire, some will bore and the sum of all the decisions will affect each person differently.
Software is art.
—Michael "Rands" Lopp
Well, I've been having "a conversation with myself" for two years and it's time to share. I'm pretty confident I've made quite a few decisions. Are they interesting? You be the judge. Some of them are fashionable right now (delivering an AJAX application on a subscription basis), some not (development tools).
I'm going to kvetch about the so-called "intellectual property" laws: they make it hard to have a meaningful dialogue with the world. That's because they're really about keeping secrets, not possession of property.I'm not worried about my ideas being "stolen." For starters, if anything I'm considering is so obvious that someone reads it and yells "that's it, let's do it, yeah!" based on my description, then I'm pretty sure there are already a dozen people already doing it and we're only talking about adding one more competitor.
"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
—Howard Aiken
So here goes, I'm going to start talking about the business model. I think it's pretty safe to say that I will not ever apply for a business method patent.
Where's the beef?
Let's start with the business idea. There are two value propositions. The first value proposition is "the beef." It's how we will attract users and grow. We help individual members of a software development team build software. The first value proposition is all about the team members: the product managers, the team leaders, the testers, and the programmers.
Our product is a wiki. It's a web site that describes the state of their software development project. The value proposition to team members is that the wiki helps our users organize their work and communicate with their team mates.
- There is special support for the semantics of software development. There is an ontology that includes entities like code, builds, releases, acceptance tests, defects, and, of course, deadlines.
- There is special support for tracking and inspecting the history of projects.
- There is integration with existing tools like issue tracking software and source code control.
One decision is to sell from the bottom up (for more about that, here's my rueful explanation). That drives an approach to the product. For example: the product has to provide value to even a single user on a team; it has to integrate with existing tools; and it cannot require a server installation.
The fallout from the bottom-up decision (actually it was a reversal of another decision) has been heavy. Most of the big wins I conjectured for a software development team have been "boil the pond" stories: they only work if the entire team adopts a practice.
When you think of one user at a time, you have to think a lot smaller in some ways. Two things that stand out are helping people organize their own work and communicate clearly. Thus the wiki.
Decisions are at least as much about what a project isn't than what it is. I have a jillion ideas about how wonderful things will be when a critical mass of users on a single project adopt the product. Nevertheless, it isn't about making teams effective, it's about making individuals effective.
I also have strong opinions about the benefits of integrating release management with continuous integration, source code control and automated acceptance testing. Nevertheless, it isn't a build and/or release tool.
I think I have some idea what kind of development software managers want to buy. There's always a workflow component. Nevertheless, it isn't about setting up a process and constraining users' behaviour.
I'll be circulating more detail soon, including the second value proposition. Please feel free to comment publicly or privately: I welcome all feedback.
Thank you Dave!
I'm working hard on opening up a dialogue around my "garage" project. More about that in another post. But today I found myself hunting for an URL to include in my spec.
Here's the URL:
http://davenet.scripting.com/1999/05/24/editThisPage
Back on Monday, May 24th, 1999, Dave Winer described something that provoked me in a deep way.
This post doesn't seem to have been the first to articulate the idea that people could use a web browser to edit a web site: Ward Cunningham's Portland Pattern Repository seems to have been around since 1995. But I hadn't heard of it and I did read Dave's post.
Thanks!
Here's the URL:
http://davenet.scripting.com/1999/05/24/editThisPage
Back on Monday, May 24th, 1999, Dave Winer described something that provoked me in a deep way.
This post doesn't seem to have been the first to articulate the idea that people could use a web browser to edit a web site: Ward Cunningham's Portland Pattern Repository seems to have been around since 1995. But I hadn't heard of it and I did read Dave's post.
Thanks!
