Agile Google-style

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places.

If you're in the habit of pre-announcing your software, then the general public usually wants a timeframe, which implies a date. This is, I think, one of the reasons Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.

The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take. So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google.

"How To Write Unmaintainable Code"

http://freeworld.thc.org/root/phun/unmaintain.html

Source Code Is A Liability, Not An Asset

http://blogs.msdn.com/elee/archive/2009/03/11/source-code-is-a-liability-not-an-asset.aspx
http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability

Don’t we spend our entire professional careers designing, writing, and testing code? That’s what we do, right? Well, no. What we actually do is deliver business value, or solutions to real-world problems, or however you want to state it. That’s why companies employ software developers. Source code is merely the necessary evil that’s required to create value. With few exceptions, source code itself is not a valuable commodity.

Tradeoffs

Tradeoffs: the better of two goods
have as little source code as possible vs well-written, maintainable code is often more verbose than dense, impenetrable code, but you should always favor maintainability

Tradeoffs: the lesser of two evils
...

False Economies
companies will happily spend multiple months of an employee’s time, at a true cost of at least $10,000 a month, counting benefits, office space, and the like, in order to avoid paying $1000 or even $500 to license a third-party software package that does the same thing

Edward Tufte One Day Seminar

http://codeliability.blogspot.com/2008/05/edward-tufte-one-day-seminar.html

Edward Tufte

quotes and general notes:

• Great designs are transparent
• Never segregate data by the mode of production.
• Show all the data, it provides credibility.
• We should be concerned with the quality of thought.
• Don't use lowest common denominator design or you will have an intellectual disaster.
• Tables out perform graphs for data less than 1000 points.
• Screens should be 95% content and 5% administrative debris (scrollbars, toolbars, etc.). Measure it.
• Design the surface first. Outside-In design. iPhone designed the hardware platform before the software. iPhone has one of the highest DPI of any consumer device.
• Don't provide an application solution.
• Leave the UI alone once it's done.
• There is no relationship between the amount of information and the ability to process. The human eye can process 10mbit/sec.
• Don't be an original. Steal a good design.
• Consider a "super graph". It unifies and relates the audience to the data or theme.
• Increase information throughput
• Examine how newspapers report data and clone it. Examine "Nature" magazine.
• Multivariant problems are the only interesting problems.
• Progress in technology is measured in resolution
• Don't use legends on graphs. Put the text on the line.
• Maximize content reasoning and minimize decoding
• "We want to be approximately right rather than absolutely wrong"
• Use Gill Sans Font
• Annotate everything

about presentations

• Show up early for your own presentation to meet people, to show a gracious gesture, and to hand out materials early.
• Use presentations as a review of the material distributed prior to the meeting. Maybe simply ask "Are there any questions?" and end the meeting.
• Use Power Point as a projector operating system
• Give out handouts before meeting - people can read 2x-4x times faster than you can talk.
• What is the problem?
• Who cares? the relevance
• The solution
• Have a summary
• Say you will answer questions when they are done reading
• Use sentences. No laundry lists of nouns. Sentences for you to think causally.
• Don't use bullet reveals.
• Practice in front of a friend or a video camera
• Turn off the video and listen to the audio
• Ask a trusted friend for criticisim
• Never begin with an all purpose joke
• Never apologize at the start of the presentation
• Stay out of the first person during the introduction
• Stay on content
• Finish early