Over at http://refcardz.dzon … dz/scrum?oid=hom9677.

Now.

This is an interesting one, answered quite thoughtfully.

I recall the sum total of guidance given to me for one (complex J2EE/Spring) project: "Make it Blue."

This one attracted my eye, as well.

Big: Oracle buys Sun.
Sad: Sun and I have a long, happy history together (in the UK, Sun engineers would frequently ring me up and ask for help; I knew a Sun 3/75 from top to bottom [I remember signing an NDA to get a look-see at the board schematics and other such "forbidden fruit"]). I have always regarded Solaris as the one 'true' Unix. Sun has always seemed innovative, young (sometimes immature) and 'cool.' I guess that coolness factor will evaporate now.
Happy: For a long time, it has seemed to me that Sun had lost its way. Now there will be a new pathway opening in front of it. Perhaps that pathway won't be exactly the one it would have chosen for itself, but I am happy that some road remains…

Where now for Solaris?

Seems pretty clear: 'Unbreakable' Solaris, coming soon to a datacentre near you.

Where now for Java?

Ah. Now that is the question as far as I'm concerned, isn't it?

It's a major part of why Oracle wanted Sun…no doubt.

Oracle's (even more than Sun's) early statements of "Use your Java skills everywhere: from Stored Procedures in the database, through the server on to mobile devices." always resonated with me: it made good business sense (and that should tell you what a doomed idea it was…)

Trouble is: history.

At first, Java was a pissy little language. I didn't take it too seriously (didn't stop me making $$$, though!).

Before release 1.1 came along, IBM contributed a big slab of technology and know-how and raised Java up quite a few levels. I saw some of this first-hand. Thus, for the longest time I said: "Java is practically a product of IBM's experience; IBM should buy Java." But over time, they stopped driving (or-more accurately, I guess-were prevented from driving) and so went off to play with Apache and then Eclipse. The end result is a lot of excellent Java-based tools and componentry but not enough at the 'core.'

IBM recently made a few noises but eventually didn't follow though, it seems. Apparently however, they opened the door for Oracle to step through.

Oracle have used Java a lot; their fusion middleware stack, etc. is all Java; they have made some excellent products using Java; they have contributed to JCPs; they have bought other big users. This is all good. But I can't see that they have ever really driven Java.

Stability seems to be what they need and will be aiming at.

Not that there is anything wrong with that.

The question is: what gets dropped?

Take IDEs: Oracle now has the Eclipse-based Workshop, JDeveloper and now Netbeans on its sheet. I was worried about them having two…

Another: JRockit. What is going to happen to the best server-side JVM out there? I was pretty mad at Oracle for restricting access to JRockit after they bought BEA. Now it seems that the JVM pack of cards will be up in the air…

My prediction is that some other pissy little language is going to become "safe harboour" and the industry will run after it like some dumb slathering dog chasing a bone: "Never mind hey! There's another silver bullet in the chamber, let's see what that does!"

A proof of this, I offer SAP.

Seems inevitable, doesn't it.

My vote would go to whitespace. If we're going to throw away all the good stuff that has happened since the late '90s, we may as well really throw it away ;-)

Let's remember the "bad old days" too (not too long ago): when DEC forced BLISS at us, IBM wanted you to use PL/I, Burroughs were the 'Algol' shop, etc. etc. These days persist with all the silly little SQL dialects out there, not to mention Microsoft .Net. Do we really want to return to this? The vendors' natural proclivities are to "lock us in" to their worlds…

http://www.ambysoft. … process/agileUP.html

A simplified, agile-oriented, version of the Rational Unified Process.

If you want something in between XP and traditional RUP, a process that is agile yet explicitly includes activities and artifacts which you're accustomed to, then the AUP is likely for you. Many organizations are leery of XP because it seems to be too light: XP doesn't explicitly show how to create some of the artifacts which management wants to see. This is an unfortunate attitude because XP is a great process. On the other end of the spectrum is RUP, which management seems to love but developers seems leery of due to the large number of artifacts. This is also unfortunate because the RUP has a lot to offer, and can be cut down to something quite useful (which is exactly what IBM Rational recommends you do). The AUP lands between the two, adopting many of the agile techniques of XP and other agile processes yet retaining some of the formality of the RUP.

The AUP isn't for everyone. The AUP is either the best of both worlds or the worst of both worlds, you be the judge.

One second you're sitting back, content with your lot, enjoying the view…

Note that I don't put any qualification on the heading!

Well:

If you're waiting around for users to tell you about problems with your website or application, you're only seeing a tiny fraction of all the problems that are actually occurring. The proverbial tip of the iceberg. Also, if this is the case, I'm sorry to be the one to have to tell you this, but you kind of suck at your job - which is to know more about your application's health than your users do.

This reflects a common battle I have had at several sites. My argument (in compressed format) goes something like this:

Why aren't we telling the users about the state of our systems?
Why do we wait until they report problems to us?
Monitoring software is soooo easy to get or to build; plop a few biiig plasma screens around in well-frequented places; put websites up; put widgets on the intranet home page.
We could be advertising our server statuses, we could be identifying scheduled downtimes.
If we do this, the users aren't surprised; they won't start filing bugs when they can see a scheduled outage.
"What gets measured, gets optimised": if we do this, we can start tracking system reliability, and planning. We'll have some figures and history to use to help us kill off unreliable hardware, to maintain critical software, fix high-profile problems.
"What gets measured, gets optimised": if we do this we will find that it's easier to ask for resources to fix a problem when the problem is clear, rather than beeing a 'feeling.'
"What gets measured, gets optimised": if we do this will we look bad? Perhaps intially, yes. But we'll (have to) improve.
"What gets measured, gets optimised": if we do this, we will be 'proactively' driving improvement.

(I hate the word 'proactively' but sometimes one has to talk to the enemy in terms they understand…:-))

I really like the Agile term "Information Radiator"…sums up the activity and the aim perfectly.

Agilists typically (but not exclusively) talk about raidating information relevant to their development activities and team. The bee in my bonnet here is that we should think about radiating information at all stages.

Sadly, my arguments always fall on deaf ears. I wonder why…

Is it me?

Is it $$$?

My guess is that is it fear…fear of being somehow "caught out."

(I'll probably have more to say on the topic of fear, later.)

So why didn't I qualify the heading? Because I am taking the huge leap here and guessing-no: predicting-that your team doesn't advertise itself to its clients properly either.

It's time to change the world…this little aspect of it, anyway.

Grails And Git QuickCast

A short (11 minute) video demonstrating how Grails and Git can work together to support a really agile development process.

I don't normally like watching video training ("where's that damnned fast forward"?) but this is about right.

Nice, quick overview. Very good graphics: Scrum in 5 Minutes.

If there is one picture to illustrate the Scrum process that your should put into the your mind of your manager, it may well be this:

(from: http://www.softhouse … all=1&parent=10)

All the basics are there…ready to be talked about and chewed over.