Why Silicon Valley is bad for Enterprise IT

99% of IT is done outside of Silicon Valley in Enterprises.  I like the valley and San Francisco is my second favourite 'new' city (Sydney comes first, London, Rome and Paris remain... well London, Rome and Paris).  The problem is that 99% of the media about IT is about what happens in Silicon Valley.  This is the equivalent of all coverage of the global car market being about Ferrari.  Its not good for IT for a few reasons.

1. A large proportion of Silicon Valley is hype over reality - remember Transmeta? A company whose coverage dwarfed that of ARM for several years, despite ARM clearly being better
2. It focuses on the 'new' over the 'useful' - Lots of good stuff comes out of Silicon Valley but the focus is always on 'the next new thing' this leads to lots of new 'wheels' for IT but very little in terms of actual progress.  Is Enterprise IT better today than it was 10 years ago? 20 years ago?  Possibly a bit with things like Java, but the focus in Silicon Valley today is to INCREASE language fragmentation thus reducing the benefits.
3. Its technology over practice - we've known for 40+ years that the real issue is in design, Silicon Valley focuses on the coding not the practice
4. Its become a circle-jerk the tech media, tech companies and VCs all running around in their own little hype cycle un-encumbered by reality.

The impact is that even the older vendors in the valley tend to leap on bandwagons like a politician desperate for votes. So rather than fixing existing technologies or providing you with the minor enhancements you get a bunch of shiny new technologies that don't work terribly well to put on top of the  old pieces that have bugs they don't fix.

Lets be clear there are great things that come out of the valley and some real revolutions have been driven from there, but revolutions have happened in other places too, Waldorf, Cambridge (UK and MA), India, CERN and lots of others.  But what really hasn't happened, and Silicon Valley is the biggest criminal in this crime, is a focus on improving the 'dull' part of IT.  Project failure rates remain high, integration is still a technical job and data quality remains poor.

Unfortunately the current set-up is designed only to hype the new rather than improve the infrastructure of IT.  Now some could argue that this is a great example of where capitalism doesn't produce the greatest good for the greatest number as the current approach actually does very little to improve the lot of the majority in IT while enriching a small subset... but I wouldn't say that as capitalism remains the only system that actually works.

The question therefore is how can IT re-orient away from the valley and away from the hype.  I think the rise of India and China will be key to this.  China and India are focusing on 'being good' rather than 'being shiny'.  This focus on improvement and innovation for improvement rather than straight innovation for the brand new.  As these economies grow and their importance to IT grows maybe we'll see a shift in IT away from the new and shiny towards the actually improving.

Lets hope.

(please note in the above I exclude Apple as they appear to live in a bubble disconnected from the valley ;)

Theory v Practice - the opposite view

There is an age old saying

In theory, practice and theory are the same thing, in practice they aren't

This is true 90% of the time, but in Engineering it isn't always the case. I was speaking to someone a day or so ago about interviews and they were nervous as the job they were applying for required a specific programming skill and they had only done "a bit" of it.

What I told this poor young fool was that as they had talent (and they do) this lack of experience was just a minor element. Could they learn more in the week before the interview? I asked. "Sure" came the reply.

Well there you go. Any if they ask questions about threading and deadlocks can you answer them.

"Well I know the theory but not the syntax"

And it was here than I imparted the knowledge... Its actually the theory that counts not the syntax. To this end I'll tell two tales.

My first job interview was for a start-up company. They had some interesting bits around Eiffel and were trying to create a meta-language on Eiffel that enabled multiple different GUIs and Databases from a single code base. Part of this would require me to know C. I was asked

"Do you know C"

"Sure" I said.

"You'll have to take a coding test next week to check" they said

This gave me 7 days to learn C, a language I'd never coded in before. By the end of that week I was coding with pointers to functions which took pointers to arrays of functions as arguments. The reason was I understood the theory and could quickly apply it to the new syntax.

I got the job..... but they went bust 6 months later owing me 2 months wages so it wasn't the best story.

Now for another story, a good friend wanted to shift out of his current IT job which didn't do coding into a coding job. He had a bunch of theory and brains but no experience. I boldly said that I could coach him through a C++ interview in a couple of weeks. For 2 weeks we talked about classes, STL, friends and lots of other things.

He got to the interview, chatted for 30 minutes about computing in general and was asked the killer question

"So you know C++"

To which he quickly replied "Yes".... and the interview was over. He got the job and was pretty bloody good at it, despite the level of bluffing (although the single word "Yes" isn't the strongest bluff in the world).

The point is that if you understand the theory of programming languages and computing then individual languages are just a set of syntax that implements that theory in a specific context. Unfortunately in IT very few people understand the theory and are therefore condemned to badly implement software in the manner of an orang-outang who doesn't understand English but has a dictionary of English words to point at.

Lots of times Theory is less important than practice, but in IT if you don't know the theory then the odds are you'll be rubbish at the practice.

Technorati Tags: SOA, Service Architecture