Process for the Enterprise » Chris Dixon

Chris Dixon asks: Who Should Learn How to Code?

Scott Francis — Thu, 02 Feb 2012 05:32:27 +0000

What a great blog post from Chris Dixon, “Who should learn how to program?” :

Businesses all over the world need more programmers. Every company I know is hiring engineers (e.g. see this list of NY tech startups). Top programmers can make $100K+ right out of college. Yet there were only about 14,000 computer science (CS) majors last year. Meanwhile about 40,000 people got law degrees even though demand for lawyers has been shrinking. America is suffering from what economists call structural unemployment: jobs are available but our labor force isn’t trained for those jobs.

Plentiful job opportunity is just one great reason for people to learn how to code (program). Unfortunately, after the dot-com bust, the news media and many cynical people convinced many college students that software jobs were going overseas and never coming back. It was a classic market-driven overreaction to a correction. In places where students have good data about market dynamics (e.g. Stanford) the number of computer science majors are up double-digit percentages each of the last 3-4 years. Additionally, there’s been a big increase in software-related fields, not typically classified as Computer Science (like Symbolic Systems, electrical engineering, and certain types of engineering and product design).

Chris also points out that programming is a great foundation for starting a tech company. Hard to argue with that. If your goal is to start a company, knowing how to code will give you a much better chance of achieving that dream than just about any other skill. Taking BP3 as an example- a services company that you might not think requires programming skills to start: I have a computer science background, and Lance knows how to write code, though it isn’t part of his job description(!). Knowing how to code and being able to do it were what allowed us to start BP3. And those skills translate well to nearby fields like statistics, that require structured or algorithmic thinking.

Programming is good for your brain – to misquote (slightly) Steve Jobs, it is like a bicycle for the mind. You’ll be amazed at how well you can remember not only where specific lines of code are in your work, but by how long you can retain this knowledge, often even years later being able to trivially skim through your code to the right spot to fix a defect.

An even better point Chris brings up is this one:

Programming is an important part of being “culturally literate.”

It is hard to underestimate this today. I’m raising two children. We’re exposing them to an immersion school that teaches them to speak fluent Spanish (as well as their native English). But the school (and through some help from outside of school) we’re also teaching them Mandarin (and a little Cantonese). If our children graduate from college fluent in English, Spanish, and Chinese – they’ll be able to do business almost anywhere in the world and converse with people from all over the world. They’ll be much better off than their monolingual father, to face the challenges of the future. But there are two more “languages” I will try my best to pass on to them:

programming. If our children learn how to write software, it will open up vast opportunities to them. It isn’t about how many software languages they learn – even one will be a big head start heading into college.
product design. I don’t think it matters if it is physical design or software design, but I want to impart to the kids something of the language of design – the terminology, the flavor, the subtlety of how you talk about it. I once compared “design language literacy” to the way chefs talk about food and cooking. If you want to communicate with a chef (or a foodie) about food, you need to learn their language and vocabulary. Similarly, for design, we need to learn the vocabulary and thought processes to communicate effectively – even if we don’t intend to become a designer.

These programming and product design skills are “meta” languages in a sense. They transcend national borders and historical language affiliation.

The comment section of Chris Dixon’s blog puts the exclamation point on the value of this post to the general school of thought about coding.

So who should learn how to write code? You should. Your children should.

The Experience versus the Expert, Part I

Scott Francis — Thu, 21 Oct 2010 13:09:10 +0000

There’s an ongoing debate between “open” and “closed”. Chris Dixon has written what I consider the most thoughtful blog on the subject, as it relates to phones and desktop PCs, which I referenced here.

This argument seems to come up any time Apple’s iPhone comes up because it is often referred to as a “walled garden”. Of course, this is nothing new for Apple. They were long criticized for keeping the hardware in-house rather than licensing their software to multiple hardware vendors, a la Microsoft. This is certainly one definition of “open” – giving a channel of manufacturers the ability to leverage your OS and build hardware around it. Another definition of “open” is releasing your source code for your operating system, a la Android, as Andy Rubin points out on twitter. But for Joe Hewitt of Facebook, neither iOS nor Android are open:

How does Android get away with the “open” claim when the source isn’t public until major releases, and no one outside Google can check in?

Compare the Android “open source” model to Firefox or Linux if you want to see how disingenuous that “open” claim is

Until Android is read/write open, it’s no different than iOS to me. Open source means sharing control with the community, not show and tell.

Clearly, from an OS-developer point of view, neither Android nor iOS (nor Windows, nor Mac OSX) meets the bar. (There’s a more complete writeup from Hewitt here)

From a Telecom Carrier point of view, Android meets the “open” claim: a carrier is free to jam pre-load it with proprietary software (good or bad). The handset manufacturers consider it open because they, too, can customize to their needs. Though, as Hewitt points out, they’re at significant disadvantage because they only have source code at major release points and have no way of getting their improvements back into the main branch of code so that it will survive into the next major release.

As an application developer, both Android and iOS are open at development time. For a small expenditure ($100 or less) I can equip my laptop with the software I need to develop my own Android or iOS application. I can even load the application on my phone to test it. I just can’t hack the OS on iOS. But if I’m writing applications, I don’t particularly *want* to hack the OS because I want my OS to look like everyone else’s (my customers’) OS. Open “source” for the OS is something that developers (the Experts) want.

Interestingly, I never heard people complain that RIM’s Blackberrys were “closed”. I suspect this is because the volume of developers for Blackberry was much lower and not in the mainstream (ie, Silicon Valley), and because the approval process for apps was dictated by each carrier in each geography, not by RIM. So the complaints weren’t targeted at RIM, but at carriers. Apple’s platform was clearly more open than RIMs in that the carriers couldn’t block your apps anymore. Apple had an approval process, but this process did not have a “negotiate payments” step in it – it was all about your application, not about holding you over the barrel for financial terms.

Apple (and Steve Jobs in particular) argue that the real debate is not open vs. closed, but “integrated versus fragmented”:

We see tremendous value in having Apple rather than our users’ be the systems integrator. We think this is a huge strength of our approach compared to Google’s. When selling to users who want their devices to just work, we believe Integrated will triumph Fragmented every time. And we also think our developers can be more innovative if they can target a singular platform rather than a hundred variants. They can put their time into innovative new features rather than testing on hundreds of different handsets.

So we are very committed to the integrated approach, no matter how many times Google tries to characterize it as closed. And we are confident that it will triumph over Google’s fragmented approach, no matter how many times Google tries to characterize it as open.

I like Steve’s re-framing of the discussion, the poles in the debate. But since I’m not marketing for Apple, I think the real debate is between the Experience and the Expert. Balsillie of RIM complains that “We think many customers are getting tired of being told what to think by Apple.” But Apple and Jobs aren’t telling customers what to think, or developers. They’re explaining how Apple thinks – Apple has to defend against this notion of “closed” because the point (for Apple), isn’t to address the Expert- it is to address the Experience.

Apple is oriented around creating a user Experience that “just works”. They don’t always succeed, but that is what they’re after (if I had a nickel for every time someone at Apple, or NeXT before that, said “and it just works” I’d be a very rich man). Meanwhile, the Experts are worried. The Expert wants to be able to see the source code, compile it themselves, contribute to the project. The Expert wants to decompile and find the internal APIs and write apps that leverage those unpublished APIs. The Expert wants to be able to install unverified code and run it (perhaps his or her own code, developed on their own laptop).

I think many Experts are concerned that Apple is dumbing things down. But certainly no more than Mac OSX did – for the experts. For the Expert, I can still write my own apps and install them on my own phone. If I want to sell them, there is a walled-garden channel for doing that – but “buying” is something non-Experts do, and Apple has built a streamlined Buying process within their iOS ecosystem. Experts don’t like it, but non-Experts love it. (No viruses? I like it).

There’s also an argument that “open” proponents make, that open wins out over closed over time. But the real question is what is the target market? Open source projects have often won over experts, but there are fewer examples where “Open” has won in consumer markets where the average consumer just wants their products to work. Linux has made huge inroads in corporations as a trusted server operating system, and open source operating system cores makes up the core of many other product offerings (including Mac OS X). But Linux desktops have never made much progress (don’t believe me? read Gosling’s article “Desktop Linux: the Dream is Dead“). It is both an economic problem (free), and a user experience problem (too complicated for the average consumer).

Even in the corporate world, some industry titans are evaluating an integrated approach – in order to create a better experience for the customer. The thinking goes that they can offer better integrated products – better tested, simpler integration, and simpler maintenance. Of course, to make that strategy work, Ellison’s Oracle has to offer an integrated stack in which each component of the stack keeps pace with the industry’s cutting edge. With the ecosystem of suppliers that feed the computer industry, this is easier to do today than in the 1980′s, when the vertical components would (mostly) be manufactured in-house.

The focus on experience is something that many people understand… but that many more do not. I highly recommend reading Sachin Agarwal’s blog post about Posterous, recounting an argument with someone who thought Posterous was doomed due to smaller share, and fewer features, than some of its rivals:

I asked this person directly: do you have an iPhone? Nope. Do you use a Mac or a PC? PC. There you go. You don’t get it. Until you use an iPhone, a Mac, drive a BMW or Audi, you don’t even realize how great the experience can be or how much it can drive the success of a product.

[...] My entire life, I fought for Apple. I tried to get my friends to use Macs. But they didn’t. It’s not because they thought their PC was better than my Mac. It’s because they didn’t know something better could exist.

[...] And they don’t measure products by what they do, but by how well they do them. You won’t find a matrix where Apple compares their product to a competitor by feature. They measure products by the experience.

We’ll return to this topic again… focusing on BPM.

The March of Open Source

Scott Francis — Wed, 29 Sep 2010 11:57:15 +0000

This article from Todd Barr, of Alfresco, made me think again about how open-source software might impact BPM. The point of the article is that VMWare is rumored to be acquiring SUSE Linux from Novell – and that this is evidence of the march of open source into commercial software companies.

I agree.

I think the key issue is one of complements and substitutes. If you are selling software, you want the complements to your product(s) to be cheaper or free, because those complements *increase* the value of your product. If you’re selling peanut-butter, you sure would like the price of bread to go down… even to zero. A better treatment of this subject than Chris Dixon’s blog post about Twitter and Twitter Apps cannot be found.

The only question in BPM is… what are the substitutes… and what are the complements? It depends entirely upon what your primary business is built around. If you’ve built your business around selling BPM software, then the complements are templates, databases, application servers, development tools, web services… all the other enterprise applications on the market.

If you’re selling one of those other applications or stack elements – then you want BPM to be cheap or free (a complement), because it enhances the value of your offering.

The next few years in BPM are going to be interesting.

Open vs. Closed

Scott Francis — Tue, 15 Jun 2010 14:48:02 +0000

Interesting article and followup discussion on the nature of Open vs. Closed, by Chris Dixon. It would be interesting thought experiment to characterize BPM in a similar fashion into dimensions and open/closed plotted against product offerings. You could imagine this chart from Chris:

OS vs. platform (originally from Tom Elsenmann, et al)

We could list on the left column, database, appserver, etc. But perhaps the most relevant items would be:

End User (browser-based, likely)

Authoring User (BPMN visualization)

Authoring User (BPMN data)

Engine (BPM engine)

Solution Provider (SIs, value added software resellers)

Platform Sponsor (BPM suite supplier)

…

At least, its interesting to think about the BPM space and what open means- each vendor is open and “closed” in different ways, which has an impact depending on the consumers of that solution.

Toys of Today

Scott Francis — Mon, 18 Jan 2010 14:09:23 +0000

Chris Dixon recently wrote that the next big thing will start out looking like a toy. No, he’s not presaging the rise of toys as the next trend in retail or tech (although, with 100,000 Apps on the App store and 3billion downloads, one could be forgiven for assuming that that would be his point).

Chris is pointing out that the next big thing often starts out looking like a toy because one cannot accurately predict how something simple will behave when it achieves network effects due to scale. And this is why incumbents often don’t identify the next big thing very quickly – because they dismiss it as a toy (at first). In fact, I’d say they often go through a few stages of denial:

It is just a toy, not worth wasting time on
It will only work for a certain niche
It will never scale
It will never work for enterprise customers (or, it will only work for well-heeled consumers)
It will never solve the really high end problems
Buy a competing product, or buy the original

I’m sure someone could come up with a better list than mine, however.

A Hunch About bp3 and #BPM

Scott Francis — Thu, 12 Nov 2009 13:20:17 +0000

If you haven’t used the site, hunch, you might want to give it a look. Its pretty interesting, as it attempts to crowdsource decisions. Hunch also does a pretty good job of anticipating your answers to questions based on your previous answers to questions.

Recently Chris Dixon made available a blog widget which can help you understand your readership demographics a bit better (assuming the readers participate!). I thought I’d give it a try…

Of course, I see some interesting possibilities for crowdsourcing vendor selection (BPM vendors), or philosophical debates like BPM vs. Business Rules. So I seeded a starting point, that is on Hunch now. I need to finish adding vendors to it, and I need help from others to add more results, train the results, and add more questions! (Anyone can login and add questions and results so please contribute! If we get enough contributions and training in, then this decision tree may have statistical significance )

Here’s the link to the BPMS decision helper…

Superman

Scott Francis — Tue, 20 Oct 2009 17:46:34 +0000

As previously noted in this blog (see Putting the Band Back Together), we’re believers in hiring Heroes. Meaning, you find and hire people that can, to large extent, “do it all”. We want to be the tip of the spear, at the front of the phalanx, for our customers. And the reason we do this is because we believe that BPM deployments greatly increase their odds of success when you seed the team with a few really good people. So I was very interested to see Chris Dixon’s article “Man and Superman“. In it, he examines why some tech companies seem to thrive beyond their first great product innovation’s life-cycle. He points out that Sony, Apple, and Microsoft all achieved this, but all were driven by a “Superman” during that time. In each case, when “Superman” wasn’t around, the companies did not fare so well.

I once worked for a company that, at the time, believed in great people making a difference. We studied works like Covey’s Seven Habits, and Jim Collins’ Built to Last (and later, Good to Great). However, at some point management decided that employees were highly expendable and fungible (the term “resources” entered the lexicon). The company is a shadow of what it once was. Reading Chris’ evisceration of Jim’s thesis that great companies are all about culture, not a singularly great leader, I can’t help but wonder if Chris has it more right than not.

Chris points out that most of the companies Jim profiled have since fared poorly – and not just with respect to the current economic climate, but with respect to the S&P 500 (Circuit City, for example, went bankrupt).

Culture might be important – but if you’re Superman in your organization, you better find another Superman to take over when you’re gone. The real lesson to take home from his post is that people count. Having good people counts. Culture alone is not enough. At BP3, we’re going to keep focused on hiring Heroes – perhaps we won’t live up to the Superman label, but we want the best, and we want people who are driven to keep expanding their abilities and who aren’t satisfied with status quo.

Is Computer Science the Only Major that Matters?

Scott Francis — Fri, 18 Sep 2009 18:25:30 +0000

Chris Dixon’s blog, which I recently was turned on to by another blogger, recently opined that the only college major that matters is Computer Science. Nice to see someone sticking up for my major! Naturally my bias led me to believe this post was sheer genius.

Of course, let’s put this in context: Chris is pre-supposing that you are interested in being involved with software companies. But given that context – if you are interested in working at a Google, Yahoo, Facebook, or any of the startups they’ve gobbled up over the years, the easiest and best way in is to know how to write software. And if you’re going to do anything else for them, it would be good if you at least know what code looks like. As Chris puts it:

Why is it so much better to learn computer science in college (or before)? Because after college it’s very hard to find the time and discipline to teach yourself coding. On the other hand, it’s pretty easy to pick up business skills, economics and all sorts of other skills on the job or in grad school.

He’s right. Learning computer science requires a lot of long, uninterrupted time to focus on what you’re doing and get the job done. There’s a reason computer science labs are open all night, but libraries typically have closing hours. A program isn’t done til it works. That paper is done when you feel like it is done (and you’ll probably get a better grade on it). The rigor required of proofs and code forces you to spend quite a lot of time on learning the art of coding. Very few people have the free time, or the discipline, or both, to really learn computer science well if it is not done in college, or as a kid, or as their full-time job. And it is difficult to get a software job if you don’t know how to write code…

I think one of the saddest things is that the media (newspapers, television, blogs) have convinced everyone that all the software jobs are leaving the US. Meanwhile, corporate America is, in some cases, helping make it so – by actually sending lots of those jobs overseas. But in fact the total number of software jobs in the US has increased. And, a computer science major will prepare you for more than one possible career (when I was a kid, I thought computer scientists just wrote games for a living – what else would you use a computer for, right? So the media scare on this front is a bit overdone.

As Chris states, not everyone who majors in Computer Science will write code for a living – any more than everyone who majors in History ends up studying it for a living. You can still go on and get that law degree, but now you’ll actually understand some of the stuff you’re protecting or litigating.

So maybe Computer Science isn’t the only major that matters – but it might be if you’re in the software business.