Photosynth demo at TED2007

Wow, this is cool.

The Dip summarised with one question

If you accomplish that, will you be seen by your audience as the best in the world, or will you be seen as doing your best?

Seth Godin

The profit maximisation principle

Art Smalley claims that one of the first slides that he saw when he did his Toyota orientation was this simple equation:

(Price - Cost) x Volume = Profit

What a great way to sum things up.

Price is controlled by the market perception of the value of our product or service. In other words, how valuable is the story? But that's just the price you can display. The price people will actually pay is also affected by their perception of their own identity.

Price has nothing to do with how expensive it is for us to produce the product or service.

Cost reflects the efficiency of our provisioning process, where typically the largest wastes are from doing things that we don't have to do.

Volume is pretty straightforward. It's just the number of units we sell or the number of people we are charging for to provide the service.

So the essence of improving profitability is increasing Price (through marketing, design, and engineering) and decreasing Cost (through design, engineering, and in general improving how we go about doing things).

That's it. The rest is details.

And if you don't have this focus, the details won't matter.

News Corp (aka "the Murdoch Empire") will go carbon neutral

I don't recall hearing this on any of the local news which is odd... but via the Good News Network, apparently Rupert Murdoch pledged that News Corp would go carbon neutral and add climate messaging to its content and programming.

Who'd a thunk it?

Personal Masters of Software Engineering

I discovered The Personal MBA a while back and thought it was a neat idea so I came up with my own Personal Masters of Software Engineering which was just a text file. I've now moved the contents to a Squidoo lens to try that out and share with other people.

I must admit, I'm not entirely satisfied with that medium but we'll see how it goes.

Communication is terrible

Via Peter Abilla,

An old Fast Company article on Jeff Bezos lists "Communication is Terrible" as an Amazon Rule.

Communication is terrible.
When Jeff Bezos's people said they needed to communicate more within the company, he shocked them by shooting back: "No, communication is terrible." To promote his decentralized vision of the company, he created "two-pizza teams": highly autonomous task forces with five to seven people -- no more than can be fed with two pizzas -- who innovate and test new features.

I hear that.

See also the concept of Consent versus Consensus and read Guns, Germs, and Steel.

Extended deadline for PLoP 2007

******************************

***************************************
EXTENDED DEADLINE

14th Conference on Pattern Languages of Programs (PLoP 2007)

September 5-8, 2007 - Monticello, Illinois, USA
http://hillside.net/plop/2007/

~ Peer reviewed ~ Digitally Archived ~

*Paper submission deadline extension to June 4th*

*********************************************************************

Dear all,

After receiving several requests, the chairs have
decided to extend the submissions deadline for PLoP 2007 to *4th June*.

Papers already submitted will be honored by
having a shepherd assigned as initially planned, at 4th June.

In order to help the shepherd assignment process,
you may also send us short abstracts that will be
posted as placeholders to be used by shepherds on their selection.

Papers received until the new deadline will be
made available for shepherd assignment
immediately as they are received. Updates of
current submissions will also be accepted until the new deadline.

All papers are peer reviewed. Dates for
submission of post-conference papers and
copyright forms for digital archival will be
announced later (PLoP'06 papers are being archived on ACM Digital Library).

We sincerely hope this extension will help the
authors with problems on submitting on time for
the initial deadline and that accommodates well with the other authors.

*New Important dates (extended)*

May 21-June 4: Paper submissions due.
June 4-11: Shepherding begins
June 29-July 6: Shepherd recommendations
Aug 1: Notification of acceptance
Aug 12: Conference Drafts due
Aug 19: Early registration ends
Sep 5: First Day of PLoP


We will look forward for your submissions.

Best regards,
Joseph Yoder and Ademar Aguiar
PLoP 2007

Who gets to define the acceptable level of quality?

The final consumer, the person who is forking over the money at one end of the value stream, gets to define what level of quality is considered acceptable.

And the fact that a defect is reported against a product or service means that the level of quality is not completely acceptable.

So what does this imply for our process?

Does the Product Manager get to say that the level of quality is "good enough" despite the likelihood that defects will be reported? Does the Product Manager get to say "don't bother spending the effort to fix that" or "don't bother spending the effort adjusting the engineering process to prevent that type of defect from occurring again"?

Two thoughts:

First, I need to find another product manager who understands the competitive advantage of delighting customers rather than just being good enough. In other words, I want to be the one setting the expectation that the competitors must struggle to match.

Two, I need to ensure everyone understands the strategic importance of encouraging pride in work.

Productivity is not about amount of scope produced

Am I a more productive software developer if I produce more LOCs or function points or some other magical size measure than other people?

I disagree with Martin's assertion that we cannot measure productivity in software development because I'll claim that productivity has nothing to do with size. The only output that matters (assuming an economic context) is financial return. How much money on average is the organisation making (ROI, net profit, cash flow) per unit of time of me developing software?

This does mean that as a developer I need to be also concerned that I'm building the right things, in the right order, and released early and often to get early payback. But that's the point isn't it?

It's not the "poor developers" that cause negative productivity

It's not poor skill that causes negative productivity; it's demeaning personalities that create a culture that can't be productive.

I blogged about this before.

Instead of a 20x developer that causes everyone to stay at 1x, I'd rather have a 10x developer that causes everyone to grow to 2x. I'd rather hire temporary consultants to deal with the cases we can't deal with rather than deal with a permanent jerk.

Agility is not the point

Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?

...

Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.

Kent Beck on the Extreme Programming page at the Portland Pattern Repository

The message of Extreme Programming, now more commonly referred to as XP, was about only doing the things that matter and doing those things as best as you could. That was about minimising waste, not agility.

I remember something in the first edition of Extreme Programming: Embrace Change about thinking about acting as if we lived in a society of plenty instead of a society of scarcity. That was about mutual respect and cooperation, not agility.

Agility became the story of "lightweight" methods only after the Agile manifesto. Before that it was something else.

The current Agile story ends up with very valid objections by people like James Bach and perhaps the whole Post-Agilism thing because the "Agile" word is empty. In my opinion, Agile is also an inaccurate way of describing what I want to do, why I want to do it, and who I want to be.

Lean is the story that Agile should have been.

Only do the things that matter. Do the things that matter the best you can. Respect people.

Agility is just a side effect...

Well, perhaps I exaggerate...

From Isao Kato in TPS vs. Lean Additional Perspectives, the four aims of the Toyota Production System are as follows:

• Deliver the highest possible quality and service to the customer
• Develop employee potential based upon mutual respect and cooperation
• Reduce cost through the elimination of waste in any given process
• Build a flexible production site that can respond to changes in the market
  

So it's not so so much that agility is just a side effect but rather that agility is definitely not the only point.

CruiseControl Enterprise is live

CruiseControl Enterprise is live.

Check out the screenshots of the new web app that will be Open Sourced in the next couple weeks or so.

The five second rule might not be a myth

Via the Freakonomics blog,

Well I always thought the 5 second rule was bogus but apparently the empirical evidence suggests otherwise:

Slices of bologna and bread left for five seconds took up between 150 to 8,000 bacteria from surfaces that had been contaminated eight hours earlier. However, left for a full minute, the food slices collected about 10 times more bacteria from the tile and carpet, and a lower number from the wood surface.

Of course, depending on the type of bacteria, 5 seconds is more than enough time to contaminate the food.

What does this sign say about respecting customers?

http://sethgodin.typepad.com/seths_blog/2007/05/no_exceptions.html

You can walk into a store, an office, a factory, wherever... and there are immediate clues about whether that organisation believes in Respect People. How signs are written is one of them.

The war against the talent myth continues

David Maister expands on Bob Sutton's article that I referenced earlier.

He adds his own lessons:

1. In hiring, never let the pursuit of volume get in the way of maintaining the highest possible standards.
2. People want the opportunity to learn and grow: you must actively work to provide a variety of stretching, challenging experiences.
3. Standards of people supervision and management are as important as standards of product or service quality: they should be monitored and enforced in the same way.
4. Firms that try to win by hiring pre-existing, already-formed talent will never do as well as firms that are skilled in building talented people.
5. Talent is over-rated: character and energy count for more.

Emphasis mine.

Mark Graban at Lean Blog provides the Toyota take on this which I will re-interpret for the general case:

1. Be very selective with new offices and new employees.
2. Develop talent and grow people as a key tenet.
   
3. Standardise work for supervisors and managers as a key concept. Define standards and a system for HOW to manage is something. Don't throw people into supervisory roles with only a "good luck."
4. Build talented people, developing the talent you hired. Another key principle.
   
5. Building on the selectiveness of #1, hire for teamwork skills and other soft skills -- showing up on time, being able to make suggestions, working with others, etc.

And just to make sure, when Lean people say "standardised work" they mean something different than what you might think.

CITCON Asia/Pacific 2007

The Open Information Foundation, co-founded by Jeffrey Fredrick and Paul Julius, presents CITCON Asia/Pacific 2007 in Sydney, Australia.

CITCON (Continuous Integration and Testing Conference) brings together people from every corner of the software development industry to discuss Continuous Integration and the type of Testing that goes along with it.

• What: OpenSpace event discussing all aspects of CI and Testing, together
• Where: TBD, Sydney, Australia
• When: July 27 & 28, 2007
• Who: Everyone interested in CI and Testing
• Cost: Free

Attendance is limited to 150 delegates on a first-come, first-served basis, so register now!

If you are interested in finding out more about CITCON Asia/Pacific and future events please join the CITCON mailing list.