An interesting article in the NYTimes on reading habits of CEOs:

Serious leaders who are serious readers build personal libraries dedicated to how to think, not how to compete.

Perhaps that is why — more than their sex lives or bank accounts — chief executives keep their libraries private.

I’m in the midst of choosing some new bookcases. My book collection is starting to get out of hand. A good problem to have methinks.

Thanks to Brad for the link, and for a number of great book recommendations from his blog.

From The Origin of Wealth:

Markets win over command and control, not because of their efficiency at resource allocation in equilibrium, but because of their effectiveness at innovation in disequilibrium.

Evolution, genetic algorithms and complexity theory, as applied to economics: It is a search problem.

This book foretells the demise of economic theories based on equilibrium. To tell the story, a wide path is walked through the history of economics, advanced computer science, physics and some chaos theory. Very interesting reading, if you are interested in economics, or why economics works or doesn’t (quite) work.

For a review, see John Hagel’s article.

The ETL series has been consistently good, and the recent lectures have continued the tradition.

A question posed by Jackie Speier, a former senator, really got me thinking:

What would you do if you knew you could not fail?

The thing that struck me was that I have no easy answer for this question.

I don’t know.

Fortunately, it is the kind of question that if you spend time thinking of an answer, you’re getting somewhere. Even without an answer, the path towards an answer is constructive.

So, what would you do if you knew you could not fail?

Eric Schmidt was interviewed recently by Wired. Some of the hightlights from the discussion include:

Architecture

Now, with the Internet protocols you can pretty much plug in your own interpretation of how email should work and your own interpretation of how voice over IP should work.

And so was spawned a swarm of Web 2.0 companies all attempting to re-invent the wheel, now in a web browser. The interesting piece for me is the potential of sync. Newsgator is my favourite for this (multiple clients all sync’d to a central server allowing online and offline).

Google docs and spreadsheets don’t work if you’re on an airplane. But it’s a technical problem that is going to get solved. Eventually you will be able to work on a plane as if you are connected and, then when you get reconnected to the Internet, your computer will just synchronize with the cloud.

Could I have this? Please? Like yesterday?

Advertising

The other interesting thing about pageviews is that we make our money by improving the quality, not the quantity, of ads showed on a page. This is very confusing to people. In a normal media business, you make money by showing more ads.

Organizational Structure

Google’s biggest scaling problem may actually be their culture. It is obviously something on their CEO’s mind.

It’s a constant problem. We analyze this every day, and our conclusion is that the best model remains small teams running as fast as they can and tolerating a certain lack of cohesion. The attempt to provide order drives out the creativity. And so it’s a balance.

Innovation

Virtually all of the innovation at the company is still coming out of 20 percent time.

Innovation doesn’t happen by accident, it happens due to a good environment that encourages it. Part of this is allocating time to let it happen. The other part is providing incentives. At Google, a good 20 percent time project has the potential to turn into a fully branded Google product. One heck of a carrot for a developer.

Search

We also know Google News, for example, which we don’t monetize, has had a tremendous impact on searches and on query quality. We know those people search more. Because we’ve measured it.

Interesting.

There is a lot of useful information in the interview and it is well worth a read.

Update: Wired has posted an earlier interview with Eric Schmidt. (link via daring fireball’s linked list)

Estimating software development is hard. But it doesn’t have to be impossible.

Software Estimation by Steve McConnell draws together research and experience from the field of estimation into a single, easy to read, volume.

The biggest lesson I got out of the book is “Count, Compute, Judge”.

Count if at all possible. Compute when you can’t count. Use judgement alone only as a last resort.

The software estimation I have been involved in falls into the realm of judgement. This is usually due to insufficient data available, or the lack of knowledge of the data that needs to be collected.

Some other highlights include:

• Relevant information from many sources (ie. key formulas from research papers, process details and examples)

• Details of industry studies and references to other work, allowing for deeper study.

• Broad coverage of estimation topics. There is much happening in this area, and this book covers it from a practical standpoint.

• Strategies for presenting estimates to stakeholders and navigating the associated political minefield.

  … estimate negotiations tend to be between introverted technical staff (developers) and seasoned professional negotiators (sales staff).

One area I found missing from the book is estimating changes to existing systems, such as maintenance and enhancements. The focus for the book is on new features and creating new products. Hopefully the process and systems recommended, such as estimating from historical data, covers maintenance development.

In addition to good process and practice, there is a useful section towards the end with rules of thumb derived from industry findings. Some of them include:

• To go from one-company, one-campus development to international outsource development, allow for a 40% increase in effort.

• Allow for a 1% to 4% increase in requirements per month.

• For first-time development with new language and tools compared to comparable development with familiar language and tools, allow for a 20% to 40% increase in effort.

• For administrative and clerical support, add 5% to 10% to the base effort estimate.

Software estimation is an important part of the development process. Estimates provide the benchmark that subsequent development is measured against. Making estimation an area that deserves more study, and making this book a must read for any software professional.