The Unfortunate Lip Service Paid to Design

May 22, 2012 in software design, ui engineering | Leave a comment

I will admit that I don’t have enough natural talent at coding that I can just sit down and code an entire application off the top of my head. So I use UML (and in the past the Booch method) to engineer my applications before I write one line of code. Design has always helped me get most of my issues worked out before I code so that when I’m ready develop, it’s all about execution; rarely do I have to stop to second-guess what I’m doing because I’ve already worked it all out in my head, and more importantly, created a map for myself to help guide my development. This practice is something I just learned on my own after failing so many times. Call me a little anal-retentive about going through this process, but I’ve had nothing but success developing applications in this fashion.

It used to bother me that for the most part, I’d be the only one designing my software before I actually built it. Hell! Everyone around me took their specs or mockups, sat down and churned out code! It used to make me uncomfortable. But it no longer makes me uncomfortable because those very same people are the ones who spend lots of time paying off technical debt. Now I think that if they just invested even a little time working out their design before they code, they wouldn’t have to spend so much time grinding their apps or components into submission. But that’s how it is with most of the software development world.

Getting to the crux of this article, almost every engineer I’ve spoken with regarding the virtues of design agrees that it’s valuable – and I’ve spoken hundreds on this subject. But only a handful have actually adopted the process of designing before you build. That doesn’t hurt my feelings though, because I figure if I can reach just a few, they’ll hopefully teach others. And those of whom I have taken under my wing to teach the process have gone on to be some of the finest software engineers in the industry, and sought after by many companies. The software they produce is bullet-proof, and it all started with design.

Despite the agreement that software design is a valuable step in the development process, overall, I’ve that that agreement ultimately is lip-service. I think many developers see it as a time sink that will take away valuable development time. I can’t tell you how many times I’ve heard something like this: “I have a deadline and can’t take the time to learn this.” But I always contend that if you start simple, the time investment is minimal. For instance, I always instruct people to start with a simple class diagram. That way they can identify the objects they’ll have to build. Doing that one thing can solve so many issues due to not knowing who the actors in your play are. Then, if they’re ambitious they can move into drawing sequence diagrams for the critical object interactions. And for the most part, unless you need use-case or state diagrams, you really only need class and sequence diagrams. In the end, it’s not much of an investment in time.

Admittedly, as with any new thing to learn, velocity will be slower. But as you get better at it, you’ll be faster. And I have found, as have all who have adopted this practice, that not only does design get faster, but development gets faster, and even more importantly, the time spent paying off technical debt is greatly reduced. For instance, I know of a guy who has worked and re-worked the same damn component for 6 months! If he had only taken the time to sit down and work out a design, he could’ve been done in two weeks – maybe even sooner. But he’d release his work, find that it was missing some key features, then rework his code. Talk about wasting time!

I think what shocks a lot developers I speak with is when I tell them the proportion of time I spend on various tasks when I’m developing. I spend about 5% on requirements review, 80% on design, 10% on development, and 5% on debugging and technical debt. Those are fairly loose averages, but I’ve measured these over time. Before I became a practitioner of design, those numbers were more like: 5% on requirements review, 10% on design, 50% on development, and 35% on debugging and paying off technical debt. What’s the implication here? Look at the debugging and technical debt numbers. With a good design, you just don’t make that many mistakes. Most of my bug tickets tend to be cosmetic fixes in nature. I don’t get too many functional error tickets; again, that’s due to having done a thorough design. Also, with the change in proportion, my overall development time, including all the steps has been reduced by 30-40%. What used to take me several days to finish, now only takes me a day or two or even a few hours! But despite sharing those numbers, and people getting fired up about doing design, most simply don’t execute. It’s really a shame.

Eventually people will learn. But in the meantime, there’s going to be a lot of crappy code out there…

If MVC Is So Simple, Why Does It Get Screwed Up So Much?

May 21, 2012 in Uncategorized | Tags: , , | Leave a comment

Seems to me that there are lots of developers out there who have taken up the MVC banner, and charged forth into battle; silently crying out, “MVC! MVC! All apps should be MVC!” Or maybe it’s just me that did that… :) Regardless, over the last few years, lots of people have adopted the MVC design pattern as their pattern of choice. But from what code I’ve seen, especially in the JavaScript world, most of it plain shit as far as following the pattern is concerned.

The most egregious guffaws are confusing object roles in an MVC system. I don’t know how many times I’ve seen objects that cross the Controller-Model or Model-View or View-Controller boundaries; intermingling roles within a single object. Other things I’ve seen are people defining objects to fill a particular role, then do all communication via two-way direct reference between objects. Or worse yet, I recently saw some code where the developer was having a controller make his view trigger an event to which the same view was the only listener! Yikes!

One could just call it stupidity on the part of the developers, but I’ll be more forgiving and say that all that boils down to simple ignorance of how the objects – and more importantly, how objects communicate in any MVC system – should work; or just plain ignorance of what MVC is all about.

The Model-View-Controller paradigm at its most pure is quite simple: It’s all about separation of concerns, and consigning “concerns” to three, specific classes of objects – Model, View and Controller objects. Each class has a specific purpose and role. In this installment, I’m going to talk about each of these classes, and how they should be used to build successful MVC applications.

Model

A Model is an application’s representation of the underlying data set; in other words, it’s data. It has accessor methods in the form of getters and setters to manipulate the data. It does not or should not contain business logic. Unfortunately, some 3rd-party libraries such as Backbone.js muddy the waters a bit by adding things like the “validate” method to allow data validation within the context of the model. I’ve always found this to be just plain wrong. While you certainly can put logic in the model by virtue of JavaScript not having any barriers to doing so, muddying the waters in the model’s role in this respect I believe does more harm than good.

To me validation is really the job of the controller, which should be the one that “owns” the business logic. However, I’m also in favor of placing validation logic in the view to encapsulate it and remove some of the burden from the controller, since validation is really view-specific.

A model’s role is simply to store runtime data. Consumers of the model can get or set attributes on the model. But when that data changes, the model is only responsible to notify listeners that it has changed. To me, that’s it.

View

To me, there are two types of Views: Smart Views and Dumb Views. Smart Views have a bit of logic in them, namely input and output validation logic to make them “smart” per se, but as the endpoint objects – that is, the objects that clients actually “see” – they should never contain core business logic. Actually Smart Views are simply Dumb Views with some validation. Some have argued that a Smart View could also be one that includes Model functionality, but I don’t subscribe to that at all. I think object roles should be distinct, and Views are responsible for presentation of data contained in their associated model. Period. As for “Dumb” views. They simply exist to display model data (and update the model if they’re used for input), and update themselves when the model changes. Pretty straight-forward.

But with any view, I found that following the following rule-of-thumb has saved me countless hours of anguish, and that is simply: A View knows about its DOM and its DOM only. It knows about no other View’s DOM. This is extremely important to consider, especially if you’re using Backbone.js whose views are normally attached to existing HTML elements, and not blitting out their own HTML. When you create a Backbone view and assign its “el,” you have to make sure that no other view – as you can potentially have several views on a page – can manipulate DOM represented by that “el.”

Admittedly, when I was new to Backbone, coming from a system I helped create whose views all contained their own HTML, I broke this rule because hey! jQuery lets you get the reference to any HTML element so long as it’s in the DOM tree. But I ran into a bit of trouble when I had multiple views on a page accessing the same region of the page and using the same el. It was a nightmare to try to maintain. I no longer do that, as I’ve learned that lesson, but mark my words: Your view should only be responsible for a distinct “el.”

Controller

Especially in JavaScript, a Controller is almost superfluous, as it is mostly used as an instantiation device for models and views. But it can carry “safe” business logic; that is, business logic specific to the operation of the application that doesn’t expose trade secrets. It is also used to control application flow. Circling back to Backbone.js, in earlier versions of Backbone, the “router” object was called controller, but was later renamed to router. I think this was a smart move because a router is simply a history manager wrapper. It doesn’t control application flow. That’s the controller’s job.

For instance, I’m currently building an application  where I have a master controller that instantiates several sub-controllers representing sub-modules of the application. Based upon user input (a click of a button or a link on a page), the controller decides that module to instantiate and display. It then tells the router to update the route to reflect the “destination” in the browser’s URL. In this respect, I’m using the router simply as a view, as all it does is update the URL, or on the reverse, tells the controller to display the right module or section depending upon what was entered in the URL.

In other words, a controller is responsible for controlling application flow. That’s all it does. It can listen and respond to events in the model and views. It can even trigger events to other controllers. But in no way should it contain data manipulation or view functionality. Leave that to the models and views of the system.

Look, MVC is not rocket science. But it may feel as if it is especially if you’re doing it wrong. And believe me, lots of people are doing it wrong.

What’s Wrong with this Picture?

April 21, 2012 in compensation | Tags: , , | Leave a comment

I made this chart based upon data that was cited in a San Jose Mercury News article that I read in today’s Business section. When I read those numbers, it made me think, “What would this look like on a chart?” Reading it in print is one thing, but seeing it on a chart tells a pretty grim story. So what does this chart tell us? That as Netflix stock was plummeting, Reed Hastings’ stock option grants soared. Note that these awards were given each month listed in the chart. Rank and file employees get annual options grants, by the way.

I know that this chart paints a pretty bad picture. But if you add another data point to the graph, Value, then each grant would be worth approximately $1.25 Million, so obviously this was a pre-arranged package. So much for Hastings’ compensation to be tied to performance. Oh yeah, the compensation board will argue that the package will be reviewed yearly, and in Netflix’ case, they’ve indicated that Hastings’ comp package will be adjusted for this coming year based upon the performance of last year. That’s such a crock. The guy made some seriously bad moves last year which resulted in Netflix’ stock plummeting to almost a quarter of its value in just two months. Yet his compensation package guaranteed him a $1.25 Million monthly bonus irrespective of the performance of the company.

I wonder what kind of message that sends to Netflix employees?

Ever wonder why uprisings such as “Occupy” happen? You just have to read stories or hear accounts like the Hastings’ compensation package to find your answer. Look, I can totally buy into the leader of a company getting paid more than the rank and file, and in great times, I can see them getting handed handsome packages for their leadership. But what I can’t abide by is a situation like this where an executive’s compensation package is not adjusted immediately upon a loss in revenue or reduction in membership.

My thought is that if you’re going to tie compensation to performance, then at the very least, review performance with a high periodicity than just annually. And set up thresholds. For instance, at a certain net income level, an executive would get X in cash compensation and option grants. If there’s growth, then they would get more. But if net income falls or in the case of Netflix, there’s an exodus of customer base, then the compensation package would be adjusted down.

Makes sense, but the reality of the situation is that practices like this won’t be changing any time soon.

Don’t Be Afraid to Scrap Your Code

April 4, 2012 in JavaScript, ui engineering | Tags: | Leave a comment

I once got this “emergency” project where I had three weeks to deliver a mobile prototype application that was to be demonstrated at a major user conference. I spent the first week creating a UML design for the app – also looking for a back-end guy to build the Java API’s for me to call. Then spent a few days prototyping some assumptions and testing our JavaScript library’s capabilities on various phone-based browsers. Once I proved that out, I had roughly 7 business days – plus a weekend – to deliver the project.

Five days and almost 600 lines of code into implementation, I realized that I was doing a boatload of coding; way too much, writing lots of code that to address things that I hadn’t considered in my design. So I stopped coding, opened up my design, ran through the sequence diagrams and realized that what would’ve helped was having an intermediary object act as a ViewController and manage the various view objects. So went back to my class diagram, inserted the new object with the methods and properties that I expected it to have, re-worked my sequence diagrams then went back to my main JavaScript file and…

…completely erased it…

I mean, Select All -> Delete.

When I redid the code, I finished it with less than 50% of the original lines of code and actually checked it in with a day to spare. During testing, only cosmetic flaws were found, but no functional errors. I fixed those flaws and the prototype was released and demoed live at the conference in front of over 1000 people. The point to all this is that once I had the right design, the coding was absolutely simple and straight-forward. I wasn’t writing any compensatory code or dealing with deficiencies in my design because the design was right.

Moreover, erasing all my original work ensured that I wasn’t influenced by my old code. I had to start with a clean slate. But in the end, I still beat my deadline by a day.

Now, this isn’t something I recommend for huge projects, but as a rule of thumb, if you find that you’re writing a lot of code – especially with object-oriented JavaScript – chances are your design is flawed. At that point, stop, re-evaluate your design, and back up to a place in your code where you can adapt to the better design. Yes, sometimes that means getting rid of all of it, but most of the time, you can back up to a reasonable place without erasing all your code. But in either case, don’t be afraid to scrap code; especially if it means that the final product will be superior to what you originally created.

Shut Up and Develop

April 4, 2012 in Uncategorized | Leave a comment

In addition to writing this blog, I also write a fairly popular blog called GuitarGear. To write that blog, I interact a lot on various forums, and meet other guitarists. Especially in the forums, there’s lots of debate about which pedal or amp or guitar – what have you – works in a particular situation. Some of the threads go on for several pages. Invariably though, someone will pipe in and say something to the effect of, “Just shut up and play.”

Sometimes I feel like saying this when I’m in meetings with fellow geeks and a side debate starts on some topic; especially on the merits of one technical direction vs. another. In the best of cases, these discussions/debates yield a good direction; actually, in the end, they almost always yield a direction. But invariably, that direction could’ve been arrived at in a much shorter span of time. I think that part of the problem, especially with well-established teams is that everyone’s comfortable with each other. That’s both a good thing and a bad thing. It’s good that you can rely on your work mates, but that comfort can dangerously lead to losing “the edge” of urgency to deliver as you belabor points. The plain fact of the matter is that we have product to build; we shouldn’t be wasting time on trivialities. So shut up and develop!

Olympia Snowe Is My Kind of Republican

March 27, 2012 in politics | Tags: | Leave a comment

A friend at work often chides me in saying that despite the fact that I’m a Republican, how I speak about politics makes me a Democrat. I’m just as Republican now as when I first registered to vote when I was 18, and I still hold to the traditional Republican values of small government, individual freedom, and conservative – as in judicious, not political – financial responsibility. My friend teases me because I have a much more moderate position with respect to my politics, which focuses on the issues and not the ideology, so I suppose it must seem to him that since I don’t speak politics like 95% of the Republicans out there, I must be Democrat. He’d probably say the same thing about Maine Senator Olympia Snowe, who is one of the few moderate Republicans in Congress today, and who unfortunately is not running for re-election.

I read an article about her frustration with American politics today this morning, and despite the article’s title of “Frustrated Senator Olympia Snowe Give Obama an ‘F,’” the actual meat of the article focused on her general frustration with Congress. Here’s a quick excerpt:

“I think a lot of the frustration frankly in our party, in the Tea Party challenges or even Occupy Wall Street is really a reflection of our failure to solve the major problems in our country,” said Snowe. “It’s become all about the politics, and not the policy. It’s not about governing, it’s about the next election.”

So has this Congress failed the country on those critical questions?

“Absolutely,” Snowe asserted.  “You have to sit down and talk to people with whom you disagree,” said Snowe. ” And that is not what is transpiring at a time when we desperately need that type of leadership.”

What she said above mirrors EXACTLY what I’ve been talking about with others when discussing politics. Especially with my ultra-conservative friends, I’m often apt to say before going into a political discussion, “I’ll only engage in this discussion if we talk about the issue, not about the ideology. If you want to bitch about Obama did this or Obama didn’t do that, then let’s talk about how the Sharks are doing instead. Whether you like the guy or not, we have real problems in this country, and discussing political ideology is NOT going to solve them.” We usually end up talking about the Sharks…

Not Sure I Buy Into Science and Engineering Jobs “Losing Ground”

March 27, 2012 in Uncategorized | Tags: | Leave a comment

I read an article today that was published in yesterday’s San Jose Mercury News Business Section written by columnist Chris O’Brien entitled, “Key Job Sector Losing Ground,” describing how growth in science and engineering jobs over the past decade has remained flat relative to previous decades, and kind of being a doomsayer in that that flatness may have an effect on innovation. He does quote a researcher that said that perhaps that flat growth means a lack of demand for science and engineering jobs. Being in software engineering, I would tend to agree with that assessment. But I disagree that that flatness may lead to the possible constriction of innovation.

I think that the flatness is actually a correction of the excesses of the dot-bomb era. Even in 2007, there was a minor uptick in the technology sector, and several companies, including my former company, SuccessFactors, added LOTS of engineers in a very short period of time. Unfortunately, during a boom period, especially in technology, the focus tends to be on putting “butts in seats” quickly as opposed to getting the right butts in the right seats. I saw that at SuccessFactors, where we added lots of really mediocre engineers to our software development team. Most of these “engineers” were the typical, “code-first-think-later” code-monkey types. As a result, in 2008 when the economy soured, the company had to shed that excess and frankly, unneeded baggage.

I’m probably sounding a bit crass and elitist, but honestly, I truly believe that what’s happening with the technology job growth, especially here in Silicon Valley has more to do with companies being careful about choosing the right people to fill their employment needs, and choosing only those whom they feel will take them to the next level.

People talk about jobs being shifted off-shore. To me, it’s natural that they’d go there. Think about the jobs being shifted off-shore. I don’t think I’d be too far off the mark in saying that those are jobs that tend to be more maintenance and production-level types of jobs. The real innovation stays here. Even with my previous company SuccessFactors, despite senior management constantly saying that our engineering group was “global,” and always tried to blur the lines between domestic and offshore development, in reality, all the innovative work took place here in the States; and even new product development offshore followed the models and innovation established domestically. Plus their designs were always subject to approval from the US-based team. So in consideration of that, to me, this “flatness” is not really flatness. I believe it’s shedding the production and maintenance workers, and distilling down to a workforce of innovators here in Silicon Valley.

Call me insensitive, but as opposed to Mr. O’Brien, I’m in the industry, and have experienced the growth and decline of job number from behind the lines. Yes, I realize that I’m opining, but it’s not uneducated and not without experience in the sector.

Want Your Team to Write Maintainable JavaScript? Start Making Them Think Alike…

March 10, 2012 in JavaScript, software design, ui engineering | Tags: , , | Leave a comment

A colleague at work today posted a couple of JavaScript/Front-End Development conferences that are coming up in the near future. One of them, the O’Reilly conference has a speaker talking about writing maintainable JavaScript. I did a bit of searching on him speaking about this topic, and the material that he presents is generally pretty good – at least from a coding standpoint. But I think that focusing only on coding won’t solve the problem. From personal experience, nothing can mess up maintainable code more than bad or non-existent design practices.

I know I don’t get too much traffic to this blog, but for those who have read my technology articles, they’ll know that I have a real design focus. Why? Simply because high-quality, easily maintainable software starts with good design, and I have LOTS of personal experience in this. I was able to get roughly 200 front-end engineers at a previous company to code the same way – in a maintainable fashion – by first teaching them good design practices. It all started out with using UML as the way to communicate our designs, then writing good technical design documents to describe and discuss the diagrams, then writing code that followed the designs. Of course, included in the process were both design and code reviews ensuring that the final product that was produced with lots of input and feedback.

Most would think that adding all this onto the development process would tack on more time to development. Admittedly, at first it does. That’s the “learning tax.” But once people are used to doing designs, and going through a few review processes to defend their designs and code, they become faster at development; much faster than they were before they started practicing “design first, code later.” While this also requires an overall organizational acceptance, it’s an easy sell because the overall code quality will shoot through the roof.

Plus, doing design then coding is the fundamental difference between software engineers and code monkeys. I’ve been around long enough in this industry to say that most software developers, though they like to think of themselves as engineers are code monkeys; albeit, with varying levels of experience. The more experienced developers will most likely be able to tackle a problem and get it right a lot of the time, but to me, when there’s not a design to accompany the development, there’s always a risk that problems that could’ve been mitigated and avoided with a design will trickle through. That’s not to say that a design will mitigate all bugs. That’s ridiculous. But you can avoid lots of problems simply by doing a design and following it; that is, implementing code according to what’s described in the design.

To crystallize the point further, let me say this: Code is PRODUCT; design is engineering. And when people are designing in the same way, they will tend to adopt coding practices and standards that are similar and maintainable throughout the organization.

So which do you want to be, engineer or code monkey? If you’re not already doing design, you know who you are…

A Real Pet-Peeve

Now that I’ve pontificated on the virtues of design, I’ll discuss code. The speaker on writing maintainable JavaScript, Nicholas Zakas, is quite an engineer, currently a principal at Yahoo. But in reading through his blog and reading through the conference highlights, plus reading this article that he wrote on the subject, he missed a VERY important point that is one of the very things that pisses me of more than anything else and that is lack of comments. I’m very good about commenting my code simply because once I’ve got it checked in, I want to be able to get a gist of the flow when I return to it weeks, months, or years from when I wrote it. I also do it so that others who may maintain my code after I’ve left know what I’m doing in my code.

I’ll just say it plainly: Commenting code is Programming I; not 101. You should be commenting your code from the get-go. Period. It’s such a key component to team coding and writing maintainable code, but it is often missed in talks and lectures because it’s assumed people do it. Nick, believe me, they don’t. :)

Here’s a Problem I Have with UI Developer Job Requirements

March 8, 2012 in Uncategorized | Leave a comment

Here’s a job description I got in my inbox today.

LUCILE PACKARD OF STANFORD MEDICAL CENTER
Sr. UI/Front end Deveoper
Perm, Up to 115K
Top of the Line Benefits

Our client, Lucile Packard Foundation is looking for a permanent UI Developer to join their team immediately on a full-time basis. Please find the responsibilities below and let me know if you might have interest.

Skillset & Requirements:
•7+ years experience developing complex dynamic web applications
•Development and Collaboration w/ both small and large development teams
•Expert knowledge of HTML/XHTML
•Ability to write code without WYSIWYG editor
•Advanced Object Oriented JavaScript
•Experience with JavaScript libraries such as jQuery and DWR
•Practical knowledge of AJAX using JSON
•Proficient in the implementation of Cascading Style Sheets
•Skilled in the use of CSS Selectors
•Competent in Web Design and graphic creation
•Experience w/ WebSphere or WebLogic is a plus

Notice I bolded the “Advanced Object Oriented JavaScript” line. This is the problem that I have with this job requirements list: The very next line mentions jQuery. Every time I see requirements lists like this it almost invariably means that they’re really not doing OOP JavaScript. Oh, they use objects and such, but their actual implementation of OOP tends to be fairly limited. Another problem related to that line is that there is not associated line that requires object oriented analysis and design. Essentially, that shop is doing DOM-level stuff. The effects are cool, but I can tell that the position is pure coding, very little engineering.

Having gone through many interviews in the latter half of last year, when I’ve interviewed with companies who have these kinds of descriptions, invariably, when they post requirements like this, they’re only paying lip-service to actual object-oriented programming. And if they do indeed do OOP, they design by code, which raises a HUGE red flag for me. Only a couple of companies that I interviewed with (one of which I joined) did some level of design, or at least wanted to begin a process that included design. Now by design, I don’t mean visual design, but engineering design, which includes UML diagrams (or industry-standard diagramming), and technical design documents. The best company that I interviewed with up in San Francisco actually spent the better part of the interview grilling me on an object diagram they had me create based upon a set of animals within a fictitious animal kingdom. I had to create the object hierarchy, and also draw out simple sequence diagrams to illustrate the interactions between the animals and their “world.” Very cool stuff, and just about the best interview I had ever gone through.

Unfortunately, a lot of companies just don’t take the time to do real engineering design. Most internet-based companies engage in “agile” development. Gawd I hate that term, mainly because practicing it has been so bastardized. What many organizations just don’t realize is that Agile development requires so much more developer discipline than most engineers are willing to commit. This is exacerbated by pressure from sales and product management to constantly deliver features and the time allotted for delivery just doesn’t allow for taking the time to do design.

As for the last line in the previous paragraph, that’s actually horseshit. In my experience, with good developer discipline, you can actually deliver more in the same amount of time because you don’t waste time flailing around with code. If you discipline yourself to design what you’re going to build, then coding is simply connecting the dots. It may seem counter-intuitive, but I will posit that if you’re not spending at least 60-75% of your development time designing, you’re really not being very productive. Food for thought.

On Glenn Beck and Global Warming and the Danger of Fox News

February 19, 2012 in politics | Leave a comment

I am so glad Glenn Beck is off the air. That man was an absolute cancer to American politics. The irresponsibility of his claim there was no evidence of global warming has set back the movement to help heal our planet for years (I won’t even touch on his negative influence on controlling Wall Street). I started getting clued in on his negative influence when a very close friend and I had a heated debate about global warming. As a faithful watcher and listener of Glenn Beck, he just spouted back what Beck said: There was no evidence of global warming. I was amazed by that claim, after having read scientific evidence to the contrary! My friend challenged me to provide evidence right then and there – and as we were on the phone, he knew it wasn’t possible. In any case, he was so firm in his position, that nothing I said would make him even consider the possibility.

It completely amazed me that my friend, whom I believed to be reasonable could be utterly and complete brainwashed by a known “shock jock” who was hired by Fox News Channel simply to incite the angst and anger of people. Way to go Fox, mission accomplished! You managed to drive a wedge into US politics where we’ll be cleaning up the mess for years to come, as this article from the Huffington Post relates.

I read that article last year and wanted to throw it into the face of my friend; tell him that his devotion to this wacko was dangerous, and that following the advice of someone who didn’t even believe this stuff he was saying would simply create a greater divide between conservatives and liberals. Okay, deep breath… Circling back to the issue of global warming, what really set me on the edge was what that article said about Glenn Beck’s personal position on global warming vs. what he actually said on his show,

Let’s take the example of climate change. There was a time when mainstream Republicans like John McCain, Lindsey Graham and Tim Pawlenty thought that man-made climate change was a real problem and that government had a role in fixing it. Then Beck and friends on Fox News Channel and talk radio in went to work. Beck’s role in all this is remarkably cynical, as he told USA Today Weekend that he personally believed in climate change — “you’d have to be an idiot not to notice the temperature change,” he said — but said the complete opposite on the air. “Americans know this global warming thing is a scam,” he proclaimed on the radio.

When I read that, I just about screamed out in rage! Here was a man who single-handedly defeated any kind of measure to control a serious problem by getting his listeners and viewers to follow what he said on his shows and put pressure on their representatives such that Republicans who were once in favor of global warming legislation completely turned their backs on it!

Months ago a study was released that Fox News viewers were less informed than those who don’t watch the news. I don’t think it suggests anything about their level of intelligence, but to me, it suggests that Fox News isn’t really focused on news, but on commentary and opinion on a a narrow set of issues that they know will incite the anger of their viewers. Rather amazing, but I believe the net effect coming from this type of “journalism” is that it has completely changed the face of American politics from open debate on issues to arguing on whose ideology is better. Throughout history, we’ve seen what governance through ideology gets us: pre-WWII Germany and Russia.

The thing that is very frightening to me is the Republican fixation on ideology. It is turning people who I have known to be great debaters and political conversationalists – such as my close friend whom I mentioned above – into ideologues. No longer do they try to get their news from a variety of sources; no, they get their news from sources that simply fit their ideology. Worse yet, they’re unabashed about regurgitating everything they read.

Another person whom I know well is particularly prolific at ideological regurgitation. I used to have a lot of respect for him, as he is a very successful attorney, and one with whom I used to have intelligent conversations on various issues. But now, he has been reduced to yet another Obama-hater, using Facebook to post link after link on why “Obama is this…” or why “Obama is that…” What a waste of a brain.

You’ve got to hand it to Fox and their ilk: They’re powerful enough to sway people – super-smart people – away from intelligent and respectful debate. But that’s where the danger lies. If we allow emotion – especially anger – affect our thinking, we’ll never come together as a country. But this seems to be Fox’s goal. Appeal to the angst and you can get millions to move. Fox gets ratings that drives in revenue. But the losers are the people. It’s saddening to see what’s unfolding before our very eyes.

Follow

Get every new post delivered to your Inbox.