July 24, 2006

Complexifiers and Simplifiers

Scott Berkun says “There are two kinds of people: Simplifiers and Complexifiers

And of course, the Complexifiers in the comments go nuts.   I think that there are two kinds of people - the kind that can tolerate the “glossing over” of aspects of a problem space, and those who can’t

I’ve just analyzed my mental database, and as far as I can tell, every, and I mean every successful entrepreneur started out by solving a complex problem, by ignoring everything but the one or two key things that made the problem interesting.

  • Google:  We’ll focus on making a better searching algorithm.   They didn’t worry about content, or network effects or portals.
  • Microsoft: We’ll build a basic interpreter for the new 8086 chips.
  • Dell: We’ll make it so you can order computers from a catalog
  • Cisco: We’ll make a hardware equivalent to the software routing code inside BSD Unix
  • Hershey: We will make milk caramels
  • Ebay: We will make it so people can buy from each other
  • Oracle: We will create a relational database
  • Motorola: We will make radios for cars
  • McDonalds: Consistent food at a low price
  • Ford:  We will make a car that is cheap and reliable.

Every single one of those strategies was rife with complexity - what about supply chains? What about inspections? How will we manage quality?  How will we deal with hardware changes? How will we take orders?  How will we grow quickly?

But all of those, it turns out, were side issues - they correctly identified the core issues that people cared about, and ignored the rest.  They simplified, and by simplifying, they were successful.
Now, many startup businesses that attempt to simplify fail because they simplified the wrong things.   And I’m sure there are a few businesses that succeeded out with “we’re going to do x, y, z, w, a, b and c and dominate the market”.  But in my experience, it is very, very rare to win with the “we’re going to solve every aspect of a complex problem”.

In general, that seems to be the case regardless of the kind of project you’re working on - initiatives that attempt to simplify a complex problem succeed much more often than initiatives that attempt to manage a complex problem.  Most “managing” solutions that I’ve seen end up living a perpetual undeath of partial use, unable to actually succeed at anything.

C# vs Python

Darmesh discusses his programming history, and finally ends up with the eternal question: “Python or C#”?

To me, the ultimate reason not to use Python is contained in this following interaction:

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
>>> exit
‘Use Ctrl-Z plus Return to exit.’
>>> quit
‘Use Ctrl-Z plus Return to exit.’
>>> ^D
File “”, line 1

^
SyntaxError: invalid syntax
>>> ^Z

C:\Documents and Settings\jb>

Yes, you read that right. Python *knows* what you want to do, and doesn’t do it. Instead, it tells you how to do it the right way.

I have to use Python because it has some nifty hooks into the R statistical programming language. But I won’t use it for anything else. If I need scripting, I’ll use Ruby, thank you very much. Because here’s what happens when I interact with the interactive ruby shell:

C:\Documents and Settings\jb>irb
irb(main):001:0> quit

C:\Documents and Settings\jb>irb
irb(main):001:0> exit

C:\Documents and Settings\jb>irb
irb(main):001:0> ^D

C:\Documents and Settings\jb>

The only mechanism it doesn’t support, ironically, is ^Z + Enter

Yeah, I know they’re not apples-to-apples comparisons. And I’m sure there are people out there who love Python for its strict purity of behavior. But I am not one of them :)