Microsoft unveiled its UI Automation capabilities for VSTS 2010 at Mix09. If you are interested, watch this video. Watching it was painful for me.
Some Highly Opinionated Observations
I felt truly bad for Brian Keller (Brian, if you're ever reading this, you did a great job). He was stuck practically sweeping up the ticker-tape from previous presentations. Even he found it ironic that his presentation was stuck at the end of the conference...like so many testing efforts. And like so many testers, he pleaded for feedback from a roomful of developers to help determine if there was significant interest in future talks about testing. Oh, and the technology wasn't helping either.
In 17 minutes, I saw a perfect example of the inherent difficulty with record-and-playback, even though it was capturing a lot of deep information. A functional test was recorded and the first failure was detected upon playback, only it was triggered by errors made while editing the generated code.
Recordin' Payback
Now, don't get me wrong. I am VERY impressed by what Microsoft is putting into the hands of the team - but at what premium? This is where I would like to insert my favorite argument, "Why do I need to pay $X,XXX.YY/seat for a tool that gives me the honor of pushing the button our team was tasked with creating?" How expensive is it to do any/all of the following during development:
- Define unique control IDs
- Define Active Accessibility parameters (y'know...those weird parameter fields you NEVER fill out when adding controls to GUIs in Visual Studio)
- Override control's WndProc methods with custom logic to persist user interactions to log files that can later be used for playback
- Keep logic OUT of the forms so that your application can run headlessly
- Implement Michael Hunter's Automation Stack
- Charge a junior test engineer with the task of learning how Win32 Window APIs, MsAA, Java Active Accessibility Bridge, .NET UiAutomation namespaces, etc. really works.
- Make testability hooks critical features in the application
- Make log files critical features in the application
- Report Source Code changes to the entire team
Does it take longer to implement these things? Maybe. It will definitely take longer to impress any management that merely hovers over the process with all the disinterest one could expect from a super model on a blind date with <insert NASA scientist here>. But I can say this much: if the department I'm in is considering necessary economic cutbacks, I'm glad I won't be competing with maintenance fees for COTS tool X.
My opinion is that these are more valuable for the organization because they invest in the individual(s) and their knowledge, not dumping money into 3rd party solutions to solve what are perceived as technological issues. To me, this is the same as if my parents, after being diagnosed with Diabetes, determined that the problem wasn't their diet but was actually their cooking. And then proceeded to "solve" this by eating the same foods at restaurants because...heck...they know how to cook. Sure, it costs more, but look how much healthier we are!
Hmmm. I guess it depends on the food/restaurant.
Benediction
Finally, on a more personal note: I long for the day when the ridiculous moniker of "evangelist" is purged from the tech nomenclature. I understand that it can bear secular meaning, but its use is imbued with religious connotation. An evangelist is one whose very existence bespeaks of a salvific message. As a tester and a man of faith, I find the idea that a technological solution could save us is...well...laughable; and the very reason I have a job.
Tuesday, April 7, 2009
Wednesday, April 1, 2009
Testing Tool: FileHamster
FileHamster is awesome. If it hasn't already arrived at your city - pillaging it with paws of gargantuan awesome-ness (paw-someness?) - then consider yourself both deprived AND unfortunate. Download it from here. I've been using this tool for about 1.5 years now and always come back to it.
In a nutshell, Filehamster is a glorified directory monitor that acts as a kind of localized source control. The developers originally intended it to allow creative types to work without the fear of being unable to undo their Picasso-esque changes. Anyone who has made modifications to a document, then closed the application only to realize that was in fact NOT the modification you wanted, can attest to this problem. Here's how it works from a 3048m view:
- Create a new directory/file watch
- Operate your application, saving changes will-nilly
- Observe that FileHamster captures each successive save
"No bug whoop!", you exclaim. "The .Net framework has a FileSystemWatcher class that lets me do the same thing!" That is true. Who hasn't written this kind of program before using that very class. However the ease of use, visibility of changes in real-time, and the diff plugin are benefits that keep this high on my desert island list of exploratory testing tools.
An example would be good here:
If I have a fat client application to test, one of the first things I do is pop open FileMon to observe its file system traffic for log files, artifacts, etc. Once I determine the directories where these files are written to, I create a new recursive directory watch in FileHamster. Even better, I can filter the types of files that it captures, thus reducing the potential for data overload. I then proceed to explore the app some more. Meanwhile, FileHamster is dutifully running in the background capturing all the file system changes into discrete time-stamped files and alerting me when it does so.
After a session, I can come back and observe the captured files. FileHamster honors any file associations; it will open the file in its associated application, e.g. TXT in notepad, MDB in Access, etc. This ability to observe a session's change history is valuable in-and-of itself. However, the diff plugin allows me to specify a comparison application as well. I can select two of the captured files and launch the comparison application via a context menu. Now I can see what changed in the document while I was testing away.
Experience Report...nnnNNNOW!:
I've used this approach while testing some financial applications that persisted actuarial debug values in a kind of CSV file. I would run a plain vanilla case, then run an alternate solve that should have given me the exact same answer. Both tests produced the CSV file. When I encountered a problem, I simply compared the known good (did I mention you can assign comments to the captured versions in this thing?) to the variant version and observed precisely where the diff was introduced. I don't need to be an ASA to tell you that a different max allowable loan value in year X could have significant ramifications on a Universal Life policy and its later-year cash values.
The only problem I've encountered is that I'm only able to specify one diff application. I've worked around this by creating a stub utility that maps all my diff applications by file extension. That way, my .xls files are compared in my custom Excel file utility, .PDF files are compared in another, etc. I may post my comparison stub script later, but it is simple enough to script in a language of your choice.
Download FileHamster and check it out. It runs on Windows and requires .NET 2.0. I want to say that I've also been able to run it off a thumb drive, so portability may be a benefit. Let me know what you think.
In a nutshell, Filehamster is a glorified directory monitor that acts as a kind of localized source control. The developers originally intended it to allow creative types to work without the fear of being unable to undo their Picasso-esque changes. Anyone who has made modifications to a document, then closed the application only to realize that was in fact NOT the modification you wanted, can attest to this problem. Here's how it works from a 3048m view:
- Create a new directory/file watch
- Operate your application, saving changes will-nilly
- Observe that FileHamster captures each successive save
"No bug whoop!", you exclaim. "The .Net framework has a FileSystemWatcher class that lets me do the same thing!" That is true. Who hasn't written this kind of program before using that very class. However the ease of use, visibility of changes in real-time, and the diff plugin are benefits that keep this high on my desert island list of exploratory testing tools.
An example would be good here:
If I have a fat client application to test, one of the first things I do is pop open FileMon to observe its file system traffic for log files, artifacts, etc. Once I determine the directories where these files are written to, I create a new recursive directory watch in FileHamster. Even better, I can filter the types of files that it captures, thus reducing the potential for data overload. I then proceed to explore the app some more. Meanwhile, FileHamster is dutifully running in the background capturing all the file system changes into discrete time-stamped files and alerting me when it does so.
After a session, I can come back and observe the captured files. FileHamster honors any file associations; it will open the file in its associated application, e.g. TXT in notepad, MDB in Access, etc. This ability to observe a session's change history is valuable in-and-of itself. However, the diff plugin allows me to specify a comparison application as well. I can select two of the captured files and launch the comparison application via a context menu. Now I can see what changed in the document while I was testing away.
Experience Report...nnnNNNOW!:
I've used this approach while testing some financial applications that persisted actuarial debug values in a kind of CSV file. I would run a plain vanilla case, then run an alternate solve that should have given me the exact same answer. Both tests produced the CSV file. When I encountered a problem, I simply compared the known good (did I mention you can assign comments to the captured versions in this thing?) to the variant version and observed precisely where the diff was introduced. I don't need to be an ASA to tell you that a different max allowable loan value in year X could have significant ramifications on a Universal Life policy and its later-year cash values.
The only problem I've encountered is that I'm only able to specify one diff application. I've worked around this by creating a stub utility that maps all my diff applications by file extension. That way, my .xls files are compared in my custom Excel file utility, .PDF files are compared in another, etc. I may post my comparison stub script later, but it is simple enough to script in a language of your choice.
Download FileHamster and check it out. It runs on Windows and requires .NET 2.0. I want to say that I've also been able to run it off a thumb drive, so portability may be a benefit. Let me know what you think.
Friday, March 27, 2009
Everything I know about Software Testing can fit in a Crock Pot
My wife put a pot roast in the crock-pot this morning in anticipation of a get together this evening. She told me she had set the timer for 9 hours, had pressed 'Start' and that it was cooking. Even though we were running late, I would not leave until I observed the timer change from 09:00 to 08:59. Despite her protestations that she had set it up correctly, I remained skeptical of the device. We had experienced failures with these things before.
What if the clock was set, not the timer? To me, the only visible difference between a clock and a timer is that one runs forward, the other runs backwards. While trying to prove her point by repeatedly pressing the 'Start' button, I observed no visceral feedback that said "Hey! I'm starting!" other than some LCD words that I had no reason to believe weren't always there before. No beeps. No buzzes. I was almost ready to assume that the bright red light was an indication that it was cooking, but I wasn't around to observe what state would cause the light to be off. I had in mind the risk of this device failing, namely that if it failed we would not eat and our party spirits would be dampened severely. This was too great a risk to not conduct a simple 1 minute test.
Mind you, the device could still fail in innumerable ways - heating element failure, electrical outage, etc. In fact, I thought about how I would be able to confirm power at home while I'm at work. I kind of wish our house had an old school answering machine and a land line telephone. But this 1 minute test would have to suffice as we had to leave ( read: push the pot roast into production ).
Please understand that my wife, so far as I can tell, does not share air with a tyrannical overlord who seeks opportune moments to hold a kind of tester's entitlement over her head. I give her honor where honor is due and ensure that our relationship flourishes in honesty and respect; she is in no small way my Queen. It is precisely because of how highly I value our relationship that the thought of her party plans being ruined compels me to protect her from the ways that technology lulls us into a false sense of security.
As we drove to work, I thought about how this epitomizes my experience in software testing.
What if the clock was set, not the timer? To me, the only visible difference between a clock and a timer is that one runs forward, the other runs backwards. While trying to prove her point by repeatedly pressing the 'Start' button, I observed no visceral feedback that said "Hey! I'm starting!" other than some LCD words that I had no reason to believe weren't always there before. No beeps. No buzzes. I was almost ready to assume that the bright red light was an indication that it was cooking, but I wasn't around to observe what state would cause the light to be off. I had in mind the risk of this device failing, namely that if it failed we would not eat and our party spirits would be dampened severely. This was too great a risk to not conduct a simple 1 minute test.
Mind you, the device could still fail in innumerable ways - heating element failure, electrical outage, etc. In fact, I thought about how I would be able to confirm power at home while I'm at work. I kind of wish our house had an old school answering machine and a land line telephone. But this 1 minute test would have to suffice as we had to leave ( read: push the pot roast into production ).
Please understand that my wife, so far as I can tell, does not share air with a tyrannical overlord who seeks opportune moments to hold a kind of tester's entitlement over her head. I give her honor where honor is due and ensure that our relationship flourishes in honesty and respect; she is in no small way my Queen. It is precisely because of how highly I value our relationship that the thought of her party plans being ruined compels me to protect her from the ways that technology lulls us into a false sense of security.
As we drove to work, I thought about how this epitomizes my experience in software testing.
Monday, March 16, 2009
Testing the Truth
Singularity Hub has an interesting post about "attempts to bring fMRI brain scanning based lie detection evidence to the court."
This got me thinking: would I have an ethical objection to testing a project like this? If not, what kind of project would I be unwilling to participate in? What if I were in a project and suddenly realized that the product could be used for nefarious purposes? What if my superiors responded to my protestation with an emphatic, "meh...get back to work."
So here are some questions I ask the greater testing community:
(1) What role do your ethics play in your software testing?
(2) Is there a project you would not work on, or have not worked on, based on moral objections?
(3) Does the current economic climate change what you would/would not work on?
(4) How would you test a product that claims to discern the truth?
(5) Would you purchase an iPhone app that could discern truth from lies?
This got me thinking: would I have an ethical objection to testing a project like this? If not, what kind of project would I be unwilling to participate in? What if I were in a project and suddenly realized that the product could be used for nefarious purposes? What if my superiors responded to my protestation with an emphatic, "meh...get back to work."
So here are some questions I ask the greater testing community:
(1) What role do your ethics play in your software testing?
(2) Is there a project you would not work on, or have not worked on, based on moral objections?
(3) Does the current economic climate change what you would/would not work on?
(4) How would you test a product that claims to discern the truth?
(5) Would you purchase an iPhone app that could discern truth from lies?
Friday, March 6, 2009
Learning to SHUT UP!
New Testers of Earth! Heed my warning!
There will be a day in your career when you will implement something you've always wanted. It may be a tool. It may be a process. It may be both. But it will seem to you as though it is yours.
You will nurse your burgeoning idea from cradle, through its shaky infancy, all the way up to the point when it begins to walk "on its own". You will grow more proud each day at your child's accomplishments. How it tidies up after itself. How polite it is to newcomers. How well-behaved and dependable it seems to be. You will swell up with pride as you show passers-by pictures of your "idea" doing the most wonderful things - running, spawning, making reports. And though you will fiddle with the thing for what seems like an eternity, you know that you know this thing, this idea, this slice of heaven - born from the marriage of your intellect and your soul - will undoubtedly change the course of history for all who would gaze upon its perfection!
If only everyone else would look at it, they would see it as you see it.
And then someone will call. Someone always calls. There is a problem. And this time the problem is not going to be solved by your miniature doppelganger. Actually, this problem was a direct result OF YOUR IDEA! Perhaps it was an oversight you made while extolling the virtues of your chosen child. Some inattentional blindness you succumbed to as you wrestled with either analysis paralysis or were being beguiled by some new technique you wanted for your resume. The once crowning, glorious edifice to all your rational logic is rent asunder by the astute observation of those you placed in subjection to it.
Your first emotion will be one of incredulity. Certainly the problem is elsewhere in another system...one you're not really responsible for. But no, the evidence points to your own backyard. Then you will seek to affix the blame on someone else. Someone else should have caught this! But alas, you'll be unable to prove that empirically and you'll realize that any effort to do so will only cause an escalation to occur. You'll be trapped. The problem finder has been found to be...a problem!
Oh, the insult to your abiding genius!
Now listen to me very closely. During all this frenetic activity, you will be tempted to lash out at those who accuse you. And you'll know all the words to say to give you the appearance of rightness. A quote here. A name-drop here. A book you read over there. Or even better, you know you could go trolling for evidence in your data farms and find the EXACT MOMENT when that ungrateful so-and-so really dropped the ball. Sure, it'll take an hour of research, but you KNOW its there. You'll even start up Agent Ransack. Are you still listening? Then hear this:
Stop it. Stop it NOW.
What you are about to do is introduce an unnecessary complexity into an already complex situation. That complexity is your personal desire to be seen as right...all the time. It is not only unnecessary, it is counter-productive.
I sometimes detect a hidden thread in our software testing conversations that bemoans our meager status. "If only they would listen to me," it seems to say. Much talk is given to methods and practices we might employ that would bolster our believability index. And this is good, but without restraint, maturity, and wisdom it leads to a kind of methodological mutiny. You can end up seeking to change the course of the development effort in a subversive manner; team buy-in be damned! This is not being progressive. This is not being helpful. This is not being clever and it will not land you a job at <insert mega-trendy forward-thinking collective here>.
You work in a team. And a team works together. You perpetuate the us-versus-them mentality at your own peril. You will make mistakes just like everyone else. Own them. Working with others is a messy affair, mostly because we are all so darned complex. We defy any attempts to metricize our behaviors, but that does not stop us from trying. Future history will be littered with our grandiose ideas to reduce complexity and manage expectation. Some may actually work, but they will only work when they work well with others.
On the cabinet above my desk, there is a post-it note stuck to the door. It simply reads:
"This is not the kingdom you are building."
There will be a day in your career when you will implement something you've always wanted. It may be a tool. It may be a process. It may be both. But it will seem to you as though it is yours.
You will nurse your burgeoning idea from cradle, through its shaky infancy, all the way up to the point when it begins to walk "on its own". You will grow more proud each day at your child's accomplishments. How it tidies up after itself. How polite it is to newcomers. How well-behaved and dependable it seems to be. You will swell up with pride as you show passers-by pictures of your "idea" doing the most wonderful things - running, spawning, making reports. And though you will fiddle with the thing for what seems like an eternity, you know that you know this thing, this idea, this slice of heaven - born from the marriage of your intellect and your soul - will undoubtedly change the course of history for all who would gaze upon its perfection!
If only everyone else would look at it, they would see it as you see it.
And then someone will call. Someone always calls. There is a problem. And this time the problem is not going to be solved by your miniature doppelganger. Actually, this problem was a direct result OF YOUR IDEA! Perhaps it was an oversight you made while extolling the virtues of your chosen child. Some inattentional blindness you succumbed to as you wrestled with either analysis paralysis or were being beguiled by some new technique you wanted for your resume. The once crowning, glorious edifice to all your rational logic is rent asunder by the astute observation of those you placed in subjection to it.
Your first emotion will be one of incredulity. Certainly the problem is elsewhere in another system...one you're not really responsible for. But no, the evidence points to your own backyard. Then you will seek to affix the blame on someone else. Someone else should have caught this! But alas, you'll be unable to prove that empirically and you'll realize that any effort to do so will only cause an escalation to occur. You'll be trapped. The problem finder has been found to be...a problem!
Oh, the insult to your abiding genius!
Now listen to me very closely. During all this frenetic activity, you will be tempted to lash out at those who accuse you. And you'll know all the words to say to give you the appearance of rightness. A quote here. A name-drop here. A book you read over there. Or even better, you know you could go trolling for evidence in your data farms and find the EXACT MOMENT when that ungrateful so-and-so really dropped the ball. Sure, it'll take an hour of research, but you KNOW its there. You'll even start up Agent Ransack. Are you still listening? Then hear this:
Stop it. Stop it NOW.
What you are about to do is introduce an unnecessary complexity into an already complex situation. That complexity is your personal desire to be seen as right...all the time. It is not only unnecessary, it is counter-productive.
I sometimes detect a hidden thread in our software testing conversations that bemoans our meager status. "If only they would listen to me," it seems to say. Much talk is given to methods and practices we might employ that would bolster our believability index. And this is good, but without restraint, maturity, and wisdom it leads to a kind of methodological mutiny. You can end up seeking to change the course of the development effort in a subversive manner; team buy-in be damned! This is not being progressive. This is not being helpful. This is not being clever and it will not land you a job at <insert mega-trendy forward-thinking collective here>.
You work in a team. And a team works together. You perpetuate the us-versus-them mentality at your own peril. You will make mistakes just like everyone else. Own them. Working with others is a messy affair, mostly because we are all so darned complex. We defy any attempts to metricize our behaviors, but that does not stop us from trying. Future history will be littered with our grandiose ideas to reduce complexity and manage expectation. Some may actually work, but they will only work when they work well with others.
On the cabinet above my desk, there is a post-it note stuck to the door. It simply reads:
"This is not the kingdom you are building."
Thursday, March 5, 2009
Learning to lead...
Today, I met with my direct reports to go over their performance reviews. It is difficult to find the purpose in bureaucracy, especially in tough economic times. So in my "rebellion", I decided to make the most of this edict from on high.
In keeping with the "script", we addressed the issues noted in their respective reviews. We talked about career goals and such. And having done this, I confirmed that they were satisfied with all that was written and addressed up to that point.
"Yes," they would dutifully reply; "Check," my mental reply.
But then I expressed to these amazing individuals that I felt responsible for equipping them not only for their jobs, but also the greater market. I spoke candidly and frankly that because we live in such uncertain times ( haven't we always? ), I felt morally obligated to assist them in becoming all I know they can be. And I apologized for failing them so in the previous year; for my distance, my myopic nature, my personal ambition making me unavailable at times.
I gave them the power and right to hold me accountable in my others-improvement endeavor. They can improve me as I help improve them. I want so desperately for my direct reports to succeed. It causes me much inner-turmoil to think that should a pink slip appear, it could send them out into the current job market with limited exposure to advanced topics in development, testing, and automation. This is my responsibility, so I endeavor to rectify it.
Managers and Testers reading this: what are YOU doing to improve the quality of the PEOPLE around YOU in ways that will benefit THEM should they no longer be around YOU?
In keeping with the "script", we addressed the issues noted in their respective reviews. We talked about career goals and such. And having done this, I confirmed that they were satisfied with all that was written and addressed up to that point.
"Yes," they would dutifully reply; "Check," my mental reply.
But then I expressed to these amazing individuals that I felt responsible for equipping them not only for their jobs, but also the greater market. I spoke candidly and frankly that because we live in such uncertain times ( haven't we always? ), I felt morally obligated to assist them in becoming all I know they can be. And I apologized for failing them so in the previous year; for my distance, my myopic nature, my personal ambition making me unavailable at times.
I gave them the power and right to hold me accountable in my others-improvement endeavor. They can improve me as I help improve them. I want so desperately for my direct reports to succeed. It causes me much inner-turmoil to think that should a pink slip appear, it could send them out into the current job market with limited exposure to advanced topics in development, testing, and automation. This is my responsibility, so I endeavor to rectify it.
Managers and Testers reading this: what are YOU doing to improve the quality of the PEOPLE around YOU in ways that will benefit THEM should they no longer be around YOU?
Humanity, Suffering, and Software
Just finished watching Arch Bishop Desmond Tutu on Craig Ferguson's show tonight. Mr. Ferguson is a recent discovery of mine since going down to basic cable. His off the cuff style hits my funny bone just right. But tonight I was hit in a different place. For the better, I believe.
Father Tutu was questioned about the motivations behind forgiveness in the face of unspeakable humanity. His answer involved describing the inherent intertwining of our humanity, and that any practice that dehumanized an other will have a reciprocal affect on the dehumanizing agent. It was incredible to watch someone who spoke with passion, precision, and humility about the betterment of life through love and forgiveness; that aspiring to the better parts of ourselves is a noble endeavor. He left the usually talkative Craig speechless. He is a peacemaker in every sense of the word.
And after this, I read James Bach's blog entry on how quality is dead. Long live quality! I will not attempt to summarize, but James' thoughts are lucid and illuminating as usual. Please read it. Now, James would be the first to say that he can be argumentative. If he is a peacemaker, it may come about only after much heated debate.
Sometimes when my mind encounters a striking dissimilarity between two things, I seek to find their commonality. What does software quality have to do with Apartheid? And so it is late enough at night for me to entertain the relationship between these two seemingly disparate media events and their perpetrators. To explore the connection between Father Tutu's cause and James Bach's cause.
Perhaps James' observations speak to a very small kind of oppression forced upon us by a culture intoxicated by its technology (in-techno-cated?). Perhaps Father Tutu's response to a particularly nasty, high severity problem ( i.e., Evil ), and his subsequent success, is a valuable model to combat the present state of affairs.
Both ideas seem to be crying out for change that benefits everyone, but are dealing with entities reticent to change because, well, there's no incentive to change; reduced quality does not hurt the 'haves'. And these entities fervently believe that nothing is wrong, that things are actually improving.
It seems to me that restoring a proper perspective is a shared idea in both issues. It is good to see ourselves as humans again - linked to each other in inexplicable ways that technology and government cannot improve upon. To begin thinking of what the word "enough" really means. In both contexts. Bringing awareness to the greater community begins to break the cycle. It all reminds me of something my Pastor father told me one time: "Some demons are killed immediately, others are starved to death." Change comes, only the velocity varies.
I'll end my philosophical waxing here because I think it is a bit disrespectful for me to equate the plight of human suffering in Darfur/South Africa with proprietary protocol failures between Tivo and Dish Network.
Father Tutu was questioned about the motivations behind forgiveness in the face of unspeakable humanity. His answer involved describing the inherent intertwining of our humanity, and that any practice that dehumanized an other will have a reciprocal affect on the dehumanizing agent. It was incredible to watch someone who spoke with passion, precision, and humility about the betterment of life through love and forgiveness; that aspiring to the better parts of ourselves is a noble endeavor. He left the usually talkative Craig speechless. He is a peacemaker in every sense of the word.
And after this, I read James Bach's blog entry on how quality is dead. Long live quality! I will not attempt to summarize, but James' thoughts are lucid and illuminating as usual. Please read it. Now, James would be the first to say that he can be argumentative. If he is a peacemaker, it may come about only after much heated debate.
Sometimes when my mind encounters a striking dissimilarity between two things, I seek to find their commonality. What does software quality have to do with Apartheid? And so it is late enough at night for me to entertain the relationship between these two seemingly disparate media events and their perpetrators. To explore the connection between Father Tutu's cause and James Bach's cause.
Perhaps James' observations speak to a very small kind of oppression forced upon us by a culture intoxicated by its technology (in-techno-cated?). Perhaps Father Tutu's response to a particularly nasty, high severity problem ( i.e., Evil ), and his subsequent success, is a valuable model to combat the present state of affairs.
Both ideas seem to be crying out for change that benefits everyone, but are dealing with entities reticent to change because, well, there's no incentive to change; reduced quality does not hurt the 'haves'. And these entities fervently believe that nothing is wrong, that things are actually improving.
It seems to me that restoring a proper perspective is a shared idea in both issues. It is good to see ourselves as humans again - linked to each other in inexplicable ways that technology and government cannot improve upon. To begin thinking of what the word "enough" really means. In both contexts. Bringing awareness to the greater community begins to break the cycle. It all reminds me of something my Pastor father told me one time: "Some demons are killed immediately, others are starved to death." Change comes, only the velocity varies.
I'll end my philosophical waxing here because I think it is a bit disrespectful for me to equate the plight of human suffering in Darfur/South Africa with proprietary protocol failures between Tivo and Dish Network.
Subscribe to:
Posts (Atom)
Posts
