To begin, I want to make it clear that I am not defending Joseph Kony or the acts for which he has been indicted and that I support the goal of the KONY 2012 campaign; to bring justice in Uganda. However, I am concerned about the precedent this video may set.
Innocent or guilty?
Joseph Kony has not been tried for the atrocities presented in the video. He has been indicted by the International Criminal Court. That doesn't mean he didn't do it, but it doesn't mean he did either. In the world I am privileged to live in, I am afforded the right of being innocent until proven guilty and the right to a fair trial and I believe everyone should be afforded those same rights. The KONY 2012 campaign skirts a fine line in this regard, perhaps even crosses it.
Truth
I believe the KONY 2012 campaign is well-founded and that Joseph Kony is guilty of the terrible acts for which he has been indicted, but all I did was watch the video. Before watching this video, I didn't even know who Joseph Kony was, yet now I fully believe he has committed terrible crimes in Uganda. Invisible Children no doubt sees that as a success (after all, their strategy is to make Joseph Kony famous) yet I have little substance to that belief; I am asked to accept it as truth based on perceived trust in the source. Why should I believe Invisible Children over Joseph Kony? I had never heard of either of them until I watched this video.
Furthermore, we're asked to make Joseph Kony famous. Famous for committing crimes for which he has not yet been tried. Throughout the video, the guilt of Joseph Kony appears to be assumed, stated as fact rather than accusation or suspicion. Think about that. A party that I've never heard of is asking me to vilify another party that I've never heard of. Which is right? Which is wrong?
It is easy to take spoon-fed media like this and jump to the conclusions to which we've been led (a point raised in the half-hour presentation), but it is our personal responsibility to take time to discern the truth for ourselves. To research our sources and determine who to trust. To afford others the courtesy and consideration that we ourselves would like to enjoy.
Justice
As the world becomes more connected, a new kind of lynch mob is made possible – create a compelling video and get it viral. Such a world makes a fair judicial process even harder than it already is, relying more and more upon individuals to discern the truth for themselves when, let's face it, not everyone is capable, willing or bothered to do so.
How many times have you voted for a political candidate based solely on political party without researching their individual manifesto? Or bought a product without reading reviews? Or considered that your religious beliefs or lack of them may be wrong? The fact is we don't like to work to prove ourselves wrong, but when it comes to justice, we must. A system where people are condemned based upon rumour, conjecture and personal belief is unacceptable. Would you like to be judged by such a system?
Stop and think
I want to reiterate, I am not defending Joseph Kony or the acts for which he has been indicted; when he is tried and if he is found guilty, he should face appropriate penalties as determined by the International Criminal Court. However, I do not want the next generation of people on this planet to grow up in a world where the first one to get their video viral writes history and I hope that you don't either.
So, I ask that before you act on KONY 2012 or any other information presented to you, stop and think. Whether the source is a charity, a news organisation, a politician, a government body, a colleague, a friend or a family member, stop and think. Listen to and think about what is being presented to you. Consider the source, do some research and find out what you can about the truth for yourself before you act, before you condemn, before you make a mistake.
KONY 2012
To close, please support KONY 2012, but not because I, Invisible Children, or the streets full of propaganda in April tell you to. Do it because the facts tell you to. Be confident in your own opinion, not someone else's.
At the end of last month I attended the Automotive Megatrends 2012 held at The Henry in Dearborn, MI. Though this was a three-day event, I attended the second day only: Connectivity. It was an opportunity for major and minor players in the automotive world to present and discuss their particular visions of the future for passenger cars in a world that is increasingly connected. Particular attention was paid to the Cloud and the continuing trend for infotainment1 to be provided via handheld devices rather than proprietary in-vehicle systems. Safety was a hot topic; in particular driver distraction, where legislation tends to hold vehicle manufacturers liable in the event of an accident even though they may have little or no control over the devices that do the distracting (such as smartphones).
The day was split into four main sessions divided by networking opportunities. Each main session took the form of a panel where four or five panelists would present their views on a particular topic with a moderator overseeing the discussion. Each panel would face a round of questions once all had presented. The topic of the first two sessions was "Connected vehicle outlook — the next 10 years" with the following sessions being "Mobile device integration" and "Software and apps" respectively. Repeatedly during the day, speakers would return to the concept of the Connected Vehicle and what that means for consumers and manufacturers alike, but what do they mean by "The Connected Vehicle"?
A Day in the Life
You wake up on a cold, wintry morning to your smartphone alarm obnoxiously wailing. Via the magic of the Internet, the home management app has checked the local weather and adjusted your home heating to give you an extra bit of toasty warmth. It has also instructed your coffee machine to brew up some Joe.
You flip to the appropriate smartphone screen and start your car. A quick swipe and the in-car temperature is set just right. An alert tells you a service is due and shows you local service locations along with their cost. You select your favourite location and choose an appointment time, then you swap over to your home management app and start the shower. By the time you're out of bed, showered, dressed and have your coffee in hand, the car is thawed out and toasty warm.
As you drive to work by way of your children's daycare, information is delivered to you via your smartphone to your in-car video and audio systems, telling you the weather, headlines, social media updates and to-do list for the day. Your favourite music plays in the background as you choose. Perhaps you even queued up some things from the night before. Voice commands and a simple, radio-like interface give you simple, non-distracting control of your information streams. Everything coordinates and cooperates to ensure that you can concentrate on driving.
As you're finishing off a quick check of your e-mail subject lines an alert flashes up warning you of road construction and traffic delays. The satellite navigation app on your smartphone kicks in, offering alternative routes and travel times to get you on your way. As you begin your detour, the directional microphones and image processing systems in the back seat detect that your kid just woke up and has started punching his sibling. In an attempt to keep the peace, the latest, greatest animated movie immediately starts streaming from Netflix, Hulu or Zune in the headrest display. Meanwhile, your satellite navigation is suggesting spots to safely pull over (as well as one or two doughnut shops you might need for the purchase of "behave yourself" bribes).
Having dropped the kids off at daycare, you pull up at work and apply the parking brake. The in-car systems take the opportunity to remind you of your service appointment. You get out of the car and walk to your office – the car automatically turns off and locks itself as you go. When you get to your desk, you computer has already synced with the Cloud, showing your service appointment on your calendar along with a snapshot of your car diagnostics, should you need to discuss the appointment over the phone.
Reality Check
Though embellished with a few ideas of my own, this scenario is similar to many involving the connected vehicle envisaged by those presenting at the conference. It is all so seductively plausible that it's easy to ignore the reality. Behind all the enthusiastic rhetoric there are so many unresolved problems and challenges that we're just not ready yet to deliver the dream of the connected vehicle. To get an idea of where we are right now, consider the current vehicle to be akin to video-game consoles just over 10 years ago. Before the current generation of consoles (Playstation 3, XBOX 360, Nintendo Wii), pretty much all you could do with a gaming console was play games, now we can not only play games, but also buy games, rent, buy and stream video, listen to Internet radio stations, watch live television (in HD) and interact with social networks.
The problems for the connected vehicle mostly lie in the gap between the old and the new; passenger cars, with a development cycle of 3-4 years and consumer electronics, with a development cycle of 12-18 months. In a world where a smartphone can be out-of-date within a year but a car is expected to last ten or more, bridging the gap becomes a challenge. Not to mention that the world of the connected car relies on the existence of wireless carriers and services that not only support the demands of consumers but also those of the equipment manufacturers, services like OnStar and its soon to be released API, requiring access to vehicle data and systems in a safe and secure manner.
Controlled Openness
To bridge the development cycle gap, there was a call for the end of proprietary infotainment systems and more controlled, open standards across the passenger car industry. The general view was that proprietary systems have to go in favour of smartphone or other smart device apps, a trend that has already begun. This move would help to reign in the growing concerns surrounding driver distraction by providing an in-vehicle delivery platform that allows apps to interact with the car and its passengers in a safe, secure and reliable manner.
In order to make such a platform appealing to app developers, a set of open standards needs to be adopted by the industry, a set of standards that has not yet been defined but that will provide rules and guidance on how an app interacts with a vehicle and its occupants (as with any new technology discussion of 2012, whispers of HTML5 were everywhere). This idea of controlling app delivery within the vehicle while allowing open standards and app development was dubbed "controlled openness" and clear comparisons were drawn with Apple and the way they govern the app marketplace.
Safe and Secure
Just like the API provided by Apple and any other contemporary development platform, security is extremely important. Security is the basis of trust for consumers and without it the full potential of a technology can never be realised as no one will ever immerse themselves fully. Several presenters gave their thoughts on how security might work but there was a lack of convincing argument that this was a simple problem to solve. In fact most speakers on the matter seemed to be plugging a product while skirting around some of the issues that had been raised by others. Issues that have names like "virus", "hacker" and "theft"; the connected vehicle opens up a cornucopia of problems that must be resolved.
How do you stop someone taking control of your vehicle while allowing you to remote start it from your phone?
How do you allow an app access to vehicle systems without allowing a bug to cause a vehicle accident?
How do you ensure that a person's identification is unpaired from a vehicle when they are no longer in possession of that vehicle due to sale, accident or theft?
Given the need to exchange data to and from the vehicle communications network in order to support telematics and other advanced (perhaps premium) apps, which may include the ability to do things like start, stop or even track the vehicle, I'm sure you can think of many other scenarios that highlight how important it is that the connected vehicle be secure.
The Internet and our increasingly connected world has security all over the place with a plethora of approaches to providing identification, authorization and secure access. However, the effects of a hack or security flaw have so far not had such potentially immediate fatal results as they might in the world of the connected vehicle. A security breach that allows someone to take control of some aspect of your car is entirely unacceptable. This is not a case of making sure it should never happen, but rather a case of could never happen. If nothing else, the experience of driving a car must be safe, both actually and perceptually.
The Road Ahead
So where does that leave us? The automotive industry has rightly identified a need to integrate more closely with the consumer electronics world and move away from the proprietary in-car infotainment systems of old, but the consumer electronics industry is racing along at quite a pace. Although the concept of a smartphone existed prior to its announcement, the launch of the iPhone five years ago accelerated smartphone evolution and it shows no signs of slowing down. However, until the iPhone of the connected vehicle concept appears and focuses consumer expectations, we will have to accept the Windows Mobile-style missteps along the way2.
While the connected vehicle is still an uncertain concept, it is becoming a reality and it will change the way we interact with our cars. In fact, they may not be our cars at all3. The speakers at the Automotive Megatrends 2012 event had plenty of statistics, ideas and products to illuminate the target that is the connected vehicle. Now all we need to do is find the road that takes us there.
Infotainment is a word used in the automotive industry to refer to the combined provision of information and entertainment services within a vehicle such as radio and satellite navigation [↩]
Not to be confused with Windows Phone 7 (or 7.5), which is awesome. [↩]
Uncertainty exists on how various facets of the connected vehicle will be monetized; from the services and apps to the car itself. Will it be subscription-based, ad-supported or freemium? Will we buy our cars or enter into a service-agreement instead? All of these things and more are yet to be determined. [↩]
I went to CodeMash this year. I was one of the 1200 (or 1300 and something, after speakers and other people were counted). It was my first time attending this community-organised conference and I had a thoroughly enjoyable time. I would show you pictures but I neglected to take any as I was having far too good a time to remember that I'd brought a camera.
My wife and I1 arrived at the venue, the Kalahari Waterpark and Resort on Tuesday, the day before everything started with Wednesday's pre-compiler. Tuesday evening was spent meeting fellow mashers in the two resort bars, but ultimately led to a rocky start to Wednesday (breakfast was scheduled for 7am but I had forgotten to schedule bedtime accordingly).
My improvisation when the coffee cups ran out
At every meal during CodeMash, I enjoyed great food, nerdy conversation and copious quantities of caffeinated beverages with some fascinating people. Most of the time I dined with people I had never met, being sure to introduce myself and making a concerted effort to remember names (though, alas, I forgot a few). Although the pre-compiler day was overshadowed by a number of beverage-related issues varying from no coffee to no Mountain Dew to lots of coffee but no coffee cups (I improvised2), the remainder of the conference catering seemed to go without a hitch. This was in no doubt thanks to the CodeMash organizers and the amazing Kalahari staff.
Every evening after the sessions ended, a copious number of tempting options were available from the game rooms where D&D, poker and various other pastimes were enjoyed to Open Spaces3, from the bars, restaurants and water park to panel discussions. Attendees and CodeMash organizers alike would advertise a plethora of options to while away the hours until sleep was the only option. I was so exhausted after CodeMash that I slept for nearly a day when I got home.
What about the sessions themselves?
Wednesday
Going Independent
I'm not going independent, at least not anytime soon, but considering I have worked with many who are self-employed and might consider it for myself one day, it seemed prudent to learn more. Michael Eaton (@mjeaton) was the speaker for this session. He drew from personal experience and the experiences of those he knew (some of whom provided their own anecdotes) to outline the common practices and pitfalls that beset anyone trying to go it alone.
Michael's conversational style provided a great start to the conference and the information presented gave me a fresh perspective on the overhead, sales and productivity concerns of a business owner (apparently, if you manage 30 billable hours per week, you're doing well). Even for someone under full-time employment like me, it provided useful details that will help me to continue supporting those who employ me.
HTML5 is here, and the Web will never be the same
Wednesday afternoon was spent with Brandon Sartrom (@BrandonSatrom) and Clark Sell (@csell5) learning all about markup, behavior and presentation with HTML5, javascript and CSS3. I am not a web developer, my acquaintance with HTML and its supporting technologies would probably make a professional sob, but this lab on the latest and greatest was fantastic. Each area of the HTML5 offering was presented with hands-on labs to sink ones teeth into. There was so much to cover that eventually time fell short, but I still have the labs on my desktop and be assured, I intend to complete them. This was a great stuff and the session so popular that we had to move rooms about an hour in. Apparently, this web stuff is a big deal. Who knew?
Thursday
Unlike the pre-compiler format of half-day and full-day workshops and discussions, the remainder of the conference was split into concurrent hour long presentations, open spaces, gaming and other activities. The sheer number of distractions was sometimes overwhelming, making the act of choosing a distraction in itself to the point where a couple of times, I gave up and just took an hour long break.
On Thursday, we had our first keynote speech, Rethinking Enterprise, while munching away at the remnants of breakfast. The speaker, Ted Neward, had an energy that made sure everyone was awake. Although Ted's presentation style was ultimately controversial, I felt the points he made were valid, well thought out and thoroughly enjoyable to learn.
From the keynote, I swiftly headed to see the popular double-act of Jon Skeet(@jonskeet) and Bill Wagner (@billwagner) presenting C# async inside and out. It was a packed out double session. Some only turned up for the much more complicated second session and I'm sure probably left very confused and scared of both C# and async. However, I loved it. Not only did I witness Jon Skeet's passion for C# first hand, but I also learned a lot (a useful mutable struct?).
After the Skeet/Wagner show, I took a break to check on my wife and make sure she was having a good time. I actually had to persuade her to make an appointment in the spa as she was perfectly happy eating homemade gumbo and watching bad daytime TV in the hotel room. Once I'd convinced her to spend some money in the spa (what did I do?!), I headed back down to learn about usability testing with Carol Smith (@carologic), attended a vendor session from Robert Half Technology, and then headed to David Giard (@DavidGiard) and his presentation on data visualization.
I have to say that while I enjoyed all the talks and workshops I attended, David Giard's presentation on data visualization was by far in the top two sessions I attended. Not only did Mr. Giard give a great talk while very much under the weather, but the examples of good and bad data visualizations he presented were useful and clear. I came away with a new found appreciation for graphs and charts, and a new found skepticism of those who create them and their motives.
Thursday was rounded out by dinner, the hilarious Pecha Kucha competition, live music, impromptu free beer in one of the hotel rooms and a late night water park party just for CodeMash attendees. At least, those were the things I attended; as always there was far more going on elsewhere in the resort if one was so inclined to attend.
Friday
Friday started slow. The night had once again taken it's toll but breakfast was thankfully an hour later, which helped. I skipped the first session, opting instead to wander the vendor stands and show my appreciation for their support.
My first session of the day was Dealing with Information Overload delivered by Scott Hanselman. I really wanted to catch one of Scott's two presentations as I had seen him present at the San Francisco StackOverflow DevDays and really enjoyed his presentation style. Just as at DevDays in 2009, Scott gave a very enjoyable presentation packed with useful, necessary tips, tricks and lessons in how to deal with information and stay productive. I have already started to fold some of the techniques into my working day and intend to continue. Along with the Data Visualization presentation from Thursday, Dealing with Information Overload was in my top two talks of the conference.
Lunch followed with our second keynote speech, How We Got Here, And What To Do About It presented by Barry Hawkins. The keynote was excellent and the presenter only went up in my estimation when we spoke and I learned he was both an anglophile and a thoroughly nice chap4.
As lunch digested, I rounded out the conference with some C# Stunt Coding from Bill Wagner (and a little Jon Skeet when he got up to refactor Bill's code; thoroughly entertaining) and some applied F# from the crazy-shirted Gary Short (@garyshort). Both of these talks were wonderful and gave me some inspiration for some crazy and not so crazy things to try in the near future (both code- and fashion-based).
Friday night's raffle was entertaining, but I didn't win so I'm not saying anymore about it. I'm not bitter, but seriously, didn't win. I did, however, win a book from O'Reilly (@oreillymedia) just for singing a couple of lines to a song. O'Reilly had a large collection of books with them on their vendor booth and gave them all away to anyone willing to sing on video. I haven't seen that video surface yet, but I'm sure it will. Still, I now have a spanking new copy of Programming Android and they're not getting it back if they decide they don't like my pipes (but seriously, thanks for the book).
The End
Jafar hamming it up for the camera while the wife and I pose
And that was that. There was more partying and water park fun but the mashing was over. My wife and I enjoyed the remainder of our stay, including a few photos with Jafar, the Bengal tiger and then travelled home to pass out and catch up on sleep.
Congratulations to all who helped put this together and a hearty thanks to all the folks (speakers, staff, attendees and Jafar) that made my CodeMash experience. It was such a wonderful event to have been a part of and I hope I am fortunate enough to get a ticket next year.
Yes, I took the missus. While I was learning and networking and totally not eating too much bacon or drinking, she was cooing at a Bengal Tiger cub or doing spa type things. [↩]
Open Spaces are free-form discussions on topics suggested by attendees where an open exchange of ideas, experiences, tips and other things can occur. [↩]
My assessment and conclusion of the latter was in no way swayed by learning the former…I swear. [↩]
If your birds are upset,
And some swine are snooping round,
It makes total sense,
That a catapult be found,
Into which you place,
The angry avians you see,
And watch each porcine face,
When hit by flung poultry.
Now you may be in wonder,
Why it is the birds don't fly,
"Why a catapult?" you ponder,
Instead of wings to get them by,
But it really doesn't matter,
I really wouldn't ask,
They're each mad as a hatter,
They might take you to task.
So with careful aim,
Teach the pigs what for.
These birds aren't tame,
They are angry, out for war.
No wooden tower,
Or icy outcrop will be safe,
When wrathful feathery power,
Lays the porky land to waste.
In the world of software, there are developers and there are testers. The developers often design and implement the software while the testers define and execute the test plans. Software engineering requires both testers and developers, and together they make quality software; one by finding problems and the other by solving problems1. At least, that's the way it should be. Unfortunately, many developers (including myself) have found themselves in situations where the QA department is nonexistent, where testing and the associated test plan updates lurk at the end of every development cycle or feature implementation.
Just to be clear, we're not talking unit tests like those used in test-driven development (TDD) with frameworks like NUnit or MSTest. Unit tests and TDD are somewhat unique in that they take the developer's strength of solving problems and trickpersuade developer's into seeing testing as yet another problem in need of resolution (just how do you prove a requirement was met – to the TDD Cave, Codeman!).
Sadly, manual tests found in system testing, integration testing and regression testing are not so exciting. They don't usually present cunning problems to be solved but instead provide a means for mind-numbing hours following detailed, inane instructions where the result feels obvious and the rewards are few. At least, that's my experience as a developer performing tests; the same cannot be said of testers. I've worked with some very talented, passionate quality assurance professionals whose joy found in their craft was inspiring and of whom I have been envious when I too have found myself burdened by testing.
Finding those team mates who take pride in testing and making a product better is like striking gold, but even those that find schadenfreude in identifying a colleague's mistakes can be a better option to a developer than having to run the testing themselves. However, dedicated resources for quality assurance are often seen as a luxury2, leaving developers with little option but to take that responsibility on themselves.
To be clear, I'm trying to say that developers generally hate testing and more specifically, I hate testing, but we'll do it anyway if pushed.
WHHHHAAAT??!
At this point you may be surprised to discover that I recently found myself testing some software. Whether it was a poorly defined test, a flaky feature, or just the mundanity of repeating the same operations (albeit with subtle adjustments) over and over and over again, it left me frustrated, weary and disengaged. Testing is just not my thing, but I do it because I have to – releasing untested software should never be an option for a professional software developer; our users are not our QA department. The all too familiar experience reminded me of steps that developers can take when they're the ones that have to update and execute manual testing; steps that I've seen in action and that make testing almost pleasurable (almost).
Just update the test plan
Have you ever updated a test plan without checking the test was correct, or perhaps executed a test plan that was incorrect? Updating a test plan is tedious, we have to check that existing tests are still relevant and work out where there are gaps in the test coverage. This usually means looking at requirements documents and change requests and determining various test paths, expected results, etc. It can be a lot of work and it is all too easy to fall into the trap of skipping some steps, like validating the test is correctly defined or pretending that there's no way the existing plan missed something. Not only that, but if you've diligently updated the test plan, validating each test as you go, executing it all over again is even more painful because you already know what does and does not work from updating the tests in the first place.
So, do it once and do it right. If you carefully update the test plan, validating existing tests, updating others and creating new ones, you will find yourself testing the product anyway. As tests that should work don't, change requests will get raised and the product will improve. Not only that, but you'll only need to update the document once and you won't need to run the tests more than is absolutely necessary. To cap it off, the act of defining tests is pretty close to problem solving, making it a little less tedious for a developer to perform (though it is documentation, so, you know, don't hurt yourself or anything).
Assume the tester knows nothing (and is a little slow)
All too often, I come across test plans that are written like a kindergarten story.
Start the application. And then open a file. And then click OK. And then check the background is white and the caption says "Bite me!".
Paragraphs of simple instructions, often with steps missing that the author assumes the tester will know and without any explanation of what it means if that test fails. Instead of this mess, introduce each test with an overview of its purpose and what failure means, followed by test instructions each on a separate line. This not only helps you and your team mates when running the tests but it also helps when they come to update the test plan. Think of the test as code; you wouldn't expect the processor to guess when you miss out lines of code (I hope) so don't expect a tester to do the same; don't forget to add comments where more detail is needed (such as why it's important to change what locale the system is using); and number each step so that it can be referred to easily in notes and change requests, e.g. "Test 2.6, step 10 failed with a value of 20 where 21 was expected"3. If you do this, you will thank yourself later.
Provide context for the results
When performing the test, you will want to be recording results for each step. When reviewing results, you will usually want to see the test step that garnered them, especially if there is a failure or an ambiguous result. Save yourself some time by specifying your tests as a table with a column for results. That way, results are recorded next to the test definition making both recording and reviewing much easier. Not only that, but you don't need to maintain a results sheet and the test definitions separately or contend with different people recording the results in different formats.
Conclusions
If you follow these three simple steps, you should end up with test definitions that look less like an account of your weeks at summer camp when you were 7 and more like the example below.
This test checks the flange sprocket exposes the doobrey flap.
Step
Instructions
Results
10
Open the flange sprocket. You should see the flange sprocket open.
Pass – opened
20
Press the doobrey flap.
Fail – unable to locate doobrey flap. Test lacking sufficient detail or doobrey flap was not exposed.
30
…
Of course, all this assumes you don't have a QA team or team members (or even some tools that help you define and execute manual testing). If you do, that's great; respect your QA team members (or your tools) and the work they do to keep your users from deploying their wrath upon thee. For the rest of us, stuck with ourselves and our office productivity applications in which to define and record our testing, following these tips will make our testing life (and that of those around us) just that little bit less tedious. Who knows, some of you might even start enjoying it.
