Who'd have thunk it!

Even Firefox, the current flavour-of-the-month, isn't quite as invulnerable as the evangelists would have us believe!

Apparently Safari on Mac fell in a few seconds!

Google's Chrome was reportedly looking good at the close of day one of the Pwn2Own competition…

[update]
By the end of the contest:

The contest uncovered 4 new and unique critical vulnerabilities affecting the latest and greatest versions of IE, Safari and FireFox. The Chrome browser gets a small nod for being impacted by one of the flaws, although exploit is not possible using any current known techniques.

[update 29/3/2009]
Apparently Mozilla Firefox is the first browser to be patched.

20 Tips to Help You Avoid Success.

A switch to agile often conflicts with personal career goals such as maintaining the status quo and working no harder than necessary. These twenty guidelines will help you sabotage your agile project, helping you fail quickly and spectacularly.

As if help was needed ;-)

Become a Certified Agile Software Specialist!
The Fastest Certification On The Web.

Puts me in my place :-)

…brevity, perhaps?

Too often, I see code like:

Groovy lets us create much neater code:

I find the version with 'with' much clearer. It isn't actually shorter but-much more importantly-the code clearly indicates: "Dear MAINTAINER: this is doing a bunch of things that are related or require a shared context; break this apart at YOUR PERIL."

It's not perfect, but it is better than nothing and it'll do for now…

I put this out there in the hope that a few will discover this 'new' statement (the 'with' statement is present in algol68, and may even be older), and a few others will recall it…my contribution to a better world ;-)

http://www.soapatterns.org/, a site dedicated to the on-going development and expansion of the SOA design pattern catalog.

I came across it when I was trying to remind myself what VETRO stood for ("Validate, Enrich, Transform, Route, Operate"…I simply could not remember what the 'O' was for…) .

Please don't snigger, but I just learned this useful little SQL nugget:

SELECT
  (SELECT 1 FROM dual) AS one,
  (SELECT 2 FROM dual) AS two,
  (SELECT 3 FROM dual) AS three  
FROM dual;

Voila!

OK! OK! I admit my knowledge of SQL is bad!

I never did like Assembly Languages (although I admit to a soft spot for the Motorola 68000 series).

I can't work out why the data-oriented community is so resistant to the clear need to evolve away from this rubbish.

Heaven knows, for the good old 80% case, we can do much better.

Drectly quoting: Re: When does Agile fail?

The answer would have to look like:

- When does it work better to focus on process and tools, because focusing on individuals and interactions would fail?
- When does it work better to focus on comprehensive documentation, because focusing on working software would fail?
- When does it work better to focus on contract negotiation, because focusing on customer collaboration would fail?
- When does it work better to focus on following a plan, because focusing on responding to change would fail?

Pretty much everything else comes down to, "we tried some set of techniques and strategies, and operationally, they didn't work for us."

Which doesn't say anything about whether "agile" works or not, more about how well the organization reacted, how appropriate the
strategies chosen, and how the people worked together.

By the way, if you think this is an unfair test, try reversing it:

- When does it work better to focus on individuals and interactions, because focusing on process and tools would fail?
- When does it work better to focus on working software, because focusing on comprehensive documentation would fail?
- When does it work better to focus on customer collaboration, because focusing on contract negotiation would fail?
- When does it work better to focus on responding to change, because focusing on following a plan would fail?

I think we can construct answers to those.

I like this quote from Rahm Emanuel, US President Barack Obama's chief of staff:

"You never want a serious crisis to go to waste. Things that we had postponed for too long, that were long-term, are now immediate and must be dealt with. This crisis provides the opportunity for us to do things that you could not do before."

This was given as the opening line of a ThoughtWorks-sponsored breakfast briefing that I attended this morning. The topic was "Lean times require Lean Thinking" and was promoted thusly:

The Toyota Way, also known as Lean, was born from hardship and survival. It is an approach that does not rely on the accidental fortunate circumstance of being in a positive business climate. The system that propelled Toyota to the top of the global automotive industry is designed to succeed in both good times and bad.

Lean thinking fundamentally changes the engagement model between IT and the business, challenging traditional relationships with staff, customers and partners.

This session, presented by a partnership between ThoughtWorks and KM&T, explains the Lean approach to challenges, continuous improvement, productivity, and quality, and how these principles can help you deliver high-value, high-quality software solutions to reduce operational costs, increase pro?tability, and survive.

As the purse-strings tighten, maybe we can learn from Toyota's experience: stop doing BDUF/waterfall projects, move our organisations from their currrent "Authority Focus" to a new "Responsibilty Focus", start taking the Agile Manifesto to heart, start learning to actually use our technologies rather than fear them (newsflash: periodically snapshotting a database for 'offline' use is not inherently a safer solution to 'live dipping', even if it feels more comfortable; newsflash: the days when RAM/disk was more expensive than programmer time is long gone; newsflash: FTP is not the perfect SOA transport; newflash:a project's success is not to be measured by the number of shelf-feet of documentation it produces; I could go on…and on…and on…)

I was particularly interested in the way that Toyota's use of Lean helped get the Prius to market faster, at significantly lower cost and with far fewer team members than any other company could have managed.

Maybe interest in the agile methodologies is beginning to have an effect: perhaps Scrum, XP and Lean are about to go mainstream? There is certainly a lot more 'buzz' around now…

I can but dream!

(Best technical book, anyway…)

The Art of Agile Development by James Shore and Shane Warden.

Excellent content presented very clearly. This is the book to show a worried team or sceptical manager.

Hmmm…it's actually a bit thick for your average PHB. Not too many pictures either, come to think of it :-)

One of my colleagues recently asked for the 'Zen and the Art of Motorcycle Maintenance' for the Project and Program Management space.

This is it, IMHO.

In the words of one reviewer on Amazon:

Finally somebody put together a book with the sharpest insights that you find…

Another reviewer finished up with:

Buy the book, read it, use it to implement agile practices and return to it frequently.

Say no more, guv. Say no more.

"Real Programmers do UML."

One hears that a lot, but to be honest I have had better experiences with much simpler tools: sticky notes and CRC cards. These are simple, easy to work with and you don't need to fight an application's feature set and associated 'foibles' when all you want to do is organise and formalise your thoughts.

On the other hand, I often turn to FreeMind when I am trying to 'brainstorm' a presentation or a document or a design/architecture, or…pretty much anything, really.

You don't need gobs of training to use it, it is quick, easy and the end result is immediately clear.

The following diagram shows the early stages of a map about my cat, Furball:

You should be able to get a good 'feel' for what is going on here almost immediately (I challenge anyone to say that about an equivalent UML diagram…if such were to exist).

You can't see it here but one of the major ways in which FreeMind wins is ease of maipulation. It is just so easy to move branches around, reorder things, insert/delete nodes, link related ideas together, categorise concepts, etc.. A few mouse-clicks or drags is usually all it takes. It is not unusual for me to reorganise a given map many times before I get it to "feel right." This freedom to "change the world around" isn't usually available (or not to the same degree) in the more heavyweight tools/techniques.

FreeMind is a great example of free software.

Every team to which I have introduced FreeMind has adopted it with gusto, and I know that it has become a standard tool in the arsenal of many past colleagues.

Add it into your toolkit now.

[edit]
My good friend Dr. Paul King reminded me that Freemind 0.9+ is Groovy-enabled. This is A Good Thing.