They’re also having a special limited-time sale on their Mac and PC base packages and upgrades. Check it out!
Saturday, August 21, 2010
Logos Bible Software 4 Mac Launch!
Sunday, May 03, 2009
Thoughts on the next Supreme Court Justice
President Obama made some remarks on the announcement of Supreme Court Justice Souter's retirement. I was most interested in what he said about what he's looking for in the person to replace Justice Souter. Here's an excerpt of his remarks during a press conference on 1 May 2009:
"Now, the process of selecting someone to replace Justice Souter is among my most serious responsibilities as President. So I will seek somebody with a sharp and independent mind and a record of excellence and integrity. I will seek someone who understands that justice isn't about some abstract legal theory or footnote in a case book. It is also about how our laws affect the daily realities of people's lives -- whether they can make a living and care for their families; whether they feel safe in their homes and welcome in their own nation.
I view that quality of empathy, of understanding and identifying with people's hopes and struggles as an essential ingredient for arriving as just decisions and outcomes. I will seek somebody who is dedicated to the rule of law, who honors our constitutional traditions, who respects the integrity of the judicial process and the appropriate limits of the judicial role. I will seek somebody who shares my respect for constitutional values on which this nation was founded, and who brings a thoughtful understanding of how to apply them in our time." (emphasis mine)
I generally like the sentiment here, but I'm not exactly sure how President Obama will find someone with these qualifications. Much has been recorded about Obama's thoughts on Supreme Court nominees which I won't go into here. But still, there is something about this that bothers me, but I can't put my finger on it.
President Obama's comments made me remember some of what God says about what he wants to see in people (not just Supreme Court nominees):
"Thus says the Lord: 'Let not the wise man boast in his wisdom, let not the mighty man boast in his might, let not the rich man boast in his riches, but let him who boasts boast in this, that he understands and knows me, that I am the Lord who practices steadfast love, justice, and righteousness in the earth. For in these things I delight, declares the Lord.'" -- Jeremiah 9:23-24
"He has told you, O man, what is good; and what does the Lord require of you but to do justice, and to love kindness, and to walk humbly with your God?" -- Micah 6:8
"Woe to you, scribes and Pharisees, hypocrites! For you tithe mint and dill and cumin, and have neglected the weightier matters of the law: justice and mercy and faithfulness. These you ought to have done, without neglecting the others." -- Matthew 23:23
To sum up, God most highly values knowing him, walking humbly with him, practicing love, justice, righteousness, kindness, mercy, and faithfulness.
Now that's what I'm looking for in the next Supreme Court nominee.
"Now, the process of selecting someone to replace Justice Souter is among my most serious responsibilities as President. So I will seek somebody with a sharp and independent mind and a record of excellence and integrity. I will seek someone who understands that justice isn't about some abstract legal theory or footnote in a case book. It is also about how our laws affect the daily realities of people's lives -- whether they can make a living and care for their families; whether they feel safe in their homes and welcome in their own nation.
I view that quality of empathy, of understanding and identifying with people's hopes and struggles as an essential ingredient for arriving as just decisions and outcomes. I will seek somebody who is dedicated to the rule of law, who honors our constitutional traditions, who respects the integrity of the judicial process and the appropriate limits of the judicial role. I will seek somebody who shares my respect for constitutional values on which this nation was founded, and who brings a thoughtful understanding of how to apply them in our time." (emphasis mine)
I generally like the sentiment here, but I'm not exactly sure how President Obama will find someone with these qualifications. Much has been recorded about Obama's thoughts on Supreme Court nominees which I won't go into here. But still, there is something about this that bothers me, but I can't put my finger on it.
President Obama's comments made me remember some of what God says about what he wants to see in people (not just Supreme Court nominees):
"Thus says the Lord: 'Let not the wise man boast in his wisdom, let not the mighty man boast in his might, let not the rich man boast in his riches, but let him who boasts boast in this, that he understands and knows me, that I am the Lord who practices steadfast love, justice, and righteousness in the earth. For in these things I delight, declares the Lord.'" -- Jeremiah 9:23-24
"He has told you, O man, what is good; and what does the Lord require of you but to do justice, and to love kindness, and to walk humbly with your God?" -- Micah 6:8
"Woe to you, scribes and Pharisees, hypocrites! For you tithe mint and dill and cumin, and have neglected the weightier matters of the law: justice and mercy and faithfulness. These you ought to have done, without neglecting the others." -- Matthew 23:23
To sum up, God most highly values knowing him, walking humbly with him, practicing love, justice, righteousness, kindness, mercy, and faithfulness.
Now that's what I'm looking for in the next Supreme Court nominee.
Tuesday, February 03, 2009
Tuesday, January 20, 2009
Why Do The Nations Rage?
Why do the nations rage
and the peoples plot in vain?
The kings of the earth set themselves,
and the rulers take counsel together,
against the Lord and against his anointed, saying,
Let us burst their bonds apart
and cast away their cords from us.
The 15 December 2008 edition of Newsweek magazine carried a cover essay entitled "Our Mutual Joy", and subtitled "The Religious Case for Gay Marriage". That title really caught my attention, and that of many others too, as it has stirred up anew a heated debate between advocates of so-called "gay marriage" and Bible-believing Christians.
He who sits in the heavens laughs;
the Lord holds them in derision.
The cover essay was written by Lisa Miller. It got me so worked up, I wrote and posted a paragraph-by-paragraph response to "Our Mutual Joy". The bottom line is that you just can't make the Scriptures support such an idea. In fact, the very notion of "gay marriage" is an oxymoron. Homosexual practices are universally condemned, first in the Old Testament and subsequently reaffirmed in the teaching of Jesus and other New Testament writers.
Then he will speak to them in his wrath,
and terrify them in his fury, saying,
As for me, I have set my King
on Zion, my holy hill.
Worse than the cover story itself was the introduction to it by the Newsweek editor, John Meacham. I also wrote and posted a paragraph-by-paragraph response to "The Editor's Desk". I say that it's worse because he not only endorses the conclusions of Lisa Miller's story, but says "this conservative resort to biblical authority is the worst kind of fundamentalism," and "to argue that something is so because it is in the Bile is more than intellectually bankrupt - it is unserious, and unworthy of the great Judeo-Christian tradition." Say what? It is nearly unbelievable to me that a respected journalist could print such an asinine remark. He doesn't seem to understand anything about what real Christians believe and why they believe it.
I will tell of the decree:
The Lord said to me, You are my Son;
today I have begotten you.
Ask of me, and I will make the nations your heritage,
and the ends of the earth your possession.
You shall break them with a rod of iron
and dash them in pieces like a potter's vessel.
To make the whole thing even worse, in the following issue of Newsweek (22 December 2008), in the section called "The Popularity Index", a comment on "Our Mutual Joy" said: "The Bible is the basis for much opposition to gay marriage. But Scripture does not proscribe it." Outrageous! First they publish an essay chock-full of bad scholarship, the editor endorses it with his own poor understanding, and then they have the gall to basically declare God is OK with it! God save us.
Now therefore, O kings, be wise;
be warned, O rulers of the earth.
Serve the Lord with fear,
and rejoice with trembling.
Kiss the Son,
lest he be angry, and you perish in the way,
for his wrath is quickly kindled.
Blessed are all who take refuge in him.
-- Psalm 2 (ESV)
It's hard to know how to conclude this. I feel outraged that people have (mis)used God's word, which is precious to me, to try to justify abominable behavior. This is just my way of trying to think through the whole thing, and provide a reasonable response. May God grant readers of these articles to see the truth.
Scripture quotations are from The Holy Bible, English Standard Version (ESV), copyright 2001 by Crossway Bibles, a publishing ministry of Good News Publishers. Used by permission. All rights reserved.
Tuesday, September 02, 2008
Google Chrome Comic
Everybody's buzzing about the new open-source browser, Google Chrome, but the best part about the announcement is the comic!
J.A.W.
J.A.W.
Sunday, July 13, 2008
Alaska Highlights Video
We just got back from a great Alaska cruise. For our family and friends, here are some highlights in a short video:
More pictures will be uploaded to my Flickr account later.
Enjoy!
J.A.W.
More pictures will be uploaded to my Flickr account later.
Enjoy!
J.A.W.
Tuesday, April 29, 2008
I'm Not Alone!
For designing web pages, I have never liked any of the fancy WYSIWYG tools that generate HTML for you. When I've looked at the actual code these kinds of tools generate, it's just so ugly! This is one reason I've always written HTML by hand, using a simple text editor like TextPad (my old Windows favorite), Notepad (the subject of many a spoof), vi (when I'm feeling extra manly), or my current favorite, emacs (especially the Aquamacs version for the Mac). The other reason I do this is that I'm a perfectionist. Go check out the source HTML on my web site if you don't believe me. :-)
Now I find that I'm not the only one - the online version of the New York Times is done the same way! In an article dated 21 April 2008, Khoi Vinh, design director of NYTimes.com, answered questions from online readers. Here is the big one for me:
Woo-hoo! Hand-coded HTML rocks!
J.A.W.
Now I find that I'm not the only one - the online version of the New York Times is done the same way! In an article dated 21 April 2008, Khoi Vinh, design director of NYTimes.com, answered questions from online readers. Here is the big one for me:
"Q: Regardless of platform or browser, NYTimes.com looks the same. This is not an easy feat to accomplish because of inconsistencies between browsers and how they handle HTML and CSS. How do you do it and with which tools?
A: It’s our preference to use a text editor, like HomeSite, TextPad or TextMate, to “hand code” everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results."
Woo-hoo! Hand-coded HTML rocks!
J.A.W.
Monday, January 21, 2008
Mac and iPod Bible Study Software News
Well, I'm not sure if it's really news to anyone but me, but I've recently discovered two great Bible study programs for Macintosh and iPod devotees (of which, of course, I am one).
The first program I found is MacSword. It's a Mac version of the open source Sword project. Here's why I like it so much:
1. It's free, open source software.
2. It runs on the Mac, a platform for which there is such a dearth of good Bible study software.
3. It has downloadable Sword modules for the English Standard Version (endorsed by http://www.desiringgod.org/) and the NET Bible (both also free).
4. It has downloadable Sword modules for some Greek and Hebrew texts, as well as many other free Bible texts, commentaries, devotionals, and other books.
The second program that I found is podBible. It's the only iPod Bible I know of, and includes the New Testament, Psalms, and Proverbs, and it's in the English Standard Version! Oh, and one more thing... free!
Check 'em out!
J.A.W.
The first program I found is MacSword. It's a Mac version of the open source Sword project. Here's why I like it so much:
1. It's free, open source software.
2. It runs on the Mac, a platform for which there is such a dearth of good Bible study software.
3. It has downloadable Sword modules for the English Standard Version (endorsed by http://www.desiringgod.org/) and the NET Bible (both also free).
4. It has downloadable Sword modules for some Greek and Hebrew texts, as well as many other free Bible texts, commentaries, devotionals, and other books.
The second program that I found is podBible. It's the only iPod Bible I know of, and includes the New Testament, Psalms, and Proverbs, and it's in the English Standard Version! Oh, and one more thing... free!
Check 'em out!
J.A.W.
Tuesday, January 08, 2008
Latest "Switchers": The U.S. Army!
Apparently the U.S. Army's IT people have been taking Apple's "switch" (now called "Get a Mac") campaign seriously:
Check out the entire Forbes article.
J.A.W.
"Given Apple's marketing toward the young and the trendy, you wouldn't expect the U.S. Army to be much of a customer. Lieutenant Colonel C.J. Wallington is hoping hackers won't expect it either.
Wallington, a division chief in the Army's office of enterprise information systems, says the military is quietly working to integrate Macintosh computers into its systems to make them harder to hack. That's because fewer attacks have been designed to infiltrate Mac computers, and adding more Macs to the military's computer mix makes it tougher to destabilize a group of military computers with a single attack, Wallington says."
Check out the entire Forbes article.
J.A.W.
Sunday, August 19, 2007
The Rise of REST and the Demise of SOAP
(This is a follow-up to my previous article, "Early signs of the
death of SOA?")
A recent article by Darryl K. Taft in the online edition of eWeek,
dated 15 July 2007, and entitled, "The Merging of SOA and Web 2.0"
offers more evidence that the SOAP and WS-* standards are not
gaining wide adoption, but simpler standards such as REST and JSON
are.
Taft quotes Dan Hushon, CTO at EMC's Grid Business Unit in Hopkinton,
MA:
"Web 2.0 concepts and technologies may, over time, displace the WS-*
stack in many cases. For example, where we used to see SOAP [Simple
Object Access Protocol] and JSON [JavaScript Object Notation]/REST
APIs to services - e.g., Google - we are now seeing mainly JSON/REST.
And, in fact, REST, with its more data-centric approach, may very
well prove to be better aligned with the need for collaborating
around data. However, systemic security remains an Achilles' heel
for REST."
Note that Hushon says it's systemic security that's the challenge, not
that REST can't be made secure at all. So let's get to work on some
good security practices for REST-based services!
J.A.W.
death of SOA?")
A recent article by Darryl K. Taft in the online edition of eWeek,
dated 15 July 2007, and entitled, "The Merging of SOA and Web 2.0"
offers more evidence that the SOAP and WS-* standards are not
gaining wide adoption, but simpler standards such as REST and JSON
are.
Taft quotes Dan Hushon, CTO at EMC's Grid Business Unit in Hopkinton,
MA:
"Web 2.0 concepts and technologies may, over time, displace the WS-*
stack in many cases. For example, where we used to see SOAP [Simple
Object Access Protocol] and JSON [JavaScript Object Notation]/REST
APIs to services - e.g., Google - we are now seeing mainly JSON/REST.
And, in fact, REST, with its more data-centric approach, may very
well prove to be better aligned with the need for collaborating
around data. However, systemic security remains an Achilles' heel
for REST."
Note that Hushon says it's systemic security that's the challenge, not
that REST can't be made secure at all. So let's get to work on some
good security practices for REST-based services!
J.A.W.
Saturday, June 09, 2007
Bad Data!
As our country's lawmakers and citizens debate the proposed Immigration Reform bill, I found an related article in the 28 May 2007 issue of eWeek entitled, "Privacy concerns stem from bill." The full title of the bill is "The Secure Borders, Economic Opportunity and Immigration Reform Act of 2007" and one of the provisions that ought to concern IT people is the proposed expansion of the Employment Eligibility Verification System (EEVS). Basically, it would require all American workers to be registered in a Department of Homeland Security database, be checked against it to get a job, and also fine businesses that don't comply. The problem is, the government doesn't have a good track record for operating and protecting large databases like this - just think about the problems with the "No Fly List" database and recent data breaches. Here's my favorite quote from the article:
"The government definitely seems to have two consistent problems — one is bad data getting into the database ... and the other is getting bad data out of the database," said John Pescatore, an analyst for Gartner.
I usually take anything a Gartner analyst says with a large grain of salt, but in this case, he's right on the money. As a government employee who's run large database programs for a living, I can tell you: It's going to be a disaster.
J.A.W.
"The government definitely seems to have two consistent problems — one is bad data getting into the database ... and the other is getting bad data out of the database," said John Pescatore, an analyst for Gartner.
I usually take anything a Gartner analyst says with a large grain of salt, but in this case, he's right on the money. As a government employee who's run large database programs for a living, I can tell you: It's going to be a disaster.
J.A.W.
Tuesday, May 22, 2007
Wimpy Theology
I just read an article entitled "The Military: Faith Under Fire" by Eve Conant in the 7 May 2007 print issue of Newsweek. It's a story about Army Chaplain Roger Benimoff and his experiences in Iraq. In a nutshell, he goes to Iraq, an evangelical Christian feeling full of faith and enthusiasm to help the soldiers there, and he ends up "losing" his faith, then slowly regaining it after returning to the U.S. The uniqueness of the article is the way in which the author tells Benimoff's story by interspersing personal interviews and diary entries.
It becomes clear that during his two tours in Iraq, Benimoff's faith in God is severely tested as he goes about his duties. Though at first his faith appeared to be strong, he became increasingly troubled by the senselessness and carnage of the war. It is related that he often quoted Bible verses to himself and others for comfort, "But it didn't explain why bad things happen to good people, a question Benimoff would face again and again from the soldiers he served with - and
from within himself." When counseling other soldiers, "They would ask me: if I'm a child of God, then why isn't God protecting me?"
The thing that made me want to write this post was a quote from Benimoff's wife, obviously very concerned about her husband's faith and general well-being: "Sometimes he would ask me: why does a loving God allow suicide bombers to attack civilians? We were both brought up with a picture of God that was different from the world he was seeing."
This highlights what I believe is a problem in many Christian churches today. What is this "picture of God" that they found so different from their experience in the real world? Theologians have wrestled with this problem for a long time (there's an understatement for you!), but many basic truths from the Bible can illuminate our understanding of the problem. For example, it is true that God allows "bad" things to happen to "good" people (see the book of Job, for instance). God is also sovereign and acts in ways that are sometimes difficult or impossible for us to understand. For a Bible-believing Christian, this is a given. I think it is due to a "wimpy gospel" that some Christians think we are immune to such troubles when we become believers. Being a Christian is not always "fun" - there are trials and troubles that God
uses to refine us and build our faith in Him. But we need to understand that is the norm, and being a Christian is not a guarantee of a trouble-free, happy-all-the-time existence.
I have great respect for Chaplain Benimoff and all our other servicemen who selflessly work to protect our citizens, our country and our freedoms. But I lay blame on denominations, seminaries, churches, and pastors who preach a warped gospel. We must present a full and well-balanced view of real Christianity, including all the fun and not-so-fun aspects.
After returning to the U.S. to take a tour at Walter Reed Army Medical Center, he wrote in his journal, "I was reading my Bible and I found myself getting violently mad at God." But by the time of his Newsweek interview, he appears to be regaining his faith, but still deals with the pain, saying, "But now I have a new relationship with God. I tend to be much more blunt with him." This sounds to me like a good thing; be honest with God and be realistic about what it's like to serve Him.
J.A.W.
P.S. - I just got the 21 May 2007 issue of Newsweek, and there were several letters to the editor on the Faith Under Fire article. Some of them basically agreed with me, but did not identify wimpy theology as the problem.
It becomes clear that during his two tours in Iraq, Benimoff's faith in God is severely tested as he goes about his duties. Though at first his faith appeared to be strong, he became increasingly troubled by the senselessness and carnage of the war. It is related that he often quoted Bible verses to himself and others for comfort, "But it didn't explain why bad things happen to good people, a question Benimoff would face again and again from the soldiers he served with - and
from within himself." When counseling other soldiers, "They would ask me: if I'm a child of God, then why isn't God protecting me?"
The thing that made me want to write this post was a quote from Benimoff's wife, obviously very concerned about her husband's faith and general well-being: "Sometimes he would ask me: why does a loving God allow suicide bombers to attack civilians? We were both brought up with a picture of God that was different from the world he was seeing."
This highlights what I believe is a problem in many Christian churches today. What is this "picture of God" that they found so different from their experience in the real world? Theologians have wrestled with this problem for a long time (there's an understatement for you!), but many basic truths from the Bible can illuminate our understanding of the problem. For example, it is true that God allows "bad" things to happen to "good" people (see the book of Job, for instance). God is also sovereign and acts in ways that are sometimes difficult or impossible for us to understand. For a Bible-believing Christian, this is a given. I think it is due to a "wimpy gospel" that some Christians think we are immune to such troubles when we become believers. Being a Christian is not always "fun" - there are trials and troubles that God
uses to refine us and build our faith in Him. But we need to understand that is the norm, and being a Christian is not a guarantee of a trouble-free, happy-all-the-time existence.
I have great respect for Chaplain Benimoff and all our other servicemen who selflessly work to protect our citizens, our country and our freedoms. But I lay blame on denominations, seminaries, churches, and pastors who preach a warped gospel. We must present a full and well-balanced view of real Christianity, including all the fun and not-so-fun aspects.
After returning to the U.S. to take a tour at Walter Reed Army Medical Center, he wrote in his journal, "I was reading my Bible and I found myself getting violently mad at God." But by the time of his Newsweek interview, he appears to be regaining his faith, but still deals with the pain, saying, "But now I have a new relationship with God. I tend to be much more blunt with him." This sounds to me like a good thing; be honest with God and be realistic about what it's like to serve Him.
J.A.W.
P.S. - I just got the 21 May 2007 issue of Newsweek, and there were several letters to the editor on the Faith Under Fire article. Some of them basically agreed with me, but did not identify wimpy theology as the problem.
Saturday, March 17, 2007
What do Software Architects Do?
In many software organizations, there are job titles like
"Software Architect". What do Software Architects do? That's a great
question, but there is no general agreement on the answer.
I have a friend who is a "real" architect (the kind that designs and
builds buildings) and he tells me that in his industry they are a bit
upset with our industry's use of the term. It's mostly because
Software Architects don't go through anything like the kind of
training, testing, and certification that building architects do. I
think they have a good point.
A recent article by Joe Winchester in the online edition of Java
Developers Journal entitled, "Those Who Can, Code; Those Who Can't,
Architect" really got my attention. The article begins with this:
"At the moment there seems to be an extremely unhealthy obsession in
software with the concept of architecture. A colleague of mine, a
recent graduate, told me he wished to become a software architect. He
was drawn to the glamour of being able to come up with grandiose ideas
- sweeping generalized designs, creating presentations to audiences of
acronym addicts, writing esoteric academic papers, speaking at
conferences attended by headless engineers on company expense accounts
hungrily seeking out this year's grail, and creating e-mails with huge
cc lists from people whose signature footer is more interesting than
the content. I tried to re-orient him into actually doing some coding,
to join a team that has a good product and keen users both of whom are
pushing requirements forward, to no avail. Somehow the lure of being
an architecture astronaut was too strong and I lost him to the dark
side."
Of course, there's a "Software Architect" article in Wikipedia, so I
checked it out. The job description seemed to have a lot to do with
working with stakeholders, getting user requirements, doing cost/benefit
analysis, generating acceptance test requirements, and "generating
products such as sketches, formal diagrams, executable models, an
early user's manual, and prototypes." Except for maybe prototypes,
that doesn't sound like much codin' to me! Where is the need to
actually understand programming?
Winchester continues: "Meanwhile, the architects seem invincible
to failure and rise within the ranks of their organizations, ordering
fresh business cards each year with the words 'architect,' 'senior'
or, for the power blowhards, 'distinguished' in the title. They are
drawn to the tar pit of attending and creating presentations, or
joining conference calls with fellow architects who showboat their
knowledge of obscure standards specifications or bleeding-edge
research projects."
I found that there's an organization called the "Worldwide Institute
of Software Architects (WWISA)". Ironically, the graphic on their web
site's home page illustrates that they do in fact consider themselves
architects in the same sense as the kind who build buildings.
Winchester concludes: "When confronted by such people, recant the
following mantra:
Code ships,
code runs,
code helps users,
get their job done.
Remind any architects in your path that presentation charts, e-mails,
project plans, line-items spreadsheets and so forth, are all there to
help the code ship on time and to spec. The goal of everyone on a
project should be to spend as little time as possible on tasks that
distract from the job of creating quality, tested, and shippable
code. Please architects, please understand this, respect this, and
quietly stay out of the way of those good folk who prefer to spend
their day working with an IDE writing code rather than composing
e-mails."
J.A.W.
"Software Architect". What do Software Architects do? That's a great
question, but there is no general agreement on the answer.
I have a friend who is a "real" architect (the kind that designs and
builds buildings) and he tells me that in his industry they are a bit
upset with our industry's use of the term. It's mostly because
Software Architects don't go through anything like the kind of
training, testing, and certification that building architects do. I
think they have a good point.
A recent article by Joe Winchester in the online edition of Java
Developers Journal entitled, "Those Who Can, Code; Those Who Can't,
Architect" really got my attention. The article begins with this:
"At the moment there seems to be an extremely unhealthy obsession in
software with the concept of architecture. A colleague of mine, a
recent graduate, told me he wished to become a software architect. He
was drawn to the glamour of being able to come up with grandiose ideas
- sweeping generalized designs, creating presentations to audiences of
acronym addicts, writing esoteric academic papers, speaking at
conferences attended by headless engineers on company expense accounts
hungrily seeking out this year's grail, and creating e-mails with huge
cc lists from people whose signature footer is more interesting than
the content. I tried to re-orient him into actually doing some coding,
to join a team that has a good product and keen users both of whom are
pushing requirements forward, to no avail. Somehow the lure of being
an architecture astronaut was too strong and I lost him to the dark
side."
Of course, there's a "Software Architect" article in Wikipedia, so I
checked it out. The job description seemed to have a lot to do with
working with stakeholders, getting user requirements, doing cost/benefit
analysis, generating acceptance test requirements, and "generating
products such as sketches, formal diagrams, executable models, an
early user's manual, and prototypes." Except for maybe prototypes,
that doesn't sound like much codin' to me! Where is the need to
actually understand programming?
Winchester continues: "Meanwhile, the architects seem invincible
to failure and rise within the ranks of their organizations, ordering
fresh business cards each year with the words 'architect,' 'senior'
or, for the power blowhards, 'distinguished' in the title. They are
drawn to the tar pit of attending and creating presentations, or
joining conference calls with fellow architects who showboat their
knowledge of obscure standards specifications or bleeding-edge
research projects."
I found that there's an organization called the "Worldwide Institute
of Software Architects (WWISA)". Ironically, the graphic on their web
site's home page illustrates that they do in fact consider themselves
architects in the same sense as the kind who build buildings.
Winchester concludes: "When confronted by such people, recant the
following mantra:
Code ships,
code runs,
code helps users,
get their job done.
Remind any architects in your path that presentation charts, e-mails,
project plans, line-items spreadsheets and so forth, are all there to
help the code ship on time and to spec. The goal of everyone on a
project should be to spend as little time as possible on tasks that
distract from the job of creating quality, tested, and shippable
code. Please architects, please understand this, respect this, and
quietly stay out of the way of those good folk who prefer to spend
their day working with an IDE writing code rather than composing
e-mails."
J.A.W.
Is Python Ready for Prime Time? Yes!
Is Python Ready for Prime Time?
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
Early signs of the death of SOA?
Trying to follow what's going on in the world of enterprise
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
Hilarious SOA Video
I found an absolutely hilarious video on YouTube (what a surprise!) called "Greg the Architect - SOA This. SOA That." Not only funny, it reflects a strangely ironic, true picture of the state of the current Service-Oriented Architecture
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
Sunday, December 31, 2006
In the Beginning... Was the Command Line
I just finished reading Neal Stephenson's "In the Beginning... Was the Command Line", first published in 1999. If you're any kind of hacker, coder, computer geek, or just someone interested in how modern personal computers came to be, this book is for you. I greatly enjoyed the book, and Stephenson's witty, smart style, but I'm not really sure what conclusion(s) I should draw from it.
The book is short (151 pages), and reads like a long essay. Stephenson quickly covers the history of the personal computer and the evolution of their operating systems, concentrating on Microsoft's and Apple's products. He discusses things like why it's hard to make a living selling operating systems, and what Microsoft and Apple have had to do to survive, which is to keep the products very proprietary, and continually one-up each other with with features in each new release. He then covers the GNU/Linux phenomenon is some detail, and makes a good case for why you should at least try it some time. The benefit is that you will have a chance to experience the "freedom" that comes from using a free, non-proprietary operating system, and the ability to tinker with the system to your heart's content without worrying about voiding your warranty. Plus, it's just a great excuse to "stick it to the man"!
One of my personal favorite quotes is on page 95, where Stephenson describes the main text editors used in the GNU/Linux world: vi and Emacs. He says, "I use emacs, which might be thought of as a thermonuclear word processor." Being a recent convert and fan of Emacs myself, I love this comment! I think it's a very accurate description of this most versatile tool.
Cautionary Note - If you visit Stephenson's web site, you'll find this interesting comment: "In the Beginning was the Command Line is now badly obsolete and probably needs a thorough revision. For the last couple of years I have been a Mac OS X user almost exclusively."
Hooray! Mac OS wins in the end!
J.A.W.
The book is short (151 pages), and reads like a long essay. Stephenson quickly covers the history of the personal computer and the evolution of their operating systems, concentrating on Microsoft's and Apple's products. He discusses things like why it's hard to make a living selling operating systems, and what Microsoft and Apple have had to do to survive, which is to keep the products very proprietary, and continually one-up each other with with features in each new release. He then covers the GNU/Linux phenomenon is some detail, and makes a good case for why you should at least try it some time. The benefit is that you will have a chance to experience the "freedom" that comes from using a free, non-proprietary operating system, and the ability to tinker with the system to your heart's content without worrying about voiding your warranty. Plus, it's just a great excuse to "stick it to the man"!
One of my personal favorite quotes is on page 95, where Stephenson describes the main text editors used in the GNU/Linux world: vi and Emacs. He says, "I use emacs, which might be thought of as a thermonuclear word processor." Being a recent convert and fan of Emacs myself, I love this comment! I think it's a very accurate description of this most versatile tool.
Cautionary Note - If you visit Stephenson's web site, you'll find this interesting comment: "In the Beginning was the Command Line is now badly obsolete and probably needs a thorough revision. For the last couple of years I have been a Mac OS X user almost exclusively."
Hooray! Mac OS wins in the end!
J.A.W.
Tuesday, December 26, 2006
How many wikis are too many?
The rising popularity and ubiquity of wikis on the internet (Wikipedia is the
quintessential example) is driving a similar pattern of adoption on
the other side of the firewall, inside corporations large and small.
A recent eWeek article entitled "Wikis Are Alive and Kicking in the
Enterprise" ("Veni, vidi, wiki" in the print edition), gives some
interesting insights into how wikis are being used in a couple of
large companies.
The first example is Motorola, with about 68,000 employees. Wikis
were introduced into the company about 18 months ago. They had 500
wikis after six months, 1,000 wikis after a year, and now the number
is 3,200! Corporate VP of IT Toby Redshaw was quoted as saying, "I'm
not sure how many more we're going to have - 3,200 wikis is a lot.
We'll probably top out around 4,000." Motorola uses several different
wiki products: Open Text, TWiki, and (literally) uncounted others.
How do they manage to keep it all under control? They don't. Redshaw
said "We don't have a wiki police group... we just think it's the way
to business runs." They do however, have a group of 250 volunteer
"knowledge champions" who take responsibility for different subject
areas in the Open Text platform. When asked why Motorola had taken to
the new platforms, Redshaw said, "One reason is generational. Another
is our affinity for technology. People take to it because we're an
engineering-based firm."
The second example is Novell. Their use of wikis started a couple of
years ago when an engineer installed a wiki server under the desk of
Lee Romero, manager for knowledge and collaboration services. Later,
Romero devised a wiki strategy for the entire company, setting up a
corporate wiki for all employees. Romero said, "It promotes openness
for both reading and authoring; it's a collaborative environment.
It's much more efficient when the work product is a document." Like
Motorola, Novell uses several different wiki products: MediaWiki (for
enterprise use), TWiki (for engineering use), and what Romero calls
"renegade" wikis. Most of the renegades run on TWiki, and Romero says
he knows very little about them, but the company tolerates this,
presumably because of the benefits it derives. Romero estimated the
IT support for all their wikis to be about one-quarter of one person's
time per year.
What can we conclude from these examples? Without going too far out
on a limb, here's what I think:
1. Wikis deliver. Most wiki products are relatively easy to install,
use, and administer. Many are free, open source products. People
like 'em because that's what they have on the Internet. The
benefits from the inherently open nature of wikis and the low cost
make their use a no-brainer.
2. Multiple wiki products are OK. Some wiki products are better for
some purposes than others; you may need more than one or two
different products to meet the varied needs of a large
corporation. Some organizations think that allowing multiple
products necessarily means high operating costs and requirements
for personnel trained to maintain the various products. The
experiences of Motorola and Novell seem to indicate that these
concerns are hardly worth thinking about, compared to the
benefits. Rather than worrying about the number of different wiki
products, it is more important to think about the value of the data
in them. They should worry about making sure that valuable
corporate data is regularly backed up and searchable by all
employees who might need to get to it.
J.A.W.
quintessential example) is driving a similar pattern of adoption on
the other side of the firewall, inside corporations large and small.
A recent eWeek article entitled "Wikis Are Alive and Kicking in the
Enterprise" ("Veni, vidi, wiki" in the print edition), gives some
interesting insights into how wikis are being used in a couple of
large companies.
The first example is Motorola, with about 68,000 employees. Wikis
were introduced into the company about 18 months ago. They had 500
wikis after six months, 1,000 wikis after a year, and now the number
is 3,200! Corporate VP of IT Toby Redshaw was quoted as saying, "I'm
not sure how many more we're going to have - 3,200 wikis is a lot.
We'll probably top out around 4,000." Motorola uses several different
wiki products: Open Text, TWiki, and (literally) uncounted others.
How do they manage to keep it all under control? They don't. Redshaw
said "We don't have a wiki police group... we just think it's the way
to business runs." They do however, have a group of 250 volunteer
"knowledge champions" who take responsibility for different subject
areas in the Open Text platform. When asked why Motorola had taken to
the new platforms, Redshaw said, "One reason is generational. Another
is our affinity for technology. People take to it because we're an
engineering-based firm."
The second example is Novell. Their use of wikis started a couple of
years ago when an engineer installed a wiki server under the desk of
Lee Romero, manager for knowledge and collaboration services. Later,
Romero devised a wiki strategy for the entire company, setting up a
corporate wiki for all employees. Romero said, "It promotes openness
for both reading and authoring; it's a collaborative environment.
It's much more efficient when the work product is a document." Like
Motorola, Novell uses several different wiki products: MediaWiki (for
enterprise use), TWiki (for engineering use), and what Romero calls
"renegade" wikis. Most of the renegades run on TWiki, and Romero says
he knows very little about them, but the company tolerates this,
presumably because of the benefits it derives. Romero estimated the
IT support for all their wikis to be about one-quarter of one person's
time per year.
What can we conclude from these examples? Without going too far out
on a limb, here's what I think:
1. Wikis deliver. Most wiki products are relatively easy to install,
use, and administer. Many are free, open source products. People
like 'em because that's what they have on the Internet. The
benefits from the inherently open nature of wikis and the low cost
make their use a no-brainer.
2. Multiple wiki products are OK. Some wiki products are better for
some purposes than others; you may need more than one or two
different products to meet the varied needs of a large
corporation. Some organizations think that allowing multiple
products necessarily means high operating costs and requirements
for personnel trained to maintain the various products. The
experiences of Motorola and Novell seem to indicate that these
concerns are hardly worth thinking about, compared to the
benefits. Rather than worrying about the number of different wiki
products, it is more important to think about the value of the data
in them. They should worry about making sure that valuable
corporate data is regularly backed up and searchable by all
employees who might need to get to it.
J.A.W.
Thursday, November 23, 2006
Restaurant Hospitality Tips for Software Development
Although my day job is in the software development business, I also love cooking and eating (hmm... doesn't everyone?) One of my favorite podcasts is KCRW's Good Food. Recently, Good Food's host, Evan Kleiman, interviewed famous restauranteur Danny Meyer. In light of the generally abysmal reputation the industry has in customer satisfaction for the software we deliver, I was amazed by the potential for improving the the software development business by applying his insights and hospitality principles from the restaurant business. I think this interview is so good, I transcribed the whole thing, and I strongly encourage software developers to read the whole thing, or go to the Good Food site and listen to the podcast.
I've highlighted the parts (in bold) that I think are particularly applicable to software development. Here's a summary of what I think are the important lessons:
Here's the transcript of the interview:
Where the Heck Is My Waiter?
KCRW's Good Food host Evan Kleiman interviews Restauranteur Danny Meyer
(15:55-24:02 segment on podcast)
Evan: Restauranteur Danny Meyer's committent to hospitality is legendary. His New York restaurants Tabla, Gramercy Tavern, Union Square Cafe, Eleven Madison Park, and his latest venture, Blue Smoke are benchmarks of how restaurants should be run. He manages to combine great food with a welcoming embrace. This embrace of the customer is his genius. The understanding that people want a place where they feel they belong and are welcome. Danny's finally written a book for all of us in business, whether you're in the restaurant business or not, it's called "Setting the Table: The Transforming Power of Hospitality in Business". I'm so glad you're here today, Denny.
Danny: Thank you for welcoming me.
Evan: Let's just talk for a minute about this word, "hospitality". How does hospitality differ from service?
Danny: Dramatically, and that actually came as a huge surprise to me. A number of years ago I decided instead of doing what I always do, which is to try to figure out what we're doing wrong, our restaurants kept doing pretty well, and I said, "You know, this is a business with a pretty high mortality rate. What if I could focus on what was going right?" And we were constantly getting praise for having this great service, and I saw the mistakes we were making. You know, we'd get the wrong food to the wrong person and sometimes make people wait too long for their reservations; this goes back into the early nineties. And I said, "Well, why do they keep praising us for something that I think we could be doing better?" And I figured out that what they were really loving, far beyond our service, was our hospitality, and what they were really responding to was the way we made them feel while they were on the receiving end of our service.
Evan: I would imagine that employees are the key component to that.
Danny: Yeah, it always is going to depend on who you hire on the front line, and I've been traveling around the country quite a bit recently. My entire feeling about a hotel chain, or a rent-a-car chain, or an airline, or a restaurant, has to do with the human being with whom I had my first point of contact. And it just seems so silly, if you think about it, that restauranteurs, for example, spend so much money trying to get the best chef out there, trying to get the best design for their restaurants - why in the world wouldn't they put the same amount of effort into the quality of the human beings who work in their restaurant? And it's really emotional skills that we look for, even more than technical skills.
Evan: Could you talk about those emotional skills?
Danny: I can; they're together they're something that I call having a high "HQ", or "Hospitality Quotient". And it's basically five skill sets that I don't know how to teach, but they can be identified, and if you can see these, and hire them on your team, you just stand a much, much higher rate of success in terms of making people feel welcome. And you're looking for people who are naturally kind and optimistic; hopeful, I think is at the root of the word hospitality. You're looking for people who are curious about learning, who have an extarordinary work ethic. Empathy is a huge emotional skill in a high hospitality quotient, and then, at last, integrity, which is possessing the judgement in any circumstance to do the right thing. And if we can get somebody who knows how to cook really well, that gets us to about the forty-nine
yard line. Now what we need for the next fifty-one yards are the compendium of those emotional skills I just outlined.
Evan: How do you go about hiring that? Do you do some sort of really sophisticated psychological testing?
Danny: Absolutely not. I wouldn't pay anyone a dime for that. I spend a lot of my time trying to hire leaders, and I put my focus on hiring the people who will be doing the hiring in our company.
Evan: Where is the customer in all of this? Is the customer always right?
Danny: Well, obviously we come to work with the hoped-for goal that the customer leaves raving about the experience. Just like any customer comes to a restaurant hoping to leave raving, we have found, sort of counterintuitively, that the best way to bring about that outcome is actually to put the customer second. I had always been taught growing up that the customer always comes first. When our staff feels really jazzed about coming to work with one another every single day, and they feel a sense of mutual respect and trust, we think the chances of customer satisfaction are way, way enhanced.
Now what that means is that there are occasions in which when the customer is not right. And I knew that even when I was, you know, a pretty young entrepreneur, and someone would come up to me and say, "Hey, Meursault is not a Chardonnay", and I know that the grape Chardonnay is the only grape in the French wine Meursault. So that customer wasn't right, but what I learned was that really the best thing to do is to just let the customer always feel heard; they don't always have to be right.
And then, furthermore, sometimes the customer is not right when they treat one of our staff members with disrespect. And for me I've found that in those rare instances, in fact we had one of those last night at one of our restaurants and I had to step in, where a customer was treating one of our lead staff members incredibly disrespectfully, and I came to the defense of my own staff member. I would much rather constantly build the team, who's responsible for providing all this excellence and hospitality.
Evan: Could you relate an instance of something that you heard your staff did for a guest that to you just made you feel so happy?
Danny: I got a letter just yesterday from somebody who raved about his meal at Gramercy Tavern, not for the lovely environment that we've put so much into, not even for the quality of the food; in fact, not even for the service. But instead, he took the time to write a whole letter to me because his back waiter, alright, this is the guy who's like a busboy, overheard that he really likes the crust part of the bread. And this back waiter brings him a whole tray of the ends of this wonderful bread that we serve at Gramercy Tavern. Now who in the world could have trained for that? All I could do, in retrospect, would have been to hire somebody who is thoughtful, somebody who thinks and feels, and then acts.
Evan: How can the guest enhance their own restaurant experience?
Denny: The best thing a guest can do is to be forthright. Realize that restaurants are really a laboratory for making mistakes, whether we like it or not. Every single two-hour meal in any of my restaurants today, I guarantee you, we're gonna probably make ten to twelve mistakes. If we're really on our game, you will not know about ten of 'em, 'cause we'll figure out ways to overcome before you even know, but you might get a salmon that's slightly undercooked or overcooked, but the key thing is this: rather than having an adversarial relationship with us, or with the restaurant, realze that we want you to leave happy. So if you'll just tell us while you're there, I want you to judge us not by the fact that we are or are not perfect, but rather how well and how graciously did we overcome a mistake once you told us. We are not great mind readers.
Evan: Thanks a lot for spending the morning with us.
Danny: Thank you so much, Evan.
Evan: Danny Meyer owns five of New York City's best and most popular restaurants: Tabla, Gramercy Tavern, Union Square Cafe, 11 Madison Park, and his latest venture, Blue Smoke. He's the author of Setting the Table: Transforming the Power of Hospitality and Business."
I've highlighted the parts (in bold) that I think are particularly applicable to software development. Here's a summary of what I think are the important lessons:
- Hire the best people, assembling a team that is passionate about delivering satisfaction to the customer, as well as being technically competent.
- Constantly build the team, putting development of emotional skills, technical skills, and team cohesiveness first; customer satisfaction will be the natural byproduct.
- Gain customer confidence by developing a mutually respectful relationship based on honesty and trust; communication and feedback goes both ways.
Here's the transcript of the interview:
Where the Heck Is My Waiter?
KCRW's Good Food host Evan Kleiman interviews Restauranteur Danny Meyer
(15:55-24:02 segment on podcast)
Evan: Restauranteur Danny Meyer's committent to hospitality is legendary. His New York restaurants Tabla, Gramercy Tavern, Union Square Cafe, Eleven Madison Park, and his latest venture, Blue Smoke are benchmarks of how restaurants should be run. He manages to combine great food with a welcoming embrace. This embrace of the customer is his genius. The understanding that people want a place where they feel they belong and are welcome. Danny's finally written a book for all of us in business, whether you're in the restaurant business or not, it's called "Setting the Table: The Transforming Power of Hospitality in Business". I'm so glad you're here today, Denny.
Danny: Thank you for welcoming me.
Evan: Let's just talk for a minute about this word, "hospitality". How does hospitality differ from service?
Danny: Dramatically, and that actually came as a huge surprise to me. A number of years ago I decided instead of doing what I always do, which is to try to figure out what we're doing wrong, our restaurants kept doing pretty well, and I said, "You know, this is a business with a pretty high mortality rate. What if I could focus on what was going right?" And we were constantly getting praise for having this great service, and I saw the mistakes we were making. You know, we'd get the wrong food to the wrong person and sometimes make people wait too long for their reservations; this goes back into the early nineties. And I said, "Well, why do they keep praising us for something that I think we could be doing better?" And I figured out that what they were really loving, far beyond our service, was our hospitality, and what they were really responding to was the way we made them feel while they were on the receiving end of our service.
Evan: I would imagine that employees are the key component to that.
Danny: Yeah, it always is going to depend on who you hire on the front line, and I've been traveling around the country quite a bit recently. My entire feeling about a hotel chain, or a rent-a-car chain, or an airline, or a restaurant, has to do with the human being with whom I had my first point of contact. And it just seems so silly, if you think about it, that restauranteurs, for example, spend so much money trying to get the best chef out there, trying to get the best design for their restaurants - why in the world wouldn't they put the same amount of effort into the quality of the human beings who work in their restaurant? And it's really emotional skills that we look for, even more than technical skills.
Evan: Could you talk about those emotional skills?
Danny: I can; they're together they're something that I call having a high "HQ", or "Hospitality Quotient". And it's basically five skill sets that I don't know how to teach, but they can be identified, and if you can see these, and hire them on your team, you just stand a much, much higher rate of success in terms of making people feel welcome. And you're looking for people who are naturally kind and optimistic; hopeful, I think is at the root of the word hospitality. You're looking for people who are curious about learning, who have an extarordinary work ethic. Empathy is a huge emotional skill in a high hospitality quotient, and then, at last, integrity, which is possessing the judgement in any circumstance to do the right thing. And if we can get somebody who knows how to cook really well, that gets us to about the forty-nine
yard line. Now what we need for the next fifty-one yards are the compendium of those emotional skills I just outlined.
Evan: How do you go about hiring that? Do you do some sort of really sophisticated psychological testing?
Danny: Absolutely not. I wouldn't pay anyone a dime for that. I spend a lot of my time trying to hire leaders, and I put my focus on hiring the people who will be doing the hiring in our company.
Evan: Where is the customer in all of this? Is the customer always right?
Danny: Well, obviously we come to work with the hoped-for goal that the customer leaves raving about the experience. Just like any customer comes to a restaurant hoping to leave raving, we have found, sort of counterintuitively, that the best way to bring about that outcome is actually to put the customer second. I had always been taught growing up that the customer always comes first. When our staff feels really jazzed about coming to work with one another every single day, and they feel a sense of mutual respect and trust, we think the chances of customer satisfaction are way, way enhanced.
Now what that means is that there are occasions in which when the customer is not right. And I knew that even when I was, you know, a pretty young entrepreneur, and someone would come up to me and say, "Hey, Meursault is not a Chardonnay", and I know that the grape Chardonnay is the only grape in the French wine Meursault. So that customer wasn't right, but what I learned was that really the best thing to do is to just let the customer always feel heard; they don't always have to be right.
And then, furthermore, sometimes the customer is not right when they treat one of our staff members with disrespect. And for me I've found that in those rare instances, in fact we had one of those last night at one of our restaurants and I had to step in, where a customer was treating one of our lead staff members incredibly disrespectfully, and I came to the defense of my own staff member. I would much rather constantly build the team, who's responsible for providing all this excellence and hospitality.
Evan: Could you relate an instance of something that you heard your staff did for a guest that to you just made you feel so happy?
Danny: I got a letter just yesterday from somebody who raved about his meal at Gramercy Tavern, not for the lovely environment that we've put so much into, not even for the quality of the food; in fact, not even for the service. But instead, he took the time to write a whole letter to me because his back waiter, alright, this is the guy who's like a busboy, overheard that he really likes the crust part of the bread. And this back waiter brings him a whole tray of the ends of this wonderful bread that we serve at Gramercy Tavern. Now who in the world could have trained for that? All I could do, in retrospect, would have been to hire somebody who is thoughtful, somebody who thinks and feels, and then acts.
Evan: How can the guest enhance their own restaurant experience?
Denny: The best thing a guest can do is to be forthright. Realize that restaurants are really a laboratory for making mistakes, whether we like it or not. Every single two-hour meal in any of my restaurants today, I guarantee you, we're gonna probably make ten to twelve mistakes. If we're really on our game, you will not know about ten of 'em, 'cause we'll figure out ways to overcome before you even know, but you might get a salmon that's slightly undercooked or overcooked, but the key thing is this: rather than having an adversarial relationship with us, or with the restaurant, realze that we want you to leave happy. So if you'll just tell us while you're there, I want you to judge us not by the fact that we are or are not perfect, but rather how well and how graciously did we overcome a mistake once you told us. We are not great mind readers.
Evan: Thanks a lot for spending the morning with us.
Danny: Thank you so much, Evan.
Evan: Danny Meyer owns five of New York City's best and most popular restaurants: Tabla, Gramercy Tavern, Union Square Cafe, 11 Madison Park, and his latest venture, Blue Smoke. He's the author of Setting the Table: Transforming the Power of Hospitality and Business."
Saturday, November 11, 2006
More SOA Wonders
The more you learn about Service-Oriented Architecture (SOA), the more you find it's the solution to everything!
Here's a site that lays out the facts on SOA:
http://soafacts.com/
J.A.W.
Here's a site that lays out the facts on SOA:
http://soafacts.com/
J.A.W.
Tuesday, November 07, 2006
SOA: Me Too!
Service-Oriented Architecture (SOA) is the latest buzzword and fad in the Information Technology world, and all the big vendors are jumping in to get a piece of the action. A recent article in eWeek entitled "Oracle Upgrades SOA Offerings" provides some humorous insight into the competition:
"However, Bill Roth, vice president of BEA Systems' Workshop Business Unit, said of Oracle's SOA news: "We have been talking about SOA since 2003, and IBM has recently painted a good part of its software with a lovely coat of SOA paint. [From Oracle] expect another 'Me Too' announcement on how everything they do is SOA, and comes from the database."
J.A.W.
"However, Bill Roth, vice president of BEA Systems' Workshop Business Unit, said of Oracle's SOA news: "We have been talking about SOA since 2003, and IBM has recently painted a good part of its software with a lovely coat of SOA paint. [From Oracle] expect another 'Me Too' announcement on how everything they do is SOA, and comes from the database."
J.A.W.
Monday, October 30, 2006
Lessons from the Agile Garment Industry
It turns out that software developers may have something to learn from the garment industry. I just read the "My Turn" editorial in the 30 October 2006 issue of Newsweek, entitled "How to Keep Your Shirt". The author, Sudhir Dhingra, describes both his experiences in starting up and running a garment business in India. It's quite a story, detailing the trials of the licensing bureaucracy, corrupt officials, various kinds of red tape, competing with China, and the successes of eventual partnerships with the likes of Ralph Lauren, Banana Republic, Tommy Hilfiger, Nike, and Levis.
One lesson Dhingra recounts, as a result of being stuck with piles of unsold Nehru shirts (remember that '70's craze?), is that "in the garment business you have to make fashion, not follow trends." Other conclusions he draws include, "We don't just make clothes, we design them," and "We successfully compete with China because we make a better product."
I was particularly struck by this key statement: "I came to see that the key to success in the globalizing apparel market is to be involved in design and development with the customer."
To me, Dhingra's lessons learned sound like they were written by the advocates of agile software development. Apart from the current hype surrounding the agile movement, don't Dhingra's conclusions square with good principles of software development in general? Who would argue that being a leader in good design, making better products, and working closely with the customer are not keys to software product success?
A favorite discussion question in the software community is what other discipline is our industry like? Is writing software similar to designing a building? Or is it more like writing poetry or painting a picture? You find plenty of opinions at both ends of the spectrum, but Dhingra demonstrates we can probably learn a lot from the garment industry.
J.A.W.
One lesson Dhingra recounts, as a result of being stuck with piles of unsold Nehru shirts (remember that '70's craze?), is that "in the garment business you have to make fashion, not follow trends." Other conclusions he draws include, "We don't just make clothes, we design them," and "We successfully compete with China because we make a better product."
I was particularly struck by this key statement: "I came to see that the key to success in the globalizing apparel market is to be involved in design and development with the customer."
To me, Dhingra's lessons learned sound like they were written by the advocates of agile software development. Apart from the current hype surrounding the agile movement, don't Dhingra's conclusions square with good principles of software development in general? Who would argue that being a leader in good design, making better products, and working closely with the customer are not keys to software product success?
A favorite discussion question in the software community is what other discipline is our industry like? Is writing software similar to designing a building? Or is it more like writing poetry or painting a picture? You find plenty of opinions at both ends of the spectrum, but Dhingra demonstrates we can probably learn a lot from the garment industry.
J.A.W.
Kennedy's Software Project Schedule
President John F. Kennedy, in his 1961 inagural address, said:
"All this will not be finished in the first one hundred days. Nor will it be finished in the first one thousand days, nor in the life of this Administration, nor even perhaps in our lifetime on this planet. But let us begin."
The "this" that President Kennedy was referring to was a set of lofty goals for world peace, in the face of growing concern over nuclear arms proliferation. However, I think we can take these words and apply them to our software projects, as they are very much in line with the current buzz over agile software development techniques. So, I present to you a version of Kennedy's statement that you can use for your "agile" software project schedule:
"All of this application will not be finished in the first one hundred days. Nor will it be finished in the first one thousand days, nor in the life of this Project Manager, nor even perhaps in the lifetime of this organization. But let us begin to code."
Just copy the above lines into your project plans and cite President Kennedy as your example of how to realistically get things done.
J.A.W.
"All this will not be finished in the first one hundred days. Nor will it be finished in the first one thousand days, nor in the life of this Administration, nor even perhaps in our lifetime on this planet. But let us begin."
The "this" that President Kennedy was referring to was a set of lofty goals for world peace, in the face of growing concern over nuclear arms proliferation. However, I think we can take these words and apply them to our software projects, as they are very much in line with the current buzz over agile software development techniques. So, I present to you a version of Kennedy's statement that you can use for your "agile" software project schedule:
"All of this application will not be finished in the first one hundred days. Nor will it be finished in the first one thousand days, nor in the life of this Project Manager, nor even perhaps in the lifetime of this organization. But let us begin to code."
Just copy the above lines into your project plans and cite President Kennedy as your example of how to realistically get things done.
J.A.W.
Thursday, October 26, 2006
Subscribe to:
Posts (Atom)