My first thought was: What do you mean, code is not your friend?
Might this compendium of blogs be IBM putting some some distance between its own approach and Microsoft People Ready? I thought I would Google the phrase, and there is an explanation. The tagline for IBM’s architect central comes from a blog post by Marc Colan.
The reason for SOA is to build change into your design, to take a proactive approach that allows IT flexibility to support changing business and technical needs. That’s the whole point of using loose coupling: to avoid rigid infrastructures. Point-to-point brings back rigid infrastructures. ESB enables adaptive infrastructures and adds a lot of valuable capabilities.
And sure, you could write code that does all of this and more. But code is not your friend: the more you have, the more maintenance costs, the more complexity is a problem. That’s why using supported middleware to simplify your IT makes financial and practical sense. [italics mine]
I am good with everything until the final statement, which I don’t think follows. Surely lesscode should mean using tools that do indeed rely on less code, that are built using lesscode? Just because middleware is "supported" doesn’t mean it is low maintenance: that is an assumption, not a conclusion.
On the contrary – complexity is a key issue for Software Group, as aknowledged by Don Ferguson here. Judging by his post on the subject however, I am not sure Don got the memo.
It is really important that IBM’s architecture visionaries internalise some thinking about simplicity. Simplicity is not a spontaneous emergent function of abstraction. Abstraction doesn’t create simplicity, it often just hides complexity. Hiding complexity can be a good thing, certainly, but its also good to try and drive it out where possible.
Why is it important that IBM continue more aggressively down the road to lesscode, with better installation mechanisms, more effective default configurations, and "less function meaning good" codebases? Well, for one thing, the key FUD message from pretty much every IBM Software Group competitor is that WebSphere and other IBM tools are hard to configure and manage, and require "support", from IBM, in the shape of armies of technical consultants to install and maintain the software. The "IBM Services Tax".
Grassroots developers meanwhile can smell complexity from a download away, they can smell it wafting over that little wall called developerworks registration. I appreciate that IBM supports legacy environments with religious zeal, which is one of the reasons it is a great company. But most developers dont want to deal with other people’s cruft – they don’t even want to deal with their own cruft… and developers choose platforms.
Lesscode, as Marc Colan seemingly understands, leads to lessconfig, which is where real economic savings come in. "Code is not your friend": I wonder what IBM’s Sam Ruby or 37Signals David Heinemeier Hannson make of the idea? Perhaps the real answer is to choose your friends more carefully. How much has really changed since Business 2.0 wrote this piece three years ago, other than Oracle acquiring key application partners?
IBM is making some substantive moves towards lesscode and lessconfig – as the work of people such as the aforementioned Mr Ruby, Rod Smith (why doesn’t Rod have a blog, he’d be a must read?) and the Jazz team makes clear. IBM is getting it in patches and in many areas doing great work. I still think Software Group needs more design and less architecture though. Harsher editing is required.
Note then to Software Group: like you say, code is not your friend.
disclaimer: IBM Software Group is a RedMonk client.
Bill Higgins says:
March 29, 2006 at 1:42 pm
The lesscode virus is spreading in Software Group, I can tell you that. You guys (RedMonk) and Ryan and the lesscode.org were key to my conversion 🙂
Just remember that Software Group is big, and there are a lot of smart folks who are not all looking to be converted. And Don’s about as high up as you can get on the technical food chain, and it seems like the lesscode meme is advancing from below.
PS – Re: Rod Smith blogging. I asked this same question and if I remember the answer was what you’d expect: “too busy”.
Sam Ruby says:
March 29, 2006 at 3:03 pm
Thanks for the kind words.
I think that the first three paragraphs from Tim O’Reilly’s Inventing the Future apply here.
Re: “too busy”; blogging is simply email, cc:world. I’d *love* to see Rod blog.
Donald Ferguson says:
March 30, 2006 at 11:33 pm
The “less code” and “simpler” memo is not advancing from below. A lot of us have been pushing and driving less code, simple, … … for a long time. I have been a zealot on this topic within IBM. So have others high on the food chain. I can produce witnesses.
Why have other IBMers been talking about this and not me? I did not know anyone read my blog. I also did not know there was a food chain. Finding this out at dinner time (which is when I am writing this) is probably not good for people in IBM. I just need to make sure I do not eat the witnesses.
The phrase “Judging by his post on the subject however, I am not sure Don got the memo” was snide and condescending. Previously, Adam Bosworth once wrote, “Don Ferguson of IBM builds edifices of such sophistication and elaboration as to daunt the designers of the extraordinary archways of the Alhambra. Adam also said that I was much smarter than he, which was clearly a way of saying I was not.
The Internet, and its pioneers and visionaries have broght tremendous benefits to the world. It would be a pity if the price of these benefits is the loss of civil discourse.
I would also like to point out the the Alhambra’s elegance relies on composition of simple, fundamental elements. It is also a UNESCO World Heritage Site.
I will respond on my blog tonight. I am tired, have had one of those days and have not eaten all day. I was busy making things complex and need to go eat dinner. Sam Ruby looks pretty tasty, and I have Tabasco Sauce.
Donald Ferguson says:
March 31, 2006 at 12:47 am
I probably did not get the memo. I am famously clueless.
This is the second time someone on the Web has insinuated that I make things too complex. Moreover, both bloggers were sarcastic, bordering on snide. Let’s avoid ad hominem comments.
When I brief customers, I begin by saying, “If things seem complex, it is me.” I used to think I understood a lot of stuff and only had an hour to present. So, things appeared confusing. My daughter told me I am just confusing. Period.
Less code is good. A colleague once said to me, “It is very hard to make software simpler by adding more software.” He is right. I keep phrases in my mind to help me remember and focus; this is one. (Another one is, “No thank you. I prefer not to sit on the bear,” but that is for another day).
Consider a scenario in which an enterprise wants to adapt/extend three existing applications, make them available over a messaging system, build a couple of workflow processes and make the processes available through a GUI. Companies do need to do things like this. The number of lines of IBM product code that supports this scenario has decreased by a factor of at least in the past five years. That is a fact. I can prove it. I have witnesses. I became an IBM Fellow and SWG Chief Architect about five years ago. Draw your own conclusions. We delivered. Clearly I did not do this all by myself. SWG’s team did. This started five years before the “memo.”
We will make things even simpler. We will also not lose our ability to solve real problems. Our middleware and tools are number one in almost all markets in which we compete. Our share grows. Customers vote with their money. They clearly do not give us the money because they read my blog.
I am not naive. We are not perfect. We have a lot to do. People who know me, including customers, know that I speak plainly. I honor my committments. I promise that I will continue to drive simplicity, reduction and fit to finish. When you want to solve a problem, you will get the minimum you want and need. Everyone in the food chain in IBM is driving this agenda. We will let people solve real problems with the simplest SW and tools possible. Period.
If anyone wants to talk to me about the ideas, let me know. I like doing this in person, if possible. I do not like blogging. It is not because I do not have the time or “do not get the Web.” [b]I don’t like talking[/b]. My nickname in college was “Silent Don.” I am from rural New England. This blog used all my words for the next three days.
Calvin “Silent Cal” Coolidge was also from rural New England. A newspaper reporter was going to the White House for a state dinner. She bet her editor that she could get Silent Cal to say more than three words to her at dinner. At dinner, she charmingly told the situation to Silent Cal. His response. “You lose.” My hero.
Sam Ruby says:
March 31, 2006 at 10:18 am
Silent Don Speaks
I remember a meeting in Austin, TX a few years back in which there were perhaps 80 or so people in a long and narrow room. Don positioned his chair sideways on the narrow edge nearest the door. At one point, he had something to add. As he began to
Kurt Cagle says:
March 31, 2006 at 4:41 pm
James,
I think your article is spot-on here in a number of ways. I think that the idea that less code (fewer lines of code) is any better a metric for the complexity of software as more lines of code is a metric for quality is ludicrous.
More lines of code DO introduce the chance for more points of error – no real surprise there – but complexity management is a matter of effective design. A good systems architect can recognize the points where complexity is unavoidable and can shunt it off into modules that can be effectively built and maintained by those coders whose job it is to deal with the particular type of complexity, making the rest of the application (the UI, the configuration, the maintenance story) appear simple and self-contained.
My only quibble here with your post (and its a minor one) is the line:
“I still think Software Group needs more design and less architecture though.”
The job of an architect is to BE that designer, otherwise the architect is simply a better paid (hah!) programmer. I’ve seen all too many “architects” who are actually in the latter role, but have the architect position because it sounds cooler than “programmer”, but the role of the architect is to identify those points of complexity and then design the application in such a way that they can control and corral the complexity in a manageable fashion.
— Kurt Cagle