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. 🙂

–jsp

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.

–jsp

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?

–jsp

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.

The Future of Java?

This is a heavy topic for a Monday, but this article at TheServerSide.com really caught my attention. Joe Ottinger succinctly lays out the options for Java, and frankly, I’m concerned.

Mostly that I’m just now concerned. Well, I’ve known for some time that Java’s future may have been in doubt. IBM wanted to buy Sun (yay!). Then Oracle bought Sun (ooh, what does that mean for Java?). But I was a corporate employee for a long time, so I’m used to the there-are-big-changes-going-on-what-does-that-do-to-my-job sort of feeling in the pit of my stomach as I lie in bed at night.

So what is going to happen to Java? Joe says there are four options:

  1. Keep it like it is (status quo)
  2. Forking Java to create a new thing (though, isn’t there already Ruby? Python?)
  3. Creating a truly independent consortium (yeah, right)
  4. Abandon it

Honestly, I’m a status quo kind of guy, so I like that option. But if there’s one thing I’ve learned in IT, it’s that the status quo is change. Lots of change.

Does that hold true for Java? If so, what does its future hold?

I want to hear what you think.

–jsp

Open Source: Where’s the Money?

Having bills to pay and stuff, I sometimes wonder where my next invoice (or paycheck when I was an employee) is coming from. Using Open Source software is a cornerstone of my consulting practice, so I also think about Open Source software. Today, I’m thinking about both.

So, I’m wondering: where’s the money in Open Source software? This article from Business Week (it’s a couple of years old) says the model is broken. That is, selling services and support around Open Source software is not working for many companies who try it, so the model is broken. I would argue that’s a little like saying, “The business model of computer manufacturing is broken… see how few companies can make a profit doing it?” The premise that because few companies succeed doing a thing, that the thing is flawed is, well, kinda stupid.

But that raises an interesting question. Even though the premise of the article is flawed, is there really money in services and support? Some companies do succeed at it. Look at Red Hat, JBoss or Canonical. And if you want a bunch of information about the Open Source Business Model, check out this link.

Personally I believe that our industry will evolve into a model that looks much like the service industry for, say, plumbing supplies. I mean, there are a handful of companies that make pipes and fittings (and I don’t know the name of a single one off the top of my head) but I can look in the phone book and choose from dozens of plumbers. Meaning, one day there will be a handful of companies that “manufacture” software, and the rest of us will be involved in using it to solve business problems (imagine that) and fixing it when it breaks. We’ll be integrators. Software Plumbers.

To sum up, I believe that software development will morph into software solutions, which is inherently service based. So in my opinion, the money is in the services. Red Hat and other companies that are using a services model around free software are getting it right. Just because everybody out there that tries can’t make it profitable doesn’t mean the model is flawed.

What do you think?

–jsp

Fluffy Little (Not-So-Secure?) Clouds…

I’m reminded of a time back around 1999 or 2000. Yes, it was a simpler time. A time when we suspected there was no money in most .com companies, and laughed at headlines like “There’s no business like no business”.

So, what has me walking down memory lane? I saw this article on cloud computing concerns from Information Week. Seems like, while 9/10 companies have concerns about security when in the Cloud, they do it anyway.

Why do I hate Cloud Computing so much? I’m not really sure, but stuff like this doesn’t help.

What do you think?

–jsp

What’s that SmEll(ison)?

So, I’m working away, thinking my little programmer thoughts, when I notice I have a Java update available for the Winblows box that I’m forced to use while on-site at this particular customer location (to do email, Office and SharePoint, ostensibly). I love Java, so I’m all, “Sure, dude, let’s spin that up!”

The update has just begun when I run across a message that – unless I uncheck the “Ooo, I’d love to install this unknown product” box – will install something called Carbonite. Apparently it’s a backup utility, and applying the Java update by default (meaning you blast through the install and don’t bother to read every screen) installs a 30 day trial of this product. I’m sure it’s a fine product (see what I just did there? I’m practicing in case I ever decide to go into politics), but NO THANKS. Oh, and I’m equally sure it’s a snap to uninstall (I just did it again there).

Now that Oracle owns Java, is this the sort of thing we can expect?

In case you’re wondering, I did NOT install the update. The whole thing is rather irritating.

OpenID for Java Web Developers

I’ve been thinking about OpenID a lot lately. Probably since around October of 2009. On my current engagement, my customer uses OpenID to enable Single Signon (SSO) for their partner applications. There is an implicit trust between them because of their business relationship, so they include links to their partners’ applications from their own applications as a convenience. The problem (before OpenID) was that each time their users accessed their partner’s application through one of these links the user was forced to sign in. A SSO solution was necessary, and OpenID was the solution. Through OpenID, my customer’s application acts as the OpenID provider (OP) and the partner applications are the relying parties (RPs). It works like a dream.

Now, I didn’t architect the OpenID solution. My colleague Oscar Pearce did, and did a great job of implementing it. He has since moved on to other things, and in October 2009 my customer asked me to help another one of their partners to OpenID-enable their application. My journey into OpenID land thus began.

At first I didn’t really understand OpenID (and to be honest, didn’t really like it). But it began to grow on me as I began to get what it was all about (funny how that happens). Slowly it started to gel, and I realized there are two main pieces to understand when using OpenID in this type of architecture (i.e., as a SSO solution):

  1. The Relying Party (RP) code and surrounding issues
  2. How to write the OpenID Server for the OpenID Provider (OP)

I love to write. It’s what I do. So I began thinking of ways to share this knowledge with the IT community. I pitched the idea to Jenni Aloi at IBM Developer Works, she liked it, and Part I (the RP stuff) is now available for your reading pleasure. You can find the article here.

I’m working on Part II (the OP stuff) now. Stay tuned. And please let me know what you think. I really like OpenID. It’s gaining momentum as an identity management solution. Check out My OpenID to see one of the largest OPs on the planet, or OpenID.net for the specs, etc.

Have fun.