(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Sunday, July 08, 2007
Repost: The NewCo Business Idea
I wrote about abandoning my attempts to write a new kind of sofware project management application. Here is an excerpt from the Original Business Plan that I wrote in 2004 and very early 2005 (1.2MB PDF). Looking back on it, the fundamental premise was to encode expertise into the system in advance. I would later move to the idea of using collaborative filtering to make predictions about the outcome of software development projects.
Let me tell you a little story:
Threadalyzer
Some little time ago I was hired by Steve Rosenberg to build a product named Threadalyzer. A very bright product manager named Saeed Khan had thought up the name, and the feature list was compiled by the simple expedient of copying features from existing products.
Threadalyzer was part of a suite of products for analyzing the behaviour of running Java applications (along with Profiler, Memory Debugger, and Coverage). Although the suite was marketed as a collection of different products, in actuality Profiler, Memory Debugger, and Coverage all shared a lot of common code while Threadalyzer was built from the ground up with a different architecture.
The biggest difference was that the other three products collected information about a running Java application. The information was presented in a graph or table, and the programmer would use that information to figure out what was going on. For example, Profiler could tell you that your servlet spent 90% of its running time in methods belonging to the jdbc package.
Is that good? Bad? Only the programmer would know.
But Threadalyzer was, at its heart, an exercise in “Artificial Stupidity.” Threadalyzer collected data about the way threads interacted with each other, especially through synchronization and locks. But unlike its suite-mates, Threadalyzer then looked for specific patterns. And instead of dumping the data in your lap, Threadalyzer made a diagnosis.
For example, Threadalyzer maintained a waits-for graph where every thread is a node and arcs connected threads that were blocked by locks to threads that held those same locks. When a cycle appeared in the graph, Threadalyzer would announce that the program contained a deadlock.
(This is not rocket science, unless you want to do this in real time by combination of hooks into the rather primitive Java VM of the day and by injecting byte codes into classes on the fly.)
Threadalyzer displaying a deadlock
I had the privilege of hiring a very smart fellow whose Master’s Thesis in Distributed Computing was one of my reference papers for the design. He sifted through the possibilities and designed several other useful patterns. The smart fellow, a C++ wizard named John MacMillan, myself, and a promising Waterloo co-op named Jenny Lee then built Threadalyzer with a plug-in architecture.
Although (to my knowledge) the product was never “unbundled” in such a way that customers could install analyzers after the fact, we built it as an engine that hosted many arbitrary little pattern-matching applications.
NewCo
Shipping software on time was and is a very hard problem. Actually, there are two hard problems involved. The first is knowing how to plan and manage development. The second is convincing stake holders that your plan is optimal and that any interference on their part—be it feature creep, dictating overtime, advancing the ship date, whatever—will make things worse. Please don’t consider the second part as me just trying to make a funny to capture your interest. It is a very hard problem in the real world.
In my twenty years of business experience, Growing a Business is absolutely the best book on founding and running a business organically that I have ever read. And I read a lot of books. “Growing a Business” is not about scoring business coups or raising money. It is not about sales tactics or innovation. It is about growing a business step by step, customer by customer. It is about expanding at a sane rate and getting rich the old-fashioned way: one satisfied customer at a time.
Growing a Business is a must-read for anyone who wants to build a business rather than “do a deal.”
One of the things people like about project management applications and spreadsheets and just about anything that produces professional looking graphics for presentations and reports is that it makes your plan seem solid and unassailable.
If a stakeholder walks into your office and sees handwritten three by five cards, she may be tempted to haggle.
One of the things I learned right away is that project management software is useless for actually planning projects, and if your boss is wily enough to know that, she will still haggle with you: she will ask tough questions like, “How do you know that you will need that much time for QA? Won’t the programmers have written bug-free code?”, or perhaps “Since we are instituting a brand new change control process, and therefore there will be very few new requirements, can’t we cut the development time in Phase II in half?”
You can’t defend a GANTT chart if your interlocutor has ever shipped a real, live working piece of software. She knows that what the GANTT chart makes tangible and concrete—task dependencies and resource allocations—have almost nothing to do with the final ship date.
So I dreamed of a piece of software that would back up the kinds of things I actually say when planning a project or defending a plan, like Well, we can produce code that requires less QA, but we will need to allocate time for that unit testing framework and continuous integration sever you turned down.
Or, Okay, you’re saying we should cut the estimate for requirements churn by 75%. Okay, we can try that, but if we get the usual number of requirements changes in Phase II, we’ll know that the fault was with the estimate, not with the team.
Or, Overtime? No problem, but the numbers show that we get almost as much work done in seventy hours a week than we do in fifty, and so on.
Triangulation
Or if that’s too much of a stretch, let me ask you this question. The very first thing you learn about shipping software is the existence of the features–quality–time triangle (another variation on the same idea is the features, money, time triangle).
Okay, where is the triangle in a GANTT chart? How do you play what–if with the triangle?
Tools for managing projects ought to directly manipulate the ways we think about managing projects. I wanted such a tool.
The Hammer
When you’re holding a hammer, every problem looks like a nail. And having built Threadalyzer, my thought was, why can’t we have a project management application that has little analyzers that look at a plan and provide warnings of problems with the plan? And of course, we would ship analyzers that encapsulated project management expertise as patterns in advance.
It would be much, much later that I would realize the fundamental error in my thinking.
I wrote about abandoning my attempts to write a new kind of sofware project management application. Here is an excerpt from the Original Business Plan that I wrote in 2004 and very early 2005 (1.2MB PDF). Looking back on it, the fundamental premise was to encode expertise into the system in advance. I would later move to the idea of using collaborative filtering to make predictions about the outcome of software development projects.
Let me tell you a little story:
Threadalyzer
Some little time ago I was hired by Steve Rosenberg to build a product named Threadalyzer. A very bright product manager named Saeed Khan had thought up the name, and the feature list was compiled by the simple expedient of copying features from existing products.
Threadalyzer was part of a suite of products for analyzing the behaviour of running Java applications (along with Profiler, Memory Debugger, and Coverage). Although the suite was marketed as a collection of different products, in actuality Profiler, Memory Debugger, and Coverage all shared a lot of common code while Threadalyzer was built from the ground up with a different architecture.
The biggest difference was that the other three products collected information about a running Java application. The information was presented in a graph or table, and the programmer would use that information to figure out what was going on. For example, Profiler could tell you that your servlet spent 90% of its running time in methods belonging to the jdbc package.
Is that good? Bad? Only the programmer would know.
But Threadalyzer was, at its heart, an exercise in “Artificial Stupidity.” Threadalyzer collected data about the way threads interacted with each other, especially through synchronization and locks. But unlike its suite-mates, Threadalyzer then looked for specific patterns. And instead of dumping the data in your lap, Threadalyzer made a diagnosis.
For example, Threadalyzer maintained a waits-for graph where every thread is a node and arcs connected threads that were blocked by locks to threads that held those same locks. When a cycle appeared in the graph, Threadalyzer would announce that the program contained a deadlock.
(This is not rocket science, unless you want to do this in real time by combination of hooks into the rather primitive Java VM of the day and by injecting byte codes into classes on the fly.)
Threadalyzer displaying a deadlockAlthough (to my knowledge) the product was never “unbundled” in such a way that customers could install analyzers after the fact, we built it as an engine that hosted many arbitrary little pattern-matching applications.
NewCo
Shipping software on time was and is a very hard problem. Actually, there are two hard problems involved. The first is knowing how to plan and manage development. The second is convincing stake holders that your plan is optimal and that any interference on their part—be it feature creep, dictating overtime, advancing the ship date, whatever—will make things worse. Please don’t consider the second part as me just trying to make a funny to capture your interest. It is a very hard problem in the real world.
In my twenty years of business experience, Growing a Business
is absolutely the best book on founding and running a business organically that I have ever read. And I read a lot of books. “Growing a Business” is not about scoring business coups or raising money. It is not about sales tactics or innovation. It is about growing a business step by step, customer by customer. It is about expanding at a sane rate and getting rich the old-fashioned way: one satisfied customer at a time.Growing a Business
is a must-read for anyone who wants to build a business rather than “do a deal.”If a stakeholder walks into your office and sees handwritten three by five cards, she may be tempted to haggle.
One of the things I learned right away is that project management software is useless for actually planning projects, and if your boss is wily enough to know that, she will still haggle with you: she will ask tough questions like, “How do you know that you will need that much time for QA? Won’t the programmers have written bug-free code?”, or perhaps “Since we are instituting a brand new change control process, and therefore there will be very few new requirements, can’t we cut the development time in Phase II in half?”
You can’t defend a GANTT chart if your interlocutor has ever shipped a real, live working piece of software. She knows that what the GANTT chart makes tangible and concrete—task dependencies and resource allocations—have almost nothing to do with the final ship date.
So I dreamed of a piece of software that would back up the kinds of things I actually say when planning a project or defending a plan, like Well, we can produce code that requires less QA, but we will need to allocate time for that unit testing framework and continuous integration sever you turned down.
Or, Okay, you’re saying we should cut the estimate for requirements churn by 75%. Okay, we can try that, but if we get the usual number of requirements changes in Phase II, we’ll know that the fault was with the estimate, not with the team.
Or, Overtime? No problem, but the numbers show that we get almost as much work done in seventy hours a week than we do in fifty, and so on.
Triangulation
Or if that’s too much of a stretch, let me ask you this question. The very first thing you learn about shipping software is the existence of the features–quality–time triangle (another variation on the same idea is the features, money, time triangle).
Okay, where is the triangle in a GANTT chart? How do you play what–if with the triangle?
Tools for managing projects ought to directly manipulate the ways we think about managing projects. I wanted such a tool.
The Hammer
When you’re holding a hammer, every problem looks like a nail. And having built Threadalyzer, my thought was, why can’t we have a project management application that has little analyzers that look at a plan and provide warnings of problems with the plan? And of course, we would ship analyzers that encapsulated project management expertise as patterns in advance.
It would be much, much later that I would realize the fundamental error in my thinking.
