Android guts

March 19th, 2012

I spend quite a lot of time by now researching different stuff in Android operation system sources.

Here are several links which are very useful for somebody who just started to look at AOSP.

Marakana info:

Internals overview:
Video, Slides:

Building custom ROM videos:
Video part 1, Video part 2

Security:
Video, Slides:

Embedded Android book

Book

Different

Android Platform Dev Guide
How activities are started

A declining gap between onshore and offshore rates

March 17th, 2012

I remember back in the year 2000 a going rate for a smart offshore developer was about $8-12/hour. At the same time, a good software engineer in Northern Virginia had a salary about $80-90K (which translates to about $50/hour).

So, it was no brainer to offshore as much work as you can (to get 4-5 developers for the price of one).

Now, the pricing has changed quite a lot. The offshore hour rate become $20-35/hour and an expenditures on local software engineer went up to about $75/hour. So, it’s now 2 to 3.5 offshore developer for the price of one onshore developer.

Frankly, one guy sitting in the office and communicating directly could be more productive (or at least of the par) than two offshore guys. So, on the first glance, amount of offshoring should go down.

However, there are couple wrinkles:

– An offshore personal pool is much-much bigger than local US (or European). So, if you want to find somebody good, smart and passionate, you have way more fitted candidates worldwide than in 20 miles radius.

– I believe offshore companies and developers has made tremendous progress for last 10 years. They learned how to work with customers, learned whole software development process from a cradle to a grave of a project and so on. (Just to make sure that it’s clear. I don’t say that ALL companies become good. I say that number of experienced software developers and managers became much higher within last 10 years).

So, long live offshoring 🙂

Too many ways to skin a cat?

March 7th, 2012

Do you follow a waterfall process or agile?
Do you use TDD or BDD or maybe D3?
How about SOLID principles? DRY?
I hope that you are aware of KISS and “You ain’t gonna need it“.
Do you plan to expose RESTful or SOAP web services?
What language and frameworks do you use?
How do you structure code, branch it, build your project?
How do you design, review code, comment code?

I can keep going like that for hours… There is unbelievable amount of HIGH level decisions which are made for each project. A lot of them have they own dependencies on other principles and decisions. And all of them will stir the development one way or another and presumably can make a huge difference.

And now the final and most important question. How do you know that your (or your team/company) choice is good and competitive?

I understand that there is no rational way to measure that. However, “It worked for me on last project” sounds like a weak argument.

Survivor bias

March 3rd, 2012

I quite often read some business related blogs or books and they are full of smart, energetic, sound and at the same time absolutely unfounded advices.

Just couple of examples: a book Good to Great or TAD talk, Simon Sinek: How great leaders inspire action

It usually goes something like this: “Let’s look on these three supersuccessful companies: Apple, Google, Facebook. All of them were founded by people who truly believed in changing the world. That means that to be successful all you need is a desire to change the world. And everybody who doesn’t believe in this will forever stay pimply, asocial and poor dummy’.

That’s exactly a Survivor bias. We get several “survivors” (several big companies) and disregard everybody else (all those other companies which failed and which were start by people who wanted to change the world too). Also, we disregard companies which become successful and which were started by people with different mindset.

So, all these advices try to imply some causation, when they don’t even properly prove correlation.

BTW. Here are several people who wrote about this problem too: Business Advice Plagued by Survivor Bias, Rails, Scrum, CMMI and Survivor Bias.