What’s Going on With Android?

Once again, Microsoft is stifling innovation. They have a long, dark track record of using economic and/or legal means to squash innovation. Check out this list of companies Microsoft has purchased. My buddies and I used to call them “Microsquash” (I’m not trying to claim we coined the term, but it is certainly indicative of their strategy for dealing with superior competing technologies) because every time someone came along with a better idea, Microsoft would buy them and either squash the technology altogether or morph it into some completely useless Microsoft offering (Internet Explorer?).

It appears that Android is just too good an idea. So now Microsoft has made bedfellows with Apple, RIM and others in some sort of unholy corsortium to buy up patents from bankrupt Nortel in an attempt to kill Android. Of course, that would be mean (and illegal), so they’re not admitting that’s what they’re doing. But, of course, that’s what they’re doing. And Apple is in on it.

Now, I have an iPhone. And I love it. But seeing Apple’s part in this clearly underhanded strategy indicates to me just how good Android probably is. Everyone I know who has an Android loves it. “From my cold dead hands,” I tell them in a mocking reference to Moses’, I mean, Heston’s NRA rant from years ago, “I’ll never give up my iPhone.” I’m rethinking that.

See, Apple has always competed based on having a superior product. They haven’t (too my knowledge) had to resort to underhanded means such as these to kill their competitors. Now that they are, I’m considering getting an Android.

In any event, Anti-Trust investigators are unswayed and are launching an investigation into this. At the very least, Google will be allowed to license the technology. But I hope this unholy union is busted. Killing the competition because they’re better? I expect that from Microsoft, but Apple? Hm.


Is Better Really the Enemy of the Good?

I see this all the time in IT: the lead architect(s) puts together a process, everybody meets to discuss it (multiple times if necessary), the process is thoroughly documented and the team follows it in their day-to-day activities.

Until one of the development team (usually alone and on the weekend) decides that this step (or that) doesn’t make sense here, and in that vacuum breaks the process. When everyone comes in Monday morning, things don’t work like they should, or artifacts can’t be found. Basically, something just isn’t right.

I understand the need for innovation. Sometimes I need to have my cheese moved to shake me out of complacency, or poor work habits. But, when a lone developer (or project manager, or business analyst, or…) decides – alone – to change the process that multiple people depend on, it just leads to project breakdown.

And, yes, this happened to me recently. This kind of thing drives me nuts. If the process is broken, let’s meet to discuss it, and fix it if necessary. In this case, it wasn’t a terribly big deal. I couldn’t locate code I needed to review because the commit comment was not of the standard form, and the commits didn’t come from the correct release branch. We got it worked out, but it started my thought process: why do developers do this?

I know the answer of course: to make it better. But to make something better generally requires a consensus. In this case, the well-meaning developer broke the process, rather than making it better. As I gently reminded him that with the number of people on this project we need to follow the process, or things get confusing he kept saying, “I was trying to do a good thing, and you’re jumping all over me!” It’s not easy being the gatekeeper sometimes, but it makes for great fodder for this forum.

What do you think? Do you run into this? I’d love to hear from you.


“Um, glad we did not step in it!”

I had a real Cheech and Chong moment with this one. Ahem, here goes…

I saw this article at InfoWorld where they interview Roger Sessions, CTO of ObjectWatch. Sessions claims that complex systems are not typically built correctly, and the bigger (more complex) they are, the more likely they are to fail.

Now what I find most interesting isn’t this startlingly obvious point, but that the definition of “complexity” in his examples (all of them that I could tell) is based on project cost, not other metrics such as, say, number of lines of code. The problem, Sessions continues, is that we are using technological approaches like SOA that are inherently mathematical, but we’re not doing the math very well. We just don’t find that sweet spot between complexity and functionality. And breaking the systems down into smaller components won’t help, he says, because as the number of components increases, the number of inter-component dependencies increases accordingly, and you have no net gain. In short, there’s no way to win.

However, through his patented Simple Iterative Partitions (SIP) technology, he can find the perfect balance between complexity and functionality. Your projects are now safe. Nothing to see here. Just hire Object Watch and all will be well. No more huge failures (or at least fewer of them).

Since the “complexity” of a project is its cost, Object Watch doesn’t waste time with the small projects. The genius of the the-bigger-your-project-is-the-more-you-really-really-need-us approach is that it’s not insulting to the small projects (“Hey, you don’t need us, you’re more likely to succeed by virtue of your small cost, er, size!”), and has the scare factor that makes big companies open their wallets.

This sales pitch has a familiar aroma to it.

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


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.

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.


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.