I saw this article at ZDNet (they’ve been ON FIRE lately!) about Facebook and Twitter and how they’re more addictive than alcohol or nicotine. Can that be? It…
Sorry, had to check my twitter. What was I saying? Oh, yeah, Facebook and Twitter are addictive. I know for me that they hardly have any effect on me at all. For example,…
Oh, how funny. Somebody just posted the funniest link on my Facebook Wall. Where was I? Oh, yeah, Facebook. I don’t really check it all that often. I mean, I do have alerts sent directly to my Android phone (same for Twitter). But, really, it just doesn’t mean that much to ….
Wow, it looks like Lance Armstrong will be racing a 70.3 Ironman soon. Just saw a Tweet about it. What was I saying?
Oh, nevermind. I forget. Now if you’ll excuse me, I think I’ll check Twitter. It’s been, like, forever.
Check out this latest Message Board entry at the Java Enterprise Open Source Application Architecture forum I manage at IBM DeveloperWorks!
Join up. It’s free!
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.
Okay, that’s a little dramatic, I admit. But as enterprise architects don’t we need to know what other options our customers and end users are potentially looking at?
I saw this article at Info World, and it made me wonder: is Mono a viable enterprise application platform? Many seem to think it is, but as the article points out, its future is uncertain. Microsoft has committed through its Community Promise not to prosecute anyone who use the ECMA 334 and 335 standards (which define C# and the Common Language Infrastructure – CLI – respectively). So, you’re probably okay to use Mono, for example, without fear of Microsoft claiming patent infringement down the road.
But so what? So let’s suppose Microsoft will play nice (and that’s a potentially big assumption). Is Mono still a viable enterprise application platform?
I have to admit, I really don’t know much about it. Which is why I’m posting this. I would like to hear from you: The experts of Java Enterprise Open Source Application Architecture. Do you know your enemy? I mean, do you know the other enterprise application platforms (including Mono) out there? Should we care?
What do you think?
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.
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?