People have been telling me this for years but it only recently started to make sense.
A while back I ordered a few things from an online electronics retailer. Just a few small items, a USB-hub, a HDMI cable and something else. Being true to my nature and well enforced students ways I automatically picked the cheapest possible shipping. Hit OK and sat down to wait for the deliver notice to be delivered by text. The text came (three days later) and it told me where to pick my things up from. It was a store a few clicks away from work. No big deal, I’ll just take care of it during lunch.
And so I did. Walk to the tram (5 minutes), wait for the tram (5 more minutes), ride the tram (15 minutes but since we are talking public transportation here, it felt like 30 minutes thanks to the gentlemen who also chose to ride that tram that day), walk from the tram (2 minutes), wait in line (20 minutes(!)) and then back again. When this was over and done with, I had spent more than one hour just retrieving my package. Time I could have spent at work, billing my customer.
Next time you have the option of paying a little bit more to save some time and still arrive at the same destination. At least consider paying a few bucks extra. Provided your ability to put food on the table doesn’t depend on it, it might be well worth it to pay a little more.
Like, if you are travelling, don’t get a dirt cheap motel an eternity away from the attractions you are there to enjoy. You’ll spend time and money on going back and forth, time any money that could be spent enjoying the attractions. (I once got a motel room about 45-60 minutes away from Yosemite, it was cheap but it also made me not do Half Dome)
The “trick”, figure out how much money you make in 5 minutes. If you ever can pay less than that to save at least 5 minutes. Take the deal.
Peace of mind does have a price and sometimes it isn’t even expensive.
The guidelines for creating a successful open source project is to release code often. The project needs to be and look alive. Well, this far, I haven’t really been honouring that guideline. That is, until today!
TAS, The Automation System (soon to be part of TTS, The Testing System) is published. It is in no way stable or feature rich enough to deserve a version number but there is some code in the GIT repository.
I have a pretty heavy sprint planned from today to the middle of November so expect this code base to grow quite a bit during the next few weeks.
Ohh, also, it’s currently GPLv2.
QA needs to be business driven. Everything we do needs to be business driven. We spend far too much time writing documents that will never be read. We spend far too much time on tasks that don’t bring us close to our goals. Like, pushing to complete test runs before a deadline, only to ignore the results and move on anyway. Don’t do waterfall. Don’t plan the test effort to the last two weeks before you are supposed to go live and ship. Dev will be a little late, then there will be a couple of integration issues and then you end up with three days to do a two week job and in the very end there will be less than zero time to fix any found issues.
And then we ship.
I recently came across this video and this is quite possibly the nicest, most beautiful, most functional, cheapest solution I have come across since the tin-can-wire phone was introduced to me.
Such pure genius. I want this in my house! How on earth did they come up with the idea to mix water and bleach to get this effect?
This people, is free as in freedom and as in free beer. For crying out loud, it even helps reduce waste! It wouldn’t surprise me if the next version emits pine scented air too.
Excuse me, I have to go buy a soda and some bleach.
At first I thought it was a bit of a stretch to call it a self healing system but honestly, it’s not. As long as you only deal with software failure, it can be fixed with software. Hardware is harder to fix like that (thus the option to finally escalate to a human admin at the end of the chain).
A guy (Patrick) at Facebook found himself doing the same things over and over again and started writing scripts that did these things for him. The number of scripts grew. The complexity of the scripts increased and after a while the entire team found them useful. At this point it is a pretty obvious step to turn this into a full fledged system and they did just that. Thus creating FBAR, Facebook Auto-Remediation.
The article doesn’t really go into the details but that’s okay. The thinking, and the methods used here are solid. The first stumbling steps of FBAR wasn’t the workings of a complete enterprise level tool. It was a few lines of code that helped eliminate time consuming and probably mind numbing manual tasks. It looks like it is polling at the moment, an event driven approach would have been cooler but hey, as long as this Gets It Done it doesn’t really matter. Besides, there will have to be an insanely big server farm for the polling to be an issue.
Right on Facebook. The last time we spoke, you didn’t have any QA but it does give me some comfort that you are in fact doing some of these clever things. Who knows, maybe the step to automating some sort of high level tests for your services isn’t that alien after all?
On a related subject, I’ve been working on TAS (The Automation System), which is now part of TTS (The Testing System). It’s bare metal, it’s light, it gets the job done. I need to make it good enough for dog fooding before I release the first drop. Any day now. Or, before Christmas =)
I recently switched back to Linux (Ubuntu 11.04) since it’s just so superior when it comes to developing new software (everything runs smoother). It was a little bit like coming home after being away for a really long time. Some things were exactly where I left them (like the terminal) but some things had changed quite a bit (Unity? More things just working). For instance, I was really surprised to find my mobile 3G broadband to be working without any fuss (plug in, select carrier, enter pin, done).
Do you know what else? As I was about to install Wine so that I could run Spotify, I noticed a teeeny tiny link at the Spotify download page. Spotify for Linux preview.
I followed the insanely simple instructions and just like that, I had Spotify running natively. It works. I haven’t found a single feature that is missing from the Windows version. It even comes with a snassy penguin on the Spotify icon.
This is so accurate that it’s almost scary. QA is far too often at the end of the pipeline. If you find something that is broken, not only will you see your planning and budget go up in smoke. You’ll also be responsible for delaying the whole project. No problem guys, we live to take your crap.
It doesn’t really matter if you know more programming than the developers. They have always looked down on QA and will probably keep doing so for the foreseeable future. Irony anyone? If a person is skilled enough to find flaws in your solution. Does that mean you are smarter than they are? No. No it doesn’t.
The moment you have completed that manual test case and have the results of your test run. All the time you spent on it turned into waste.
And that’s how you break someone’s spirit.
I know this is silly. You know this is silly. Still, it happens every day. Every single day.
But hey! It’s not like I am bitter about it or anything. Like a a friend and a colleague of mine keeps telling me: “This is great! This is what keeps you and I in business”
Thanks dilbert.com for the original material.