From time to time I advise start ups on mostly technical matters, inevitably they ask me for referrals to hire engineers or help with editing their job postings.
Typically they email me a very detailed and specific job description for a, say, Data Architect or Ajax messaging programmer or Java Engineer complete with an obscure list of libraries and technologies that the candidate expected to be master in (probably those technologies were suggested by their VC to them in their last meeting)
Start ups should be built like special forces, with a few brave and smart generalists with a lot of heart and "get it done" attitude, not by deep specialists in any certain area - I am talking about the first few engineers here - a statistical modeler with no programming skills or a Data Architect with focus on data replication makes a fine contractor for a short time to advise your core engineering team, but should not be one the first 5 engineers you hire.
Friday, June 25, 2010
Wanna Make Your Life Hard? There is an app for that, or maybe 100,000
These days it is not uncommon to find some one with 100+ apps installed on his/her phone (maybe you are one of those?). I imagine most of those apps are used once or twice and will never be used, the only time you see them (or their icon) is when you scroll past by them to get to your 2 or 3 (or five) apps you actually use frequently.
This app mania clutters UIs and waste a lot time, and I can't help but thinking "do we simply forget all the lessons and progress of last 10-15 years simply because a device came along with attractive aesthetics?"
What happened to "browser is the operating system?" in the days that most desktop apps are moving to cloud and being delivered thru browsers, why is it that most (if not all) mobile apps are native code? Yes native apps still have certain capability that browsers do not offer YET, but with HTML 5 and Web Kit (and maybe with a little bit of industry support to close the remaining gaps) browser based apps would be sufficient for large majority of mobile apps.
Don't get me wrong, there will always be need for native apps, but much like with desktop, over time only a few apps will be privileged to be native, most other will and should be browser based standard, write one, run on any browser apps.
This makes development of mobile apps simpler and more cost effective, instead of maintaining three apps for iPhone, Andriod and Blackberry, most developer only maintain one version, and you only install a few apps that truly need to be native apps.
This app mania clutters UIs and waste a lot time, and I can't help but thinking "do we simply forget all the lessons and progress of last 10-15 years simply because a device came along with attractive aesthetics?"
What happened to "browser is the operating system?" in the days that most desktop apps are moving to cloud and being delivered thru browsers, why is it that most (if not all) mobile apps are native code? Yes native apps still have certain capability that browsers do not offer YET, but with HTML 5 and Web Kit (and maybe with a little bit of industry support to close the remaining gaps) browser based apps would be sufficient for large majority of mobile apps.
Don't get me wrong, there will always be need for native apps, but much like with desktop, over time only a few apps will be privileged to be native, most other will and should be browser based standard, write one, run on any browser apps.
This makes development of mobile apps simpler and more cost effective, instead of maintaining three apps for iPhone, Andriod and Blackberry, most developer only maintain one version, and you only install a few apps that truly need to be native apps.
Monday, June 14, 2010
"My Dad is 50 years old, weighs 30 lbs and is 40 ft tall...I like him b/c he is silly"
A very competent and respected colleague of mine, in his early 30s, 5’9” and reasonably proportional I might add, has the following written by his 5 year old son posted in his cube:
“My dad is 50 years old, 30lbs and 40 feet tall and I like him because he is silly”
Besides it being funny and making me think what my daughters really think about me, it reminds me of how our products can be perceived and used by other engineers: They way they see it not they way “they are”.
If you are developing systems, services and products for other developers, it is important to understand that your will be used they way others understand it and not the way you planned it to be used. I have seen a session service used as a general purpose cache, ESB riddled with use-case specific routing logic, authentication service used as data pre-fetch mechanism and presentation logic (in XSL) saddled with complex and critical business logic – of course in XSL. All examples of how we all use tools to solve our problems regardless of whether or not the tool is meant for it (remember eating jelly with knife?)
The first solution of course is documentation, but here is what that documentation should include:
- Real world, working and end to end examples of the right way to use the services/product
- Examples should be cut-and-paste able (to the extent possible)
- Realistic examples of wrong way of using systems, updated periodically as new misuses surface
- Direction and pointers for how to address the original need leading to the misuse.
- Address of a user (or expert monitored) forum where users can get help
“My dad is 50 years old, 30lbs and 40 feet tall and I like him because he is silly”
Besides it being funny and making me think what my daughters really think about me, it reminds me of how our products can be perceived and used by other engineers: They way they see it not they way “they are”.
If you are developing systems, services and products for other developers, it is important to understand that your will be used they way others understand it and not the way you planned it to be used. I have seen a session service used as a general purpose cache, ESB riddled with use-case specific routing logic, authentication service used as data pre-fetch mechanism and presentation logic (in XSL) saddled with complex and critical business logic – of course in XSL. All examples of how we all use tools to solve our problems regardless of whether or not the tool is meant for it (remember eating jelly with knife?)
The first solution of course is documentation, but here is what that documentation should include:
- Real world, working and end to end examples of the right way to use the services/product
- Examples should be cut-and-paste able (to the extent possible)
- Realistic examples of wrong way of using systems, updated periodically as new misuses surface
- Direction and pointers for how to address the original need leading to the misuse.
- Address of a user (or expert monitored) forum where users can get help
Thursday, June 10, 2010
Presentation for my eBay DevCon 2010 Talk
Here is the slide deck for my talk @ eBay DevCon 2010" The User Who Came In From the Cloud.
If you ever wanted to consume identity from external identity providers (Facebook, Google, Yahoo, PayPal etc.) you may want to check it out.
If you ever wanted to consume identity from external identity providers (Facebook, Google, Yahoo, PayPal etc.) you may want to check it out.
Friday, June 4, 2010
"Failure is not fatal, but failure to change might be" John Wooden
John Wooden, the Wizard and West wood, passed away today. I imagine most of the readers of my blog probably do not know him, you can read all about him by visiting his official web site.
He was the embodiment of the word "coach", not only did he win 10 national championship (7 consecutive), he developed players and MEN.
I am a Big Ten guy and never cared much about Pac 10, but I learned about Wooden by leanring about his amazing basketball dynasty at UCLA - anyone who ever worked with young 20 year old programmers can appriciate what it takes to get them focus on a goal and develop the decipline to achive it - then I read his books and his favoriate maxims. And only then I truely appriciated why they call him "The Wizard".
Of course he was not a software architect, but what said about "...failure to change" should be on top of every architect's mind, he proved it by architecting a system that work flawlessly level in 12 different environments. How many of us can create a system that works in 12 different environments?
Yet again, make me convinced that the essence of architecture is about changing gracefully.
He was the embodiment of the word "coach", not only did he win 10 national championship (7 consecutive), he developed players and MEN.
I am a Big Ten guy and never cared much about Pac 10, but I learned about Wooden by leanring about his amazing basketball dynasty at UCLA - anyone who ever worked with young 20 year old programmers can appriciate what it takes to get them focus on a goal and develop the decipline to achive it - then I read his books and his favoriate maxims. And only then I truely appriciated why they call him "The Wizard".
Of course he was not a software architect, but what said about "...failure to change" should be on top of every architect's mind, he proved it by architecting a system that work flawlessly level in 12 different environments. How many of us can create a system that works in 12 different environments?
Yet again, make me convinced that the essence of architecture is about changing gracefully.
