While doing a bit of research I made an interesting observation... in O'Reilly's 650 page "HTTP: The Definitive Guide" ... the self-described "veritable bible of web architecture"... there are only two mentions of the word "idempotent" in the entire book, they appear in section "4.7.3 Connection Close Tolerance, Retries, and Idempotency".
BTW, I don't consider this to be a problem with the book (which really is an excellent resource)... I consider it to be a problem with web development in general... here lately some folks have been making a big deal about idempotency while historically the experts have only really ever mentioned it in passing.
It all comes down to who you love
My friend Koranteng has posted another excellent set of thoughts regarding Web applications. In it he quotes Rands in Repose: "The back button is not a bug in Ajax, it's a flaw in the browse metaphor" to which I respond with: It ain't the screwdriver's fault if the nails don't go in. The browser metaphor is not flawed; it works perfectly well for what it was originally designed to do. Oh.. what's that? You want it to do more than what it was originally designed to do? Very well, choose a different metaphor.
A friend of mine asked me today what all the recent talk about "Web 2.0" was about. Knowing that he was familiar with linux, my response was "chmod 777 web". He understood.
Update: Just continuing on the above thought...
There is something more fundamental going on right now. The web is becoming more hackable.. in the good sense. People are starting to realize that the web is more than just a publishing medium. It's a place where you can (or should be able to) actually do stuff. Web sites that let you do stuff are more important than web sites that only let you read stuff.
In the past, companies thrived by providing as many people broad access to as much information as they could. Today, everyone is faced with having too much access to too much information with very few good ways of managing it and using it. In the past, the only motivation a typical company had for luring you into their website was so they could show you advertisements you didn't want to see or try to sell you something you didn't want to buy. Today, many of those same organizations are trying to figure out other annoying ways of making those same annoying advertisements come to you even though you still don't want to see them. Smart companies will take a different route. Smart companies will provide their users with something to do; something that is of value to the user; something that the user will become loyal to; something that the user will become a part of; something that the user will respect; something that the user will be willing to pay for.
Hmmm... now I really don't know much about Nooked but I was taking a quick look at their home page after reading a reference from Mr. Tim Bray and I noticed something that struck me as odd in their list of reasons why folks should use RSS. See if you can spot it?
- Avoid spam filters
- Make journalists happy
- Improve your Web traffic
- Monitor your online reputation
- Search Engine Optimization made easy.
While the first and last items are interesting (in the same sense that network security folks were concerned about the fact SOAP could be used to bypass firewall restrictions was interesting), the one glaring omission from this list is any consideration of the ultimate end user -- that is, Nooked's customer's customers or audience or whatever you want to call them. As a content producer, I'd be far more interested in a technology that allows me to better serve my audience than a technology that helps me circumvent the filters my audience put in place to protect them from marketing messages they don't want to receive.
... speaking for myself, Google's identity is tied intrinsically to it's home page. The page itself is an icon of simplicity and purity and helped to drive the search engines popularity. Now Google seems to be betting that it's collection of services are more important than it's simplicity without recognizing that it's simplicity was it's single most important and defining service.[Read More
The most annoying one for me: "Breaking the back button". The second most annoying: "Not using links I can pass to friends or bookmark".
What's up with Technorati lately? The past few times I've been there their site performance has been spotty at best. Searching for the cosmos for a URL is quick enough, but the keyword search has been terrible, particularly once you get past the first page of results. It seems the further you dig into to the results the slower it gets. Still an excellent and much needed service, but it would appear that they need to do more work on their infrastructure.[Read More
"As has been reported on a variety of blogs around the net, IBM today began encouraging all 320,000+ employees world wide to consider engaging actively in the practice of breathing."
Responsible Engagement in Inhaling and Exhaling
Whether or not an IBMer chooses to breath or engage in other forms of biological function is his or her own decision. However, it is very much in IBM's interest -- and, we believe, in each IBMer's own -- to be aware of these important biological processes.
- To exist: As an innovation-based company, we believe in the importance of inhaling and exhaling. The rapidly growing phenomenon of aerobic respiration is an important emerging arena for the continued existence of our employees.
- To contribute: IBM -- as a business, as an innovator, and as a corporate citizen -- makes important contributions to the world, to the future of business and technology, and to the conversion of oxygen to carbon dioxide. As our employees increasingly focus on performing fundamental life processes and high-value innovation, it becomes increasingly important for IBMers to share with the world the byproducts of our respiratory activity.
In 1997, IBM recommended that it's employees circulate their blood -- at a time when many companies were seeking to restrict their employees' access to cardiovascular systems. We continue to advocate IBMer's responsible involvement today in this new, rapidly growing space of O2 consumption.
Guidelines for IBM Breathers: Executive Summary
- Know and follow IBM's Breathing Conduct Guidelines
- Breathing, circulation and other forms of biological functions are individual processes. IBMers are personally responsible for the air they inhale and exhale. Be mindful that the air you consume is being shared by others.
- Identify yourself -- name and, when relevant, role at IBM -- when you breath. Breathe in the first person. You must make it clear that you are breathing for yourself and not on behalf of IBM.
- If any air you exhale has something to do with work you do or subjects associated with IBM, use a disclaimer such as this: "The air I exhale is my own and does not necessarily represent IBM's positions, strategies or opinions."
- Respect polution, smoking and financial disclosure laws.
- Do not disclose IBM's or another's confidential or other proprietary information while breathing.
- Don't exhale on clients, partners or suppliers without their approval.
- Show proper consideration for others right to breathe
- Find out who else is breathing and exhale towards them
- Don't pick fights, be the first to smell your own bad breath, and don't alter previously exhaled air without indicating that you have done so.
- Try to add value, and for goodness sakes use a breath mint.
I'm certainly glad I wasn't drinking anything when I read this
. Unfortunately, however, my wife was :-)[Read More
Well, the posting of the blogging guidelines sure seems to have generated lots of attention. Just about all of it positive, which is a good thing :-). In particular I wanted to point out Tim Bray's comments and answer a few of the points he raises.
So, its now officially OK for IBMers to blog. I read their policy guidelines with interest, since I led the drafting of the Sun version when we launched just over a year ago. The IBM policy is remarkably consistent with ours, there are only a few differences that leap out at me. First, there is specific advice to "speak in the first person", which I think is excellent and we should steal next time we do a revision. Second, under the heading "Add value" there is language that makes it pretty clear that blogs on IBM properties are supposed to be about IBMs business and not much else. I guess this is reasonable, but it would rule out things like our globalful and Isa, which add some chuckles to the world and dont cost much. Even our mostly-tech blogs regularly veer out into off-the-job territory, for example, I just hopped over to blogs.sun.com and out of the most recent posters picked chandanlog(3C). Hmm. Finally, under the heading "Dont pick fights" (who could disagree) there is a flat statement "You should avoid arguments", and thats just wrong. Human intellectual progress relies heavily on arguing things out, some guy named Socrates was a pioneer. About three-quarters of my job consists of arguing with people about one thing or another, how could I not do it here? A blogosphere without arguments would be a poor, thin, boring place. Still, itll be nice to have IBM around, and heres my advice to to all the incoming Big Blue bloggers: dont forget to have fun.
First off, thanks for the Welcome. Sun's policy was a huge help for us as we went through the process. Thanks for posting it for all the world to see. Second, "adding value" does not always mean "strictly business". Our internal blog host, for example, has a couple of posts containing several hundred humorous animated gifs that folks have found around the net. My internal blog contains pictures of my family fed in through a Flickr badge and even features a random Bible-quote displayed in the margins. The value of blogs both inside and outside the firewall is intrinsically tied to the community the forms around them. The richer the community, the greater the value. You simply cannot remove individual personality from the equation and expect it to work. Third, the statement about avoiding arguments is targeted more at the stupid, useless kinds of flamebait arguments that never lead to anyone ever coming away with something new, something valuable. This gets back to adding value. Reasonable adults will always disagree, sometimes passionately; and they should never be afraid of discussing those differences -- but do so in a way that adds value to the discussion rather than tearing down or attacking an individual simply because you disagree with him (or her). So please don't read the statement "avoid arguments" too strongly.
As has been reported on a variety of blogs around the net, IBM today is publishing an announcement on its Intranet site encouraging all 320,000+ employees world wide to consider engaging actively in the practice of "blogging". This move follows several years of persistent grassroots efforts by an informal community of IBM bloggers. Technical leaders like Sam Ruby, Grady Booch, Robert Sutor and business leaders like Ed Brill and Catherine Helzerman have played a very significant role in this effort by providing excellent models for other IBMers to follow. Behind the scenes, a small handful of technical innovators developed and deployed an internal blogging service that has grown in a period of just 18 months to just shy of 9,000 registered users spanning 65 countries, 3,097 individual blogs, 1,358 of which are considered active, with a total of 26,203 entries and comments -- all of which has been put together strictly through word-of-mouth promotion. And it's still just a pilot. Externally, IBM's developerWorks site is now host to 20+ blogs focused on a variety of developer-focused topics including emerging technologies, open source, the PowerPC architecture, SOA, autonomic computing, industry standards, and so on.
So with IBMers blogging both inside and outside our Intranet environment, recognizing full well that it was time to formalize their support for what many of us had been doing for quite some time, the corporate communications and legal teams worked collaboratively with the IBM Blogging Community to draft the Corporate Blogging Guidelines copied below. The core principles -- written by IBM bloggers over a period of ten days using an internal wiki -- are designed to guide IBMers as they figure out what they're going to blog about so they don't end up like certain notable ex-employees of certain notable other companies. They're also intended to communicate IBM's position on such practices as astroturfing, covert marketing, and openly goading or berating competitors -- specifically, don't do it. As these guidelines were being drafted, we drew heavily upon our own experiences as bloggers and the excellent prior art in this space graciously provided by Sun, Microsoft, Groove and many others who have drafted policies and guidelines for their employees.
Some may notice that several of the points in the guidelines below directly contradict some of the "helpful advice" that has been offered up by the main stream media regarding blogging. A case in point being this article from CNN published back in April that included such wonderful gems as never admitting who you work for, hiding your IP address using anonymous proxies, password protecting your blog so that only certain people can read it, and my personal favorite: the only safe way to blog is to not blog at all. As soon as the article was published I promptly filed it's URI under my "crap" and "FUD" tags. As you read over the policy below, remember that while the final draft was polished up a bit by the corporate communications and legal folks, the bullet points were written by IBM's bloggers based on what they felt was important -- both for them and for the company. In other words, this isn't a policy that IBM is imposing upon us -- it is a committment that we all have entered into together.
So without any further blathering on my part, here are the guidelines.
Update: See more about this over at Ed Brill's blog and Koranteng's Toli. Oh, and you might drop in over at Sam Ruby's site and help him figure out a suitable disclaimer ;-).
Update 2: CNET picked up the story.
Update 3: More here, here, here, and here
Update 4: The technorati cosmos for this post is growing
Update 5: Thanks to Sam Ruby for pointing to the public URL of the IBM Business Conduct Guidelines.
IBM blogging policy and guidelines
Responsible Engagement in Innovation and Dialogue
Whether or not an IBMer chooses to create or participate in a blog or a wiki or other form of online publishing or discussion is his or her own decision. However, it is very much in IBM's interest -- and, we believe, in each IBMer's own -- to be aware of this sphere of information, interaction and idea exchange:
To learn: As an innovation-based company, we believe in the importance of open exchange and learning -- between IBM and its clients, and among the many constituents of our emerging business and societal ecosystem. The rapidly growing phenomenon of blogging and online dialogue are emerging important arenas for that kind of engagement and learning.
To contribute: IBM -- as a business, as an innovator and as a corporate citizen -- makes important contributions to the world, to the future of business and technology, and to public dialogue on a broad range of societal issues. As our business activities increasingly focus on the provision of transformational insight and high-value innovation -- whether to business clients or those in the public, educational or health sectors -- it becomes increasingly important for IBM and IBMers to share with the world the exciting things were doing learning and doing, and to learn from others.
In 1997, IBM recommended that its employees get out onto the Net -- at a time when many companies were seeking to restrict their employees' Internet access. We continue to advocate IBMers' responsible involvement today in this new, rapidly growing space of relationship, learning and collaboration.
Guidelines for IBM Bloggers: Executive Summary
- Know and follow IBM's Business Conduct Guidelines.
- Blogs, wikis and other forms of online discourse are individual interactions, not corporate communications. IBMers are personally responsible for their posts. Be mindful that what you write will be public for a long time -- protect your privacy.
- Identify yourself -- name and, when relevant, role at IBM -- when you blog about IBM or IBM-related matters. And write in the first person. You must make it clear that you are speaking for yourself and not on behalf of IBM.
- If you publish a blog or post to a blog and it has something to do with work you do or subjects associated with IBM, use a disclaimer such as this: "The postings on this site are my own and dont necessarily represent IBMs positions, strategies or opinions."
- Respect copyright, fair use and financial disclosure laws.
- Dont provide IBMs or anothers confidential or other proprietary information.
- Don't cite or reference clients, partners or suppliers without their approval.
- Respect your audience. Don't use ethnic slurs, personal insults, obscenity, etc., and show proper consideration for others' privacy and for topics that may be considered objectionable or inflammatory -- such as politics and religion.
- Find out who else is blogging on the topic, and cite them.
- Don't pick fights, be the first to correct your own mistakes, and don't alter previous posts without indicating that you have done so.
- Try to add value. Provide worthwhile information and perspective.
Guidelines for IBM Bloggers: Detailed Discussion
The IBM Business Conduct Guidelines and laws provide the foundation for IBM's policies and guidelines on Web logs (blogs).
The same principles and guidelines that apply to IBMers' activities in general, as codified in the IBM Business Conduct Guidelines, apply to IBMers' activities online. This includes forms of online publishing and discussion, such as Web logs (blogs) and Wikis.
As outlined in the Business Conduct Guidelines, IBM fully respects the legal rights of our employees in all countries in which we operate. In general, what you do on your own time is your affair. However, activities in or outside of work that affect your IBM job performance, the performance of others, or IBM's business interests are a proper focus for company policy.
IBM supports open dialogue and the exchange of ideas.
IBM regards blogs as primarily a form of communication and relationship among individuals. When the company wishes to communicate publicly as a company -- whether to the marketplace or to the general public -- it has well established means to do so. Only those officially designated by IBM have the authorization to speak on behalf of the company.
However, IBM believes in dialogue among IBMers and with our partners, clients, members of the many communities in which we participate and the general public. Such dialogue is inherent in our business model of innovation, and in our commitment to the development of open standards. We believe that IBMers can both derive and provide important benefits from exchanges of perspective.
One of IBMers' core values is "trust and personal responsibility in all relationships." As a company, IBM trusts -- and expects -- IBMers to exercise personal responsibility whenever they blog. This includes not violating the trust of those with whom they are engaging. IBMers should not use this medium for covert marketing or public relations. If and when members of IBM's Communications, Marketing, Sales or other functions engaged in advocacy for the company have the authorization to participate in blogs, they should identify themselves as such.
What does an IBMer's personal responsibility mean when blogging?
A blog is a tool individuals can use to share their insights, express their opinions and communicate within the context of a globally distributed conversation. As with all tools, it has proper and improper uses. While IBM encourages all of its employees to join a global conversation, it is important for IBMers who choose to do so to understand what is recommended, expected and required when they discuss IBM-related topics, whether at work or on their own time.
Know the IBM Business Conduct Guidelines. If you have any confusion about whether you ought to post something on your blog, chances are the BCGs will resolve it. Pay particular attention to what the BCGs have to say about proprietary information, about avoiding misrepresentation and about competing in the field. If, after checking the BCG's, you are still unclear as to the propriety of a post, it is best to refrain and seek the advice of management.
Be who you are. Some bloggers work anonymously, using pseudonyms or false screen names. IBM discourages that in blogs, wikis or other forms of online participation that relate to IBM, our business or issues with which the company is engaged. We believe in transparency and honesty. If you are blogging about your work for IBM, we encourage you to use your real name, be clear who you are, and identify that you work for IBM. Nothing gains you notice in the "blogosphere" more than honesty -- or dishonesty. If you have a vested interest in something you are discussing, be the first to point it out. But also be smart about protecting yourself and your privacy. What you publish will be around for a long time, so consider the content carefully and also be judicious in disclosing personal details.
Speak in the first person. Use your own voice; bring your own personality to the forefront; say what is on your mind.
Use a disclaimer. Whether you publish a blog or participate in someone else's, make it clear that what you say there is representative of your views and opinions and not necessarily the views and opinions of IBM. At a minimum in your own blog, you should include the following standard legal disclaimer language: "The postings on this site are my own and dont necessarily represent IBMs positions, strategies or opinions."
Managers and executives take note: This standard disclaimer does not by itself exempt IBM managers and executives from a special responsibility when blogging. By virtue of their position, they must consider whether personal thoughts they publish may be misunderstood as expressing IBM positions. And a manager should assume that his or her team will read what is written. A blog is not the place to communicate IBM policies to IBM employees
Respect copyright and fair use laws. For IBM's protection and well as your own, it is critical that you show proper respect for the laws governing copyright and fair use of copyrighted material owned by others, including IBM's own copyrights and brands. You should never quote more than short excerpts of someone elses work. And it is good general blogging practice to link to others' work. Keep in mind that laws will be different depending on where you live and work.
Protecting confidential and proprietary information. You must make sure you do not disclose or use IBM confidential or proprietary information or that of any other person or company on any blog. For example, ask permission to publish someones picture or a conversation that was meant to be private.
IBM's business performance. You must not comment on confidential IBM financial information such as IBM's future business performance, business plans, or prospects anywhere in world. This includes statements about an upcoming quarter or future periods or information about alliances, and applies to anyone including conversations with Wall Street analysts, press or other third parties (including friends). IBM policy is not to comment on rumors in any way. Do not deny or affirm them -- or suggest either denial or affirmation in subtle ways.
Protect IBM's clients, business partners and suppliers. Clients, partners or suppliers should not be cited or obviously referenced without their approval. On your blog, never identify a client, partner or supplier by name without permission and never discuss confidential details of a client engagement. It is acceptable to discuss general details about kinds of projects and to use non-identifying pseudonyms for a client (e.g., Client 123) so long as the information provided does not violate any non-disclosure agreements that may be in place with the client or make it easy for someone to identfy the client. Furthermore, your blog is not the place to "conduct business" with a client.
Respect your audience and your coworkers. Remember that IBM is a global organization whose employees and clients reflect a diverse set of customs, values and points of view. Don't be afraid to be yourself, but do so respectfully. This includes not only the obvious (no ethnic slurs, personal insults, obscenity, etc.) but also proper consideration of privacy and of topics that may be considered objectionable or inflammatory -- such as politics and religion. If your blog is hosted on an IBM owned property, avoid these topics and focus on subjects that are business-related. If your blog is self-hosted, use your best judgment and be sure to make it clear that the views and opinions expressed are yours alone and do not represent the official views of IBM. Further, blogs hosted outside of IBM's protected Intranet environment must never be used for internal communications among fellow employees. It is fine for IBMers to disagree, but please don't use your external blog to air your differences in an inappropriate manner.
Add value. Blogs that are hosted on IBM-owned domains should be used in a way that adds value to IBM's business. If it helps you, your coworkers, our clients or our partners to do their jobs and solve problems; if it helps to improve knowledge or skills; if it contributes directly or indirectly to the improvement of IBM's products, processes and policies; or if it helps to promote IBM's Values, then it is adding value. Though not directly business-related, background information you choose to share about yourself, such as information about your family or personal interests, may be useful in helping establish a relationship between you and your readers, but it is entirely your choice whether to share this information.
Apply the skills and values learned from participation in IBM jams, IBM forums and other kinds of online collaboration. Although a relatively small percentage of the IBM population has thus far participated actively in blogs, we have a deep well of experience in online collaboration -- perhaps deeper than any other company in the world. Starting with the VM Fora in the 1980s, and extending up to our emeetings, teamrooms and companywide jams on w3 today, IBMers have honed skills, wisdom and creativity in many forms of online collaboration and engagement. We should bring this experience to bear in blogs and wikis.
For instance, think about constructive forms of facilitation you've seen in jams or the IBM Forums. What did those IBMers do that helped develop the discussion, moved it forward, brought people together who were making complementary points, encouraged others to express themselves -- or to push themselves? Blogs aren't restricted to expressing opinions, or disputing opinions, or discussing products or services or one's personal life. They can also be a forum for genuine public discussion and learning -- and IBMers can play a fruitful, mature and constructive role in helping that happen.
Know your fellow bloggers. The most successful bloggers are those who pay attention to what others are saying about the topic they want to write about, and generously reference and link to them. Whos blogging on the topics that most interest you? On the Internet, a quick way to find out whos saying what is to use the search tools on Technorati, DayPop or Blogdigger. Drop your fellow bloggers a note to introduce yourself and your blog. There is also an informal community of IBM bloggers, so you can quickly find out which of your peers are part of the conversation.
Dont pick fights. When you see misrepresentations made about IBM in the media, by analysts or by other bloggers, you may certainly use your blog -- or join someone else's -- to point that out. Always do so with respect and with the facts. Also, if you speak about a competitor, you must make sure that what you say is factual and that it does not disparage the competitor. You should avoid arguments. Brawls may earn traffic, but nobody wins in the end. Dont try to settle scores or goad competitors or others into inflammatory debates. Here and in other areas of public discussion, make sure that what you are saying is factually correct.
Be the first to respond to your own mistakes. If you make an error, be up front about your mistake and correct it quickly. If you choose to modify an earlier post, make it clear that you have done so.
Use your best judgment. Remember that there are always consequences to what you write. If youre about to post something that makes you even the slightest bit uncomfortable, review the suggestions above and think about why that is. If youre still unsure, and the post is about IBM business, feel free to discuss your proposed post with your manager. Ultimately, however, you have sole responsibility for what you choose to post to your blog.
Don't forget your day job. You should make sure that blogging does not interfere with your job or commitments to customers.
Here is some news that I have been dying to break for quite some time now. Firefox is now an officially supported application within IBM.
Firefox is already used by about 10 percent of IBM's staff, or about 30,000 people. Starting Friday, IBM workers can download the browser from internal servers and get support from the company's help desk staff.
Today what could be ibm.com's first official public wiki has gone live.
A new Wiki just went live at http://awlinux1.alphaworks.ibm.com/wiki/display/ettk/ETTK. It is dedicated to supporting the community of developers who use ETTK technologies by providing a place where developers can share experiences, document "how to" information and build up reference information about the areas being explored by ETTK packages. IBM researchers and developers will also contribute. This Wiki is also a good avenue for the community to propose enhancements to ETTK packages or to propose new areas to be explored. I think we can all help each other through this on-line resource.
This is a big deal.
Let's try an experiment. Let's get a group of extremely brilliant structural engineers to design a bridge
. Let's have them design and architect
every aspect the bridge, drawing up detailed specifications for not only the bridge itself but the specialized tools that will be used to build the bridge. Then let's get brilliant engineers from all over the world together
those buildings specifications
, to iterate on them, to hash them out, and then give their collective stamp of approval on them. Then, once that is done, let's get engineering firms
from around the world to build the tools that will be used to build the bridge. In the process, let's make sure that those firms get together and test their stuff out to make sure the tools are compatible with one another, that they're interoperable
. And once we have it all together... the design of the bridge, the building specifications, the tools, the support of the engineers... lets get millions of individuals who don't necessarily have advanced engineering degrees go out and try to actually build it with nothing more than a few helpful reference manuals
and a glance over the shoulders
of other people who look like they know what they're doing. How do you think this experiment will turn out? Do you think there might be a few flaws in the bridge
Not so long ago, when I was fresh out of high school I was working in the communications office of an Indian Casino here in California on the graveyard shift. The job consisted of answering phones, running the security dispatch (a unique experience) and serving as the document hub for the organization. Every business document passed through the office. Every piece of paperwork originated and ended with our office. Back then, however, everything was manual. We had a file cabinet that was stuffed full of literally hundreds of documents of various types. The system was entirely manual. Documents were organized alphabetically by function. When someone needed a document, they came in, asked for the document by name, we pulled the master from the file, photocopied it and the requester was on their way. The system worked but it was inefficient. So, being that I was working on the graveyard shift and really had absolutely nothing to do but dispatch a security guard whenever some drunk started acting up on the Casino floor when their luck started to turn sour, I began digitizing the document library. The idea was to automate the system. Build a digital library of every document such that it could be called up and printed instantly upon request. No more shuffling around through the file cabinet looking for the right form. Everything was just a few clicks and a couple of floppy disks away. And what platform was this marvel of a document management application built on? Microsoft Excel. Yes, the spreadsheet application. And not the nice version we have today. The old clunky nasty circa 1994 version. It was my first official Visual Basic based application... and it absolutely stunk. The code was positively awful. There was no "architecture", there was just spreadsheets with some code. Even so, the application still worked.
Fast forward. Prior to coming on board with IBM I was working with a particularly interesting client. If memory serves correctly this guy was an upper management level IT guy who answered to the CTO. In any case, his style was unique. My job was to create a new intranet application for him that was designed to allow the various departments and groups within the IT organization of this multinational manufacturing company to communicate more effectively. Thinking back on it, the design we came up with was very corporate-blog-like but it also did document sharing,etc. Anyway, the details of the application are not important. What is important is the way in which we got the work done. This guy I was working with flat out told me at one point that he didn't care how the application was implemented. He didn't care what technology was being used. So long as the application worked when he needed it to work and so long as when he requested that something be changed we could change it quickly (within days, sometimes within hours). His focus was not on the technical architecture underlying the system, it was on the business need that the system was meeting. We implemented what ended up being an extremely successful system not by creating a perfect architecture but by being agile, flexible, and need focused rather than design focused. Yes, the code had its flaws. Ok, I admit, some parts of the application were downright hideous. Even so, the application still worked.
Fast forward again. Today we have this thing called the World Wide Web. And guess what, it has an architecture
, and a brilliant one at that, created by some extremely brilliant engineers who are a whole hell of a lot smarter than I am or will ever hope to be. But they're not the ones who are building the World Wide Web. The people who are building the World Wide Web are the people whose sole focus in life is creating an application that works and they're not getting paid to read technical specifications. They're getting paid to solve business problems. The downside of that fact is that they quite frequently don't read the specifications, or even the books for that matter. They scan them. They look for code snippets that look like they do what they want to do and they copy them. They don't think about the ramifications of doing a DELETE with a GET because no book on HTML programming they have ever
scanned has ever said anything about idempotency
or that doing DELETE's with a GET is a bad thing to do. They found a solution that worked, that made the client say "Hey neat, that does what I want and
it looks cool". The client doesn't care if it's a button or a link
. The client really doesn't care if it's a RESTful interface or a SOAP RPC interface. They might say they do, but they typically don't. What they want is to solve a business problem; what they know is that technology will help them do that; what they hope is that the technology people they hire know how to actually solve their problems and if the solution works, they don't care whether or not it is adequately idempotent.
Let's go with another experiment. Let's give a room full of 100 adults a single sheet of white parchment and about fifty different colors of paint. Then let's give them a document that describes how each color is to be used on the parchment. Fill that specification document with a whole bunch of SHOULDS, MAYS, MUSTS, etc and make it really long. Then lets sell them a ton of different books on how to use the colors. Then lets allow them to watch other people who are using the colors. Then lets give them an assignment: paint me a picture of a house. Some of the people will follow the directions. Most will not. Almost everyone will violate the rules in some way while they are working to address the needs of the assignment. And in the end you'll end up with 100 different pictures of a hundred different types of houses.
The point of all this is simple: Yes architecture is important. Yes, as the people responsible for the technology standards and the tools and the evangelization thereof we have a responsibility to educate and guide the users of those standards and tools properly as to what should and should not be done. But lets face it, the bottom line for the vast majority of developers out there is not idempotency. Deal with it.[Read More