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.
Sunday, December 31, 2006
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)