A Ruby course to avoid

"Ruby Programming from Scratch - Beginner and Advanced" by EduCBA IT Academy

I'm cheating somewhat in reviewing this Udemy course, because I haven't finished it.  And I doubt that I ever will.  I finally realised I was falling victim to the sunk cost fallacy and gave up. 

That was in Lecture 78 (of 175), in which our tutor's uninspiring delivery is all but drowned out by what could be someone chasing electric cabling into a wall with a mallet and bolster. (Or - for a more attractive image - perhaps chiseling out a piece of fine marble sculpture.)

The list price for this course on Udemy is a jaw-dropping £233 (That's right - two hundred and thirty-three) which I imagine must make it one of the most expensive courses on the site.

As I said in an earlier post, you should never pay full price for a course on Udemy*. I paid $10 for this one, but regret even that. $10 seems like more than the creators spent on putting the course together.

Format

The format of the course (unless it changes in the sections I haven't watched) is to go through elements of Ruby, define them, and give a basic example of the relevant syntax. 

There is no encouragement for you to try out the constructs for yourself: no exercises, or project running through the course.

I suppose it could serve as a look-up for a particular syntax with an example of its' use.  But then you could just look up the ruby documentation yourself.

The presentation is flat and uninspiring. Worse, it seems to have been put together with contempt for the student.

Lazily produced

Aside from visible basic spelling errors on the site like those above, the actual video content is poorly and lazily produced.

For example, within a single video lecture we start with a discussion of the second point on a slide (string interpolation), before the video jump-cuts back to the first point on the slide (explaining what a string is). Clearly wrongly edited.

It gets worse in the section on comparison operators.

It seems odd that the first lecture in that section launches into discussing the second operator (!=) in a table of them.  "What about the first one?", you think.  Maybe == is so obvious it doesn't need explaining?

But, no, after a couple of minutes the video jump-cuts back to give a general introduction to the table we've already been looking at.... and describe the == operator.  And at 5 mins 40 in the same video we jump again to what was obviously meant to be the start of the lecture - with a basic definition of what a comparison operator is.

All confusing enough, but it gets worse as the next video explains the != operator to us again as if we'd never seen it before.

Quality control

I can only conclude that they didn't bother to make even basic checks of the course content before publishing it. And Udemy clearly don't practice any quality control themselves. I should have followed my own advice.

Before long, even the small things about this course were getting on my nerves.

Like the poor audio with various distracting background noises. 

And that every time the tutor wants to run one of his ruby files we have to watch him open a command prompt and "cd" four times to get to his working directory. If you can't organise your presentation a bit better, why not at least cd once with the full path?!

*takes deep breath*

There are, of course, a number of alternative Ruby courses on Udemy.  A couple which I've tried and would rate higher than this one are:

http://www.udemy.com/learn-ruby-programming-in-ten-easy-steps/

http://www.udemy.com/ruby-programming/

Wait for the $10 per course offers, though!

*Except Alan Richardson's magnificent WebDriver course, but even that can be taken outside Udemy here.

"The Leprechauns of Software Engineering" by Laurent Bossavit

"The software engineering profession as a whole needs to feel ashamed that it will so readily repeat, as if it were a universal truth, something that is only a half-baked figure from a single project in a single business..."

- Laurent Bossavit

Laurent Bossavit's book questions how truisms in software development come into being without compelling evidence. And it specifically debunks a few of them - like the "10x" variation in productivity between developers; and the "fact" that defects are exponentially more expensive to fix the later in the development process they are identified.

Unfortunately, we accept and repeat claims that sound intuitively plausible like these without stopping to think that we don't even have universal agreement on how to measure "productivity", or on what exactly is the definition of a "defect".

Clearly decisions should be made based on evidence, not on hearsay or what "everyone else is doing". 

Organisations shouldn't adopt Agile practices, for example, just because they're fashionable. That wouldn't be rational.  And yet....

If I ask myself how this adoption of folklore happens, I can think of a couple of possible contributing factors. (Given the topic, I should stress that I have done no research, and can offer no evidence.)

How do these claims propagate?

As I read the book I was reminded how information-transfer often takes place in "punchy" presentations, documents and web pages. 

Points need to be made quickly, often visually. A few individual data points get represented as a more dramatic curve for "clarity".  If we have a point that we want to get across then the cliche (along with including a Wikipedia definition) is to Google for some - any - source that appears to back us up with statistics. 

We don't check any deeper for proof of what we already know. No-one really has time for detail anyway.

As Bossavit points out: "If you can cite a source for your claim then it is probably true" is a dangerous heuristic.

If someone tells us that "evidence shows" 71% of failed software projects suffer from poor requirements then, fair enough, we don't have the time or inclination to check that.
But that doesn't mean we have to believe it.
And why do we think that what applies to other people's projects applies cleanly to ours?

Why are these claims accepted?  

Well, personally I suspect I fall for something like the "argument from authority" fallacy.

I tend to assume that everyone (and I do mean everyone) in the software world knows more than I do, especially if they're confident enough to state those views publicly. 

But knowing about some things in software doesn't equate to being an expert on every topic. Nor mean that they can be bothered to fully research the claims they repeat any more than I can.

My default position is too often a trusting "ah - I didn't know that" rather than "what's the evidence?". 

(Luckily the fact that I have now have a blog myself should rid me of the belief that writing a blog automatically makes you a credible source for anything.)

Critical thinking

Bossavit wants to see a bit more of what Testers like me should already be used to applying - critical thinking.

He also believes that research into software engineering should be informed by the methods of the cognitive and social sciences, and not simply look to arrive at quotable metrics by taking shortcuts.

In leading us through exactly how he has uncovered the lack of evidence behind these "facts", Bossavit gives a run-down of how we can use Google for leprechaun hunting ourselves - and encourages us to practice on claims we find questionable.  

I might try it on some of those statements made about the miraculous properties of test automation.


"The Leprechauns of Software Engineering" by Laurent Bossavit is available now as an e-book from Leanpub.

Testing in the Pub Podcast, Episode 15 - Pairing

Stephen Janaway and Dan Ashby's "Testing in the Pub" podcast is a nice source of free learning, and they deserve thanks for taking the time to put it together.

Having started early last year they're up to Episode 15 already with this one about pairing.

For years I worked as a sole Tester in an organisation where all the dev was outsourced. I used to dream of pairing (ok, not literally dream) if only to have a second set of eyes checking what I was doing.  Since then I've been fortunate to have the chance to do some informal pairing with other Testers and have really found it valuable.

In this podcast I found it particularly interesting to hear Janaway and Ashby talk about how pairing can mean more than just sharing a screen with another tester to tackle a challenging scenario; or with a developer to provide immediate feedback on what they're coding.

As Testers, pairing can also help us influence decision-making; raise our profile in the team; and enlighten those who don't fully understand the role of testing - or believe the misconceptions. We can add value to a project pairing with other roles than just test and dev. (I've had a valuable session pair-testing with a Project Manager in the past.)

Pairing is also a great way of learning. Dan Ashby talks about a nice set of simple question words he uses as a framework whilst pairing to gain information and understanding which will inform testing decisions.

As someone who finds Session Based Test Management a useful approach to Exploratory Testing, I'm embarrassed I hadn't already thought about applying a similar approach to pairing. 

Don't just spontaneously attempt to start a pairing session with a colleague. Get their agreement in advance, have a goal for the session and put a time-limit on it.

But before you do any of that, as the guys discuss, you might need to convince Management that pairing is a good use of resources.

Lots to think about and act on after listening to this discussion. And it can be easily digested during your commute!

You can access this episode, and all of the Testing in the Pub podcasts at: http://testinginthepub.co.uk/testinginthepub/

"Hands-on Mobile App Testing" by Daniel Knott

Daniel Knott has produced a great book, full of practical information.

Next time I have to undertake a mobile testing project this will be my starting point for gathering ideas.

Knott doesn't skimp - giving us everything from an overview of the history and growth of mobile technology to the factors you should consider to ensure a successful app launch.

Indeed, my overriding impression of this book is how practical and useful it is if, like me, you're not as familiar with mobile testing as you'd like to be. It made me realise how shallow some of the app testing I've done in the past has been.

As context to inform your test approach, the book describes the special challenges of mobile testing, eg. device fragmentation and unique hardware factors like the use of sensors.

There are also comprehensive chapters on "How to Test Mobile Apps" and on mobile test automation. These chapters work, often literally, as ready-made checklists which you can put straight into action.

Having read through Hands-on Mobile App Testing once, I'll be going through it again to try out some of the practical test ideas and exercises Knott outlines.  For example his suggestion (which I won't detail here - buy the book!) on how to use the information app providers publish about their updates to improve your own testing and test design.

It feels like nothing is left out here, with discussion of topics like: understanding and profiling your user; usability; security - even how you might source and manage those ever-changing devices.  And if you need to go deeper on a subject Knott points you towards sources for that too.

You'll find information and advice relevant to whatever testing you do. Knott's section on planning a mobile testing strategy is helpful when compiling any test strategy; his chapter on skills mobile testers need is applicable to testers in any area.

If I have one tiny nitpick it's that there are some "literals" in the book which might have been picked up with another proof-read. (They're not spelling errors that a spellcheck would see.)

But this is understandable given the self-published approach through Leanpub, and as Knott has announced on his blog that a deal has been done to publish the book through a major publishing house then I'm sure those will be polished out.
In any case, it's a minor concern which didn't impact the quality of this book for me. I strongly recommend it.

Please note:

Since I wrote this review of the Leanpub version of "Hands-On Mobile App Testing" a revised and expanded edition has been published.

Using Udemy for Online Courses

Udemy.com is a website offering online, video-based courses.  A large number of which relate to technology, programming - and even specifically to testing.

I have bought a lot of online courses from Udemy. So many, in fact, that I always have a backlog of ones in progress or waiting to be started.  I expect many of the posts on this blog as it develops will relate to Udemy courses.

Courses can be taken on the website, of course, and there's also a mobile app which allows video lessons to be downloaded and watched offline. (I use the Android app - I assume the same is possible on iOS.)

The latter is very handy for learning during a commute, although some courses will work better than others if - like me - you don't have a tablet.  Even a large phone screen doesn't always give a clear view of what's going on in an IDE or command line.

Udemy don't produce learning content themselves but rather act as a kind of clearing-house for courses produced by "trainers" ranging from individuals to organisations; and from the highly professional to the decidedly amateur.

Sadly there is no guarantee that a course sold on Udemy will be of good quality - and you might not find that out until after you've bought it.  Udemy do offer a 30-day money back guarantee although personally I have no experience of trying to claim on it.

Here are a few points I follow when deciding whether or not to buy Udemy courses.

1. Never pay full price for a course

With a small number of exceptions that course you're interested in on Udemy will soon be available at much less than the full price if you just wait a little while.

As I mentioned, I always seem to have a backlog of Udemy courses and that's mainly because I'm easily tempted to buy them in the regular sales and offers.  To give you an idea of what's possible here's an excerpt - just an excerpt, mind you! - of my Udemy purchase history.

Many instructors offer multiple courses on Udemy and these giveaways are "loss-leaders" so that they can market other courses to you.  But that doesn't mean you have to buy the other courses - and many of those will also be offered at a cut price if you wait a while.  

In fact, you can learn without paying a penny. There are a large number of free courses available on Udemy.

2. Sign up before you buy 

By signing up, and maybe wishlisting a few courses, you'll soon start to receive emails with the offers that feed my first point.  Registering will also allow you to .....

3. Preview the course before you buy

Once you're signed up to the site you can generally select a free preview of the course you're interested in.  This amounts to a small number of sample "lessons" from the course which you view.  Of course, these sample lessons don't tend to give away any valuable content - they might just be an introduction, or cover how to install the software tools the course uses - but it gives you the chance to gauge the quality of the production and the presenting style of the trainer. Do they speak clearly and engagingly, or do they have a monotonous delivery that you'll struggle to pay attention to?

4. Look at the course's "Discussions" thread

The main page for any course, which lists out the individual lessons, will also have a discussions panel available on the right.

Look here to see whether the instructor is engaging with their students and providing helpful feedback.  It's not uncommon to see discussion threads where seemingly straightforward questions placed by students weeks or months ago sit unanswered.  

On the other hand, the best instructors can be seen clearly taking the time and effort to provide extra value - and these are the kind of instructors who are most likely to add new material to the course over time or refresh parts that go out of date.  Remember, one of the benefits Udemy push is that you'll have lifetime access to the courses once purchased.

One more thing...

At the time of writing it looks like Udemy have now introduced pricing in sterling for UK customers - and it doesn't work in our favour.  A quick check suggests that courses priced at $99 have a sterling cost of £79 - when the current exchange rate would work out to around £65. 

So a disincentive for UK users, perhaps. Certainly another reason to always hold out for those cut-price offers.