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
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.