Virtual Surreality
It’s too real to be true

My CTO, Rebecca Parsons, announced the publication of the ThoughtWorks Anthology a few days ago:

I am thrilled to announce that the ThoughtWorks Anthology is now ON SALE!

http://www.pragprog.com/titles/twa

There are essays by Roy and Michael Robinson, Martin, Neal Ford, Tiffany Lentz, Stelios Pantazopoulos, Ian Robinson, Erik Doernenburg, Kristan Vingrys and James Bull, as well as ex-TWers Dave Farley, Jeff Bay and Julian Simpson. (And of course your’s truly made her own contribution). Mike Aguilar wrote the introduction.

Some comments that appear in the book:

Jim Fischer writes, “The anthology provides a peek into the diversity of views and perspectives held by a company that dares to take on the long-accepted tenet of the IT industry that custom software is too hard and too costly.”

Big Dave Thomas writes, “Software is in many ways a team sport, and the leaders shape the software culture. Often successful organizations don’t take the time to document them, and hence others don’t benefit from them. This interesting collection of personal essays gives a glimpse into the culture of ThoughtWorks through some of its leaders.”

I’m really excited that this project has come to fruition and I hope you all enjoy what you see.

Rebecca

I was lucky enough to review the content earlier this year. It’s a keeper.

UPDATE: Some press… http://www.sys-con.com/read/541124.htm

After a meeting of the office of the CTO, most of us stayed around in our San Francisco office for a few days to do some podcasts and to participate in a Code Jam for Inveneo, a not-for-profit who provide computers and connectivity to developing countries (especially their schools, hospitals, and poorer villages).

They install a server in, say, a hospital with a few lower-powered, custom desktops (almost iMac in configuration). These, as well as the servers, can run off solar panels for power.

We were presented with a worthwhile problem with a number of interesting constraints:

• Low-power server running Ubuntu, with two small SATA hard disks in a Linux software RAID-1 array
• VMWare images of the servers for testing
• Python, bash, mdadm, and beep as our “programming languages”

When a RAID array fails, we need to alert any (if any) humans who are near the server. This can be interesting as the only things nearby might be the tree it is mounted in with a long-range WiFi, or the goat who uses it as a heat source at night. This means that any alert should be sufficiently frequent and annoying for the locals to contact someone who can let the support technician know. The conflict is that it also might be the nurses in their office at the hospital who have work to do and don’t want to be disturbed.

The solution was to use the PC speaker to beep. We can control the pitch and duration of the beep. Some combinations sounded too much like an ECG machine so that was no good. In the end, we chose a simple rising scale that would sound odd in any environment (except, perhaps, in a Mike Oldfield recording). This is repeated by default every 30 minutes.

We also had to send an email to the support technician. This doesn’t work when the server doesn’t actually have any connectivity (as some are used only as a local communications hub), or when connectivity is unreliable. Even then, many of the technicians are hours or even days away from the servers.

As many of the technicians aren’t particularly technical, we also had help by identifying which of the two disks had failed and allow them to simply change the one labelled “Disk 1″ or “Disk 2″. Serial numbers are good for this but VM hard disks don’t have serial numbers (I think that’s a feature request to both VMWare and Parallels).

We had Jeff Wishnie from Inveneo as the customer, Anda Abramovici as IM, Jonny Leroy as BA, Paul Hammant and Chad Wathington as QA, and the star developer crew of Drew Olson, Sammy Zahabi, Ola Bini, Erik Doernenburg and your’s truly. We quickly learned the following:

• The skills we needed (and had, just a little rusty) were more along the lines of Unix devices, shell, ASCII control characters, and simulation
• Python sucks (a bad tradesman blames his tools? perhaps - but it still sucks)

Anyway, we got most of what we wanted done in the time, and given the context, more than we anticipated. But we all would have liked to get a lot more done and would have if we were using our tools of choice (which are chosen for very good reasons).

Nonetheless, we’re doing it for the kids and it was great!

What a buzz. Super Agile. Super Fun. Go Inveneo, you rock!!

Charles Nutter has just written up a nice summary of the things in Thomas Enebo’s announcement of RC2 of JRuby 1.1

He talks in general about the astoundingly improved performance characteristics, particularly when compared to the Ruby 1.8.6 and 1.9 native interpreters, as well as the better use of JVM resources. Let alone the 260 bug fixes since RC1.

There’ll be more from me soon about our commercial experiences with JRuby and hopefully give you some fuel for introducing Ruby into your large, conservative corporate environment. I have to say, going back 2 years and thinking about the “enterprise readiness” of Ruby, things have changed a lot - almost exclusively due to the work done on JRuby. The pace at which the JRuby team work to address issues and improve the platform is outstanding, and puts commercial software vendors (particularly those hawking development tools) to shame. Things also have a long way to go - there are many, many solutions that would still be recommended around a recent version C# / .NET or Java implementation and that doesn’t look like changing for some time. The team behind JRuby is multi-skilled and very aware of innovations in other languages and platforms and I think this is one of their key success factors.

If you are evenly remotely interested in working on an OSS project, I encourage you to contribute to JRuby, even if it’s just to identify a problem to be fixed - it’s fun, it’s a great community, you’ll learn a lot about Ruby and the JVM, and you’ll work with some of the best guys in the business.

I suppose we Aussies might give up too easily, Ola

Antonio Cangiano let everyone else who isn’t on the list know the disappointing news from earlier this afternoon.

Nonetheless, stalwarts like M. David Peterson (happy birthday!, you’re still younger than me) and Ted Neward (and others who want to see a CLR and/or community-based implementation) may continue the work.

I’m chairing next week’s Ark Group conference on SOA (Achieving Interoperability in Systems Architecture) at the Vibe Hotel in North Sydney, Australia.

You can download the conference brochure here. My ThoughtWorks colleague Halvard Skogsrud and I are presenting the workshop entitled “Bearing the standards of interoperability”.

For a wonderfully concise and lucid synopsis on what you really need to be aiming for while devising an SOA, watch Jim Webber’s InfoQ interview.

He discusses the Agile-hugging benefits of an emergent service ecosystem, provides best practices around building for scalability, highlights what makes RPC (even if you pronounce it “doc/literate”) bad in terms of technical abstractions like types and operations, espouses the simplicity of message-oriented interactions, summarises the features of SSDL (a simpler alternative to WSDL, WS-CDL and WS-BPEL), and touches on the “degenerative” RPC model that is unfortunately being adopted by implementations claiming to be RESTful.

For links to those mentioned in Jim’s interview:

• Savas Parastatidis, the greek geek grid god (PS: Savas, can you confirm my Greek phrase, two posts down?)
• Various SSDL contributors from academia, most of whom have moved on but easily Googled
• Patric Fornasier, SOYA creator and newly joined to ThoughtWorks (woohoo!)
• Mark Baker, the Bob Marley of RESTifarians

…and you’re already at me.

For the Aussies, Halvard Skogsrud and I are presenting a workshop at the October 2008 Ark conference on SOA (Achieving Interoperability in Systems Architecture), which I’m also chairing. Our workshop is entitled “Bearing the standards of interoperability” and, amongst other things, includes some more depth on Jim’s comments around tight coupling, REST, MEST, and “tunneling XML”. There’s some great presentations on the card from credible people, all of whom have real-world experience in forming SOA’s within the corporates and government they are employed by. You can download the conference brochure here. I look forward to seeing you!

This past week, my coworkers Scott Shaw, Evan Bottcher, and Richard Durnall from TW Melbourne, and Gianny Damour from TW Sydney enjoyed our time speaking at the inaugral Australian Archtecture Forum in both Sydney and Melbourne.

The most fabulously contentious talk I attended was a round-table discussion from Gianny on the role of the (software) architect in an Agile project. The quote of the week was “Are you saying architects should be coding? Pig’s arse they should be!”, from my favourite Enterprise Architect in Sydney (Big G from a client). He also rightly quipped that a few months of me helping code on one of his core systems was enough to scare me back into doing EA work!

I discussed Plugin Architectures, spending most of the time on OSGi, and how they could be useful in coming years for incremental deployment (dormant features, production mocks, breaking down monolithic apps). I was surprised to see so many people, figuring it was more to raise awareness, and was delighted to discover 2 projects in Sydney that where heavily component driven with runtime composition. I look forward to hearing more about the day-to-day challenges they face with this interesting and powerful approach.

Evan had a great discussion on different approaches to dealing with legacy applications, encouraging us to not nuke them but to strangle or renovate them. I was asked to give an opinion on how to deal with a VB6 frontend migrating to a web app (no, not Big G’s crowd for those who are reading), and whilst my initial reply was to try the .Net porting tools as a stepping stone and to empathise with the challenge, I also think two more things: if the only reason to change is due to lack of MS support it’s probably not worth doing yet; or it is the ideal opportunity to redevelop from scratch as it is so old the users probably don’t use it like it was built anymore (i.e. it’s a detonate candidate anyway).

Scott talked about dynamic languages in the enterprise and was nicely interleaved with a great Ruby Nubies in our Melbourne office on Thursday night - it was great to see such a diverse crowd with many from the corporate IT space. The talk may have been mostly to the “converted” but it incorporated some of our work over the past 18 months on finding the “enterprise” gaps in RoR and tracking/helping those gaps get closed. We are so close in closing them now I have just started a JRuby project with a long-term client in Sydney. This is a significant event and I look forward to the collaboration with the ThoughtWorks RubyWorks team who have been marvellous in their support. We’re also fortunate enough to be using the single best piece of project software ever released - Mingle!

Richard’s session was totally packed in both cities as he described the way to approach aligning business process, agile requirements, and application architecture. Drawing on his Lean manufacturing experience and sitting right on top of how an SOA should be fabricated, I heard Jim’s voice ringing in my ears “construct your services along business process lines”. Rich is from the black country and Jim is Brummy so the accent is close enough for my upside-down ears. Correction: Jim pointed out my “gross cultural faux pas” in that he, too, is from the black country. Alreet.

On SOA, I hope to have some exciting details about the Ark SOA conference coming soon…

I’ve just read a great post by John Pither, a ThoughtWorks colleage of mine, that helps people think about an SOA through the pub/sub model of the physiological systems in the body. Like many middleware vendors, though, I think he’s missing some important facets of an SOA.

While loosely-coupled components interacting with messages using a (typically) asynchronous event-driven transfer mechanism are an important part of an SOA, it’s not the whole picture. At the least, we also have implementation substitution and recomposability to deal with.

So, perhaps the body’s redundancy of certain functions across organs, and artificial implants could be considered implementation substitution (and even dialysis as “outsourcing”?).

I’m struggling with recomposability - you don’t want the ingestion to occur after the excretion, but I’ve seen some automated systems that are equivalent ;-). Perhaps when considering organs with long-defunct function, the Appendix of the SOA world will one day be bloatware adapters for systems that don’t use interoperable standards.

And on a slight tangent, if you really want to use an ESB - which may actually stand for “Expensive Spaghetti Box” - take a look at Mule first and give it a try ($0).

Java™ isn’t really the success we think it is, you know.

Java programs written the way Gosling et al originally intended would clearly be using the object-oriented paradigm (sure, they’d be applets in a browser, but that’s another story).

What happens when the COBOL crowd (of which I was one) gets their working-storage sections and procedure divisions pulled from under their feet and replaced with interfaces and immutable objects?

What we have, ladies and gentlemen, is a fantastic volume of COBOL programs re-written using Java syntax but with few of those pesky OO semantics.

Look out for RuBOL - the next big thing, where you can MOVE SPACES TO boolean just like in the good ol’ days.

Last weekend a group of antipodean ThoughtWorks blokes (plus Suzie) crashed our Melbourne office for the inaugural Service Oriented Systems Practice workshop.

We had a Saturday full of learning and discussion, the morning sessions being mostly introductory technological concerns, and the afternoon tended towards business problems and commercial practicalities.

I myself (as opposed to you myself) gave a spiel on WS-* for Security, which was basically a cut-down rehash of a lecture I gave at Macquarie University a couple of weeks ago to some luckless post-grads.

One of the “pub discussions” that we haven’t had yet was “YAGNI versus SOA”.

If “you ain’t gonna need it” then why would I be doing the extra work to expose functionality for clients I probably don’t know about and probably never will? When they’ve come to understand that SOA isn’t slapping an EAI/ESB into the mix, organisations seem to suddenly become more reluctant about composable applications and lego-like automated business processes. For them, Tomorrow Never Comes, and Pay Now Or Pay More Later is Someone Else’s Problem.

Fortunately, it looks like I’ll able to explore the realities with a client looking to be truly innovative and really take strategic competitive advantage, so we’ll be able to discover whether there really is a trade-off in doing things a bit smarter now for future adaptability – beyond our well-established simple, easily changed code.