Meanwhile, Back at the Cloud Alliance…

I’m staying away from Cloud Computing for now. But sometimes I wonder if I’m making the right decision, or if I should just get my head in the Cloud. Especially after I see articles like this one in InformationWeek Online.

It describes an alliance of vendors (so far so good) called the Open Data Alliance for Cloud Users, who are getting together under the guidance of Intel (um, okay, go on) to discuss standards for interoperability.

So, let me get this straight. A bunch of companies (among whom are Deutsches Bank, UBS and JP Morgan) are going to get together and figure out how to interoperate? Holy CORBA, Batman, I think this is really gonna work!

Okay, I’m a skeptic (you may have picked up on that). When I see stuff like this I start thinking, “Okay, what’s up?” As in, “What’s REALLY up?” I have no idea. I’m just gonna go back to my cube and write some Java code. Forget I brought it up. 🙂


Note: you can also read this post here.

IBM + Oracle + OpenJDK = ?

Alright, campers. Math quiz. Take IBM add Oracle plus OpenJDK and what do you have?

Give up? Well, according to this press release from Oracle you have Innovation. I like innovation. It got us out of the caves, gave us agriculture and the iPhone. I don’t use OpenJDK, but not because it’s not super cool, but just, well, because. I mean the JDK is so easy to download, install, use.

But will that be the case going forward? Is OpenJDK going to be the JDK replacement? Maybe replacement is the wrong word. But will what we call the JDK today morph into OpenJDK?

Should I care? I mean, Mark Reinhold seems excited about this.

What do you think?


Different is Good (right?)

I keep seeing that word: process (or sometimes, processes) . This time it’s in an article from InformationWeek, talking about the top 5 trends in IT in the coming year. Number one on the list is innovation, which the article’s author argues may have never left, but what is different this time around is that “some companies are attempting to codify the processes through which innovation can be nurtured.”

Granted, this is more of a business-focused article, but the word keeps popping up. I wonder if even the business types aren’t seeing the value of doing things differently, rather than just doing different things.

So is there value in doing things a different way (i.e., making the process better)? Or should we all just work harder? Do more with less? Rightsize it? Focus on our key competencies to leverage synergies within and among multiple business units to maximize shareholder value?

(Wow, my gibberish spewing machine really kicked into overdrive on that last one.)

What do you think?


I’m Going Deep!

I can’t seem to shut this thing off between my ears, and so today I started thinking about rules, which triggered some thoughts of using a production system (CLIPS in this case) on a Telecom project I was involved with a few years back. See, I really like to understand things at a deep level. So, I’m dusting off my understanding of the Rete algorithm, which forms the basis of production systems. Suddenly I thought, “Do I really need to understand rules at this (the algorithm) level to be an effective architect?”

I’m sure some (if not all) of you know what I mean about wanting to dive down DEEP into the “thing” we’re looking into. And my question isn’t, “Does that help us be effective architects?” but rather “Does that hurt our effectiveness as architects?”

We all have a finite amount of time to devote to putting an architecture together. So how are we spending that time? I find myself resisting the urge these days to go deep into a subject so that I can look at the overall picture. This means, basically, I have to trust that the intellectual investment in the widget I’m looking at gets the job done.

Or does it? Am I copping out? Or do we reduce our effectiveness as architects by trying to go too deep into every component?

What do you think? I’d love to hear from you. C’mon, post a reply. I won’t mind. 🙂


What the Mayans Needed: Joda Time!

I ran across this article on Yahoo! News and it got me to thinking about Dates (mostly how JDK Date sucks), and their place in applications. My little stroll down memory lane included the super-high consulting fees of pre-Y2K days (I wasn’t yet a consultant back in ’97-’99). What’s a couple of digits gonna hurt? Not much as it turned out (mostly because – I believe – that the code most likely to blow chunks was cleaned up ahead of time).

No doubt about it: dates and date calculations are important in enterprise applications. And Joda-Time is a great library for Java applications. I never miss an opportunity to plug Joda-Time, or the IBM Developer Works article I wrote on it.

What do you think? Talk to me.


Great Developers, Mediocre Dev Process – OR- Mediocre Developers, Great Dev Process

Okay, this topic may be a little heavy for a Monday, but it’s been on my mind lately. I’ve designed a number of Development Processes over the course of my career, and there’s one thing I’ve noticed about them: the majority of great developers won’t follow any process they didn’t come up with. And usually the process they follow is in their heads (read that: undocumented) and is not always consistent. But mediocre developers are happy to follow a process if it makes their job easier to do (the exception is the mediocre developer who thinks he/she is a great developer…. they don’t follow any process or listen to anyone).

So, my question is: would you rather have a team of great developers who follow a crummy process (which may mean “no process at all”), or a team of mediocre developers who follow a well-designed, repeatable process with well-defined milestones, deliverables and job functions?

You may be able to guess my answer, but I’ll bore you with it anyway. I’d take the mediocre developers any day. Any day. We’ve all heard the term “herding cats” which is usually how software project managers lament having to work with software developers. Of course, none of us wants to think that we’re difficult to work with (it’s always that other guy who’s difficult to work with… I mean, if he’d just do it MY way, everything would be okay… sound familiar?). But the truth is, the better we are at slinging code, the more difficult – in general – we are to work with. Why? Because (a) we know we’re good at what we do, (b) we don’t like to be told what to do, and (c) (now this one’s gonna hurt) we don’t work well with others.

The solution? Hire crummy developers, train them to write code the way you want it written and make them follow a well-defined process. I’ve worked for two companies that did just that: they created coding standards and had training classes, and smooth development and environment migration processes that were enforced. Both of these demanded repeatability, and for years these companies were extremely profitable. I also watched them decline as client/server gave way to younger developers (yes, I was one of them), who resisted any type of process, which caused communication breakdowns, and the like. These companies both struggle today. I don’t blame the lack of process, but I believe it didn’t help.

Look at modern engineering. If you wonder how a bunch of people whose educational (or citizenship) credentials are in doubt can build a bridge that stands for decades, I argue it’s because of great engineering and great *development processes*. I mean, if we built bridges the way we build software, I’d be afraid to leave town. Seriously.

So what is my point? I suppose it’s this: given the choice between herding cats or sheep, I’ll take the sheep. They do what their told, they’ll follow the process, and well, I really don’t like cats.

What do you think?


Software Plumber?

Okay, both of you who read this blog know that I believe that the software industry will be transformed at some point to a model similar to that of the manufacturing industry. That is, fewer companies will build software and most people in IT will make their living installing and supporting that software (and training others how to install and support software). One of my colleagues, Shawn McKinney (a Paragon of Security knowledge, keeper of the sacred keys), brought up a good point in this thread at IBM’s My Developer Works, on the Java Enterprise Open Source Application Architecture Group. Here’s my reply:

I think the whole software sales model is a good one. The problem is that the companies that sell the software are the same ones who support it. Who better to support the software than the people who wrote it, right? Well, that argument works for anyone who hasn’t called a software support help desk. There the problems begin.

See, companies that are good at writing software aren’t always good at doing support. So, that do they do? They hire people making $10/hour (or less), reading from a script, that have no idea how to solve your problem, because by the time the help desk people have enough experience to be helpful, they get hired away to another company (etc.).
It seems like nobody has figured this out, and I think the reason is that the people who write the checks for software licenses (and support agreements) aren’t the ones who actually have to call the help desk when the app is in the ditch. I think the industry figured this out with manufacturing and up sprang a whole group of people who are great at supporting the manufactured-thing when it breaks.

For better or worse (or lower revenues), I believe the services-model is inevitable. It’s a game of musical chairs, my friend, fewer companies will be building widgets and more people will be putting them together. The question is, where do you want to be when the music stops?

Interested in joining IBM My DeveloperWorks? Click here to register, and as soon as you register, click here to join the Java Enterprise Open Source Application Architecture Group.

Carry on.