(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:


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.


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.


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.

Comments on “Repost: The NewCo Business Idea:
I know you as person, who writes insightful blog posts and (mostly) good comments on reddit. You have years of experience, so i was keen how your business plan would look like.

Sad part is the link is dead. :(

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

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

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

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?

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

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

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

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

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

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 /