Developers Are Not Presidents

I (heart) open source.  Deeply.  There are at least a few dozen libraries that I couldn’t live without anymore.  Tons of indispensable products like MySQL, Apache, Tomcat are part of my standard toolkit.  But the community hubris that goes along with it…Fuggetabouddit.  A recent quote by Django guru Jacob Kaplan-Moss concerning the balance of complex projects, features, release schedules and project management (collectively referred to in the quote as “these issues”) got my hackles up (full read here if you like):

“Open source cleanly avoids these issues by letting technical voices have the last say.”

Really?  So developers are now the President AND Congress? We write AND approve the laws?

Unfortunately, I think Jacob has missed the forest for the trees in this case.  From a broader perspective, the larger software product ecosystem looks like this:

Customers <-> Marketing <-> Engineers

We have Customers who have a need.  Marketing determines their desires, figures out features they want and asks the Engineers to build the product for the Customer.  (Obligatory Office Space joke)  Customer gets something that is Useful.  Everyone is happy.800px-PC_Load_Letter

In Open Source things are a bit different–we leave out the middlemen because we’re building tools and frameworks mostly.  We change the Customers a bit because Joe Six Pack, Joe Biden or your Grandma sure-as-heck aren’t going to be putting Django on their machines anytime soon and we get:

Engineers <-> Engineers

Open source sure has something easier to deal with than the earlier picture.  And no WONDER the developers get the final veto…chances are, they’re CUSTOMERS.  It’s great the Django has the luxury of saying to their developers, “Well, we’re not going to add in the toolbar to the next release” because in reality, that’s not a major loss to their customers.  They’re smart enough to find it on their own.  They are used to cobbling together things to get their end product working.  They’re highly technical and like to tinker.  They’re innovators and early adopters in Geoffery Moore’s terms.  They understand PC Load Letter (NSFW) on their printers.  But they’re the easiest groups to deal with when you’re a technical person.  It’s the other groups that are hard–and they’re the ones that make up a real product.

There’s a distinct difference between a project and product.  Project managers (like Jacob on Django) are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project.  Product managers, on the other hand, are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle.  These two roles are often at odds with each other, but it’s clear that Django doesn’t need or have a product manager because Django doesn’t fit into the category of a mainstream product.  It won’t be sold or marketed like Photoshop or Excel.  You won’t have customers that nicely follow Moore’s technology adoption curve.

Feature set balancing for real products and serious projects requires more than just a bunch of architects sitting in an ivory tower with a REJECTED stamp and red ink pad.  There are revenue considerations to be made, customers that would buy your product because you now have feature X, and competitive analysis to determine market viability.  None of which has anything to do with the purity of the code base, what your UML diagrams look like or how clean you keep SVN.

Sorry Jacob.  That may work for Django but you might want to look at some broader, successfully released products before pounding your chest about the reason for your wild success on a project.

Adapt or Die Thinking You’re Right

From the late 1800s until the 1950s, railroads dominated the transportation landscape.  Want to go from LA to Chicago?  Chances were you did that by train.  It was the preferred choice of the traveler–cost effective, comfortable, and enjoyable.  In short, the railroads enjoyed a near monopoly on passenger movement for nearly 100 years.

When the automobile began to dominate the landscape, railroads simply ignored the threat.  “We are vastly superior, have a lock on many markets, and offer an experience you can’t touch!”  Unfortunately, the American consumer disagreed with them and railroads entered a period of decline.  Cars became the preferred mode of transportation, changing the way cities were built and how people spent their leisure time.  By 1966, railroads only carried 2% of all intercity passenger traffic.  And by 1970, only one major railroad carried passengers at all.  The railroads shrank, cut routes, and closed down wondering what happened.  This is now a classic example in business texts, MBA courses and lectures:  railroads failed to understand they were in the transportation business, not the passenger business.  They didn’t realize their core strengths causing certain death when their market shifted.

Back in the early 90s, my first job out of college was technical support at a GUI toolkit company.  This company’s claim to fame was a platform portable library(written in C, later adding a C++ framework) where you could build a user interface on say Windows and then move it to Motif, Mac, OS/2 or a litany of other unfamiliar and obscure platforms, recompile and BOOM, your app ran there too.  At the time, it was a novel concept and one folks were paying a mighty fine premium to obtain.  Licenses ran about $2000 a piece, plus annual maintenance for support.  Writing these kind of applications required a level of GUI expertise that wasn’t commonly available to many developers of the era which gave rise to a Consulting and Training Group that charged hefty rates for their highly sought-after services.  Life was good:  the company sold several million dollars of support, product and services each year.  ISVs writing C and C++ applications gobbled up the software as voraciously as their CFOs would approve the purchase orders, creating a very large and lucrative market during that time.  They were kings of the hill.

Fast forward about 3 years.  Java and HTML appear on the scene.  Younger developers in the company are checking these new technologies out and sending emails to the executives saying how cool Java is and how HTML is taking over the world.  The executives didn’t care.  “HTML?  Bah, that’s for children.  Java?  A toy language at best…all it can do is make Duke dance in an applet window.  Ignore them.  We have the Enterprise to worry about.”  They missed the point.  They were in the business of providing a platform-portable GUI development solution.  They forgot that technology doesn’t factor into their mission statement.  They were focused on getting new customers in their existing market.  They insisted everyone would use C++ forever because it sucked less than HTML and Java, instead of seeing how the market had changed.  Just like the railroads.

A few years later, the company shrank from the 100+ employees in 1994 to less than 5 by the Millennium.  Developers left in droves because Java was the hot new language and C++ developers were in demand.  Professional services was sold to another company because management wanted to “focus on product sales, not services”.  The product sales dried up slowly and only a few stubborn customers who couldn’t get off their C/C++ platforms paid the outrageous maintenance fees charged by the remaining shell company.  Java became the defacto language for the enterprise.  HTML is the lowest common denominator of every web framework today.

Seth Godin nailed this in a short post:  When you have a hammer, everything looks like a nail.  But making sure you have the right tool for the right market is about how quickly and easily you can switch hammers.  Not hitting the same nail again and again.

The lesson here is clear:  Understand your strengths because your market isn’t static.  When the market changes, be prepared to adapt to it with those strengths. Otherwise, you’ll die thinking your strategy was right.

Fail Fast, Learn Quickly

Welcome to Lessons of Failure.  If you were looking for another blog about Dot Com Bazillionaires running around in limos post-IPO, well, sorry.  Try Google for someone else.  That’s not me.

I’ve spent the better part of two decades now as a professional computer geek (even longer as a rank amateur) and if there’s one thing I know about by now, it’s failure.  Everything from small fuse-popping, whoops-don’t-put-120V-on-an-electrolytic-capacitor failure, to Holy Sh*t! Dad-is-gonna-KILL-us-when-he-finds-out-about-this failure.

My background as a consultant gives me a unique perspective in the software industry.  Sort of like a bystander during an auto accident.  Or walking into the back of a bar mitzvah in a hotel.  You’re there, but at the same time, you’re also divested of the outcome to a certain degree.  Oh sure, you want success because it also happens to improve your chance of renewal at contract expiration time.  But when the company suddenly transforms into a smoking crater, you’re still standing on the side covered in a bit of soot, unlike your coworkers that are now atomized.  And hopefully a bit wiser, assuming you paid attention before the bomb went off.

Everyone knows the famous quote by George Santayana:

“Those who do not learn from history are doomed to repeat it”

And that’s what this blog is about…learning from failure.  Personal failure (like divorces).  Industry failure (like the dot-com bust).  Company failure (like Enron).  Learn or repeat.  Easy to say.  Hard to practice.

Having failed to learn a few times and, ahem, received a chance to repeat the mistake, this blog will explore failure on all those levels and more.  Fail fast, fail often, but for heaven’s sake, at least learn something.