Category Archives: Computing

Articles about computers and the IT industry.

QA Mindf**k

When I read Rand’s recent post on QA I was pretty much entirely in agreement. A good QA team is a real asset to any project, especially large ones. However, a bad QA team can be a huge liability and cause problems for everyone.

Bad testers don’t understand the product they’re working on. They follow test scripts they don’t understand, write short, inaccurate bug reports and make no attempt to appreciate the context of any error.

This should all be obvious from Rand’s post. What’s maybe not so clear is what problems it causes.

What follows is not the tale of any one project but all of these things have happened at one time or another.

  • The QA team starts too early in development and doesn’t comprehend that it’s working on unfinished software. Many bug reports are raised for things that are known to be missing or incomplete.
  • The real bug reports contain so little data that they can’t be reproduced, or at least can’t be replicated without a lot of effort.
  • There are many bugs in the test scripts too, but since the QA team have no real understanding of what the software is supposed to do they refuse to take a second look at them.
  • Since QA don’t understand the desired functionality, important modules are not tested, leaving an unpleasant surprise at a later, critical stage of the project.
  • As the bugs pile up, the development team have to spend more and more time working on them instead of completing the project as originally planned.
  • Eventually, overwhelmed, the project is replanned.
  • This time the development team is under increased scrutiny. Metrics – bugs raised, time to fix, closure rate – are tracked.
  • Collecting all the metrics slows down development further.
  • Bugs pile up, the metrics start taking over the project.
  • The numbers mean everything. Few actually understand what is wrong, only how many defects there are.
  • Ironically, the pressure of developing the remaining features, working on the stream of defects and the new management overhead result in a decrease in quality as the same people are expected to do more work.
  • Management adds more people to the project to solve this problem. Unfortunately Fred Brookes wasn’t wrong.
  • The new project plan fails, further replanning…
  • Rinse. Repeat.

It’s a death spiral. Longer hours. Weekend work. Replanning. Delays. People, frustrated, leave. It’s toxic.

More often than not, projects like these get cancelled but sometimes, for political reasons, they have to be delivered. In order to do so the cycle has to be broken. This always requires someone brave to come in, slash the scope and come up with a truly realistic plan.

But it’s best just to have a constructive relationship between the development and QA teams. After all, the goal for everyone should be to deliver the best possible software.

Java and Yosemite

"To view this web content, you need to install the Java Runtime Environment."
“To view this web content, you need to install the Java Runtime Environment.”

Ever since upgrading from OS X 10.9 to Yosemite (10.10) I’ve been getting the above error message periodically. As far as I know I have no software that needs Java to run.

When I asked on Twitter, the most common suggestion was that it was the Adobe updater. But I don’t have PhotoShop or anything else likely installed.

I checked the system logs, but, again, nothing.

The final obvious — for a fairly broad definition of “obvious” — was in System Preferences. If you look in the “Users” pane, you can find a list of “Login items,” programs that are started when the computer boots. (I figured this wasn’t likely since the alert pops up at all time but it was worth checking.)

think I found the solution but I found some interesting (if you’re geeky) new commands that I thought I’d talk about before I document the actual solution.

So the underlying system that the Mac uses to start programs periodically is called ‘launchd’ (or “launch daemon”). It’s kind of an amalgam of init and cron and a bunch of other standard Unix processes, a concept that is controversial in some circles. The interface, I found, isn’t terribly intuitive.

In addition to the long-running process, there’s a configuration program called ‘launchctl.’ The man page runs to several pages. ‘launchctl help’ is only slightly shorter.

I find the ‘list’ subcommand in the “legacy” section and give it a try:

$ launchctl list | grep -i java
- 0 com.apple.java.updateSharing
98767 0 com.apple.java.InstallOnDemandAgent
$

The columns are Process, Status and Label. So we can see that Apple’s Install On Demand Agent is running but not what triggered it.

There’s also a sub-command called ‘procinfo’. It’s not even “legacy” so it must be good… I certainly can’t complain about the volume of information, though I couldn’t claim to understand a good chunk of it.

Ah, but then I see ‘blame’ which the help tells me ‘Prints the reason a service is running.’ Ooh, yes please!

$ launchctl blame 98767
Usage: launchctl blame <service-target>
$

Er, so what’s a service-target?

Anyway, long story short, I find that the text in the man page isn’t entirely clear and that I need to do this:

$ launchctl blame pid/98767/com.apple.java.InstallOnDemandAgent
Not privileged to signal service.
$

So, I don’t know. (If anyone could give me a sample command I’d be grateful!)

But, after all this messing around I did find something. The configuration for ‘launchd’ is scattered around the filesystem in directories like ‘~/Library/LaunchAgents’. I grep’d in that directory for “java” and found a single reference to it in an application that I installed ages ago and never used. The file is called “com.facebook.videochat.stephend.plist”. I deleted it and the other binaries related to it and then restarted.

Clean so far…

ShareEverywhere

ShareEverwhere main screen
ShareEverwhere main screen

I was so busy when it came out that I never quite got around to blogging about it here: I have a new app out! It’s called ShareEverywhere. It is built exclusively for iOS 8 and uses the new, built-in “share” functionality, allowing you to share to a good number of services from any app that uses the standard share button.

When I first wrote it, I wasn’t sure how many, if any, developers would build share widgets into their apps. Now that we know the answer is “a lot of them,” I still use ShareEverywhere because it beats having a dozen widgets hiding in your action menu. And there are still services, like Pinboard.in, that don’t have their own native apps.

It’s available now in the App Store for your iPhone or iPad. It costs £1.49, $1.99, €1.79 or your local equivalent.

How do I do “X” in Swift?

Maybe I have some duff feeds in my RSS reader. Maybe I have a few poor choices of people that I follow on Twitter. But I see links along these lines all the time:

How do you do something in Swift?

The answer is, almost always, exactly the same way you’d do it in Objective-C!

You want to do pull-to-refresh? Same.

You want to play with location services? Same.

You want to display one of the new UIAlertControllers? That’s the same, too.

Why? Because they’re all part of the underlying framework, the framework that’s there whichever language you’re using. That includes both Apple-languages — Swift and Objective-C — and everything else, C#, Python, Ruby.

That’s not to say that there is nothing useful to write about Swift. As a new language there are lots of things to write about, new ways of structuring your code, better ways of implementing algorithms. Tricks to avoid common errors or pitfalls. But interfacing with the OS? The syntax changes slightly but the code is pretty much the same.

Starting Coding

Graham Lee’s “Why is programming so hard?” made me think about how I started programming and whether I’d be coding now if I was twelve.

When I began, I had a Sinclair Spectrum. Back then, home computers booted into a programming language (BASIC typically) and to do anything you needed to know at least one command. To be fair, even then many people didn’t get beyond J, Symbol Shift-P, Symbol Shift-P (‘LOAD “”‘, the command used to load a program from tape).

My first memory of using a Spectrum is trying to type in a program from the manual. This was harder than it sounds as the Spectrum had a weird-and-wonderful command entry system in lieu of a lexer in the BASIC interpreter. I can’t even remember if I got it working, but I was hooked.

I still played games, but I occasionally looked at something and thought “how do they do that?” I’d then try to replicate it. Over time I’d spend more time coding and less gaming. I’d also read magazines and type in code from books and magazines. Then as now, working with other peoples code can be very instructive.

(But, to answer the question in the original blog, I can’t really remember the process of going from a few lines of trivial code to something more complex.)

I think three things — at least — were appealing at the time.

First, I had one. I guess that sounds obvious but even a few years earlier that wouldn’t have been a given. Prior to my interest in computers, I was fascinated by cars. I could identify all the models on sight, memorised the statistics and could tell you that a new Ford Fiesta had terrible handling. But I didn’t really know any of the basics about actually driving as it would be another six years before I could get a provisional licence and start taking lessons. The possibility of owning a car was even more remote (I’ve still never owned one!). There’s a dramatic difference between reading about something and actually using it.

Secondly, it was possible to pretty much understand the whole machine, from the hardware right up to the BASIC interpreter. I didn’t, of course, but nothing seemed out of reach. I started in BASIC but I also played with Z80 assembler. The Spectrum was a simple enough machine that working at that level exposed a lot of what was happening with the hardware — interrupts, memory mapped hardware — even without breaking out a soldering iron.

Thirdly, even the state of the art seemed achievable. I was writing programs to fade text in from black to white and animating crude figures around the screen. What was Jet Set Willy but more of the same? (That’s a rhetorical question. In practice the difference was pretty substantial, but it was still one guy sitting alone at home.)

There was a learning curve but I thought that everything was understandable and figured that I could do even the hard stuff. This really spurred me on, made me try things and play around. There is no better way of learning; nothing kills my enthusiasm more than thinking I can’t solve a problem.

Fast forward to today and, while most people own a computer, the machines are not fully understandable and the state of the art seems distant and impossible for a mere mortal to achieve.

Look at a game that appears as simple as Monument Valley. It doesn’t take long to realise that it’s not that simple. Where would you even start? What would you need to understand just to put a few of your own pixels on screen?

I fear that I would get overwhelmed by the amount that I didn’t know — and possibly would never know — before I got interested enough to keep going.

So where is the “in” to programming these days?

It’s easy to get hung up on the programming language or environment, but I don’t think that’s the key. If it’s interesting people will put in the time to get past those kinds of obstacles. (Whether they should need to or not is another question.) Instead, we need projects that can start small and gradually get more complex, and they have to be in environments that the user understands, and the results need to look immediately impressive or be immediately useful.

This is why I don’t think learning to code in, say, Python is likely to be compelling for many people. It is programming, but few people use command lines any more and the results don’t look impressive. Printing the numbers from one to ten? Yawn.

Web programming is, perhaps, the obvious example. People start copy-and-pasting can graduate to writing code. Please don’t start the BASIC versus JavaScript debate in the comments.

I have heard about (but have no experience of) building “mods” for Minecraft. Much as I did, people play the game and get hooked. Rather than trying to replicate features, they try to modify them or enhance them.

Once people have left academia, the most popular method of starting programming that I’ve seen has been Excel. People start building complex spreadsheets, then add a few macros and then begin playing around with VBA. At each stage they can do a little more than they could before and at each stage it’s useful.

So, back to the original question: would I be programming now if I was twelve? I think the most likely route would be through something like Minecraft, but I never got hooked on anything more complicated than Bomb Jack so I have to think the answer would be no. For my own sanity I probably should think too hard whether or not that’s a good thing.

Recruitment Tests

Over the years I’ve been asked to do a lot of programming aptitude tests. I’ve had to do some in the last couple of months and I’m deliberately writing this now before I get the results back of the most recent one so you won’t think that this post is just sour grapes…

I’m not going to get into the details of the tests because it doesn’t really matter what they are or who administered them for the purposes of this post.

I don’t like these tests. I don’t think they work well for either the candidate or even the company that is using them.

An obvious complaint is that the tests bare little resemblance to Real Life. On Twitter I cynically suggested that a more realistic test would involve trying it write a program based on an ambiguous and constantly changing specification. The test would end when you quit in frustration.

A bigger issue, I think, is the amount of time it takes and when they take place.

Let’s tackle the latter point first. Every time I’ve been asked to take a test it has been before I’ve spoken to anyone. All they’ve seen of me is my CV/resume. All I know about the company and job is what I see on their website and a brief job description. Am I a nice person? What is it like to work there? Neither party has any idea.

My objection to this is that we both have a lot to lose if the recruitment process goes wrong. I always consider an interview to be a two way process — they need to learn about me and I need to understand more about them — yet the very first stage in the recruitment process is them demanding a couple of hours or a days commitment of my time but only a couple of minutes of their time.

To be clear, I have sat on the other side of the table. I do know that far too many candidates have no real hope of filling the position. But, equally, you don’t want to push away the most qualified candidates.

Two hours is a good a chunk of time. A day is a lot of time. If I already have a full time job and am just looking to move to something better how are those requests going to fit into my schedule? Badly I’d hazard. A full day is half my weekend. Two hours is an evening. (At least! Finding two contiguous hours at home these days is a challenge.)

Sure, the least qualified candidates will fail it but the very best candidates probably won’t even take it. They’ll just say “no” and move on to an opportunity that requires less upfront effort.

I came across this quote earlier today: “Never allow someone to be your priority while allowing yourself to be their option” (either Mark Twain or Maya Angelou, not sure who said it first). That seems very appropriate here. Should I really prioritise these companies over others? Are these companies that special? (A possible exception would be really big names like Google or Apple but I think it’s fair to say that none of the companies that have asked me to do tests have been in that class.)

So, what’s the answer? Certainly there’s no silver bullet that pleases everyone and finds only the very best matches. Having thought about this I think the best compromise would be asking candidates to do something as basic as FizzBuzz (but probably not exactly that as it would be very easy to Google the answer).

To people who have never done any recruitment this probably sounds incredibly patronising. All I can say is that I wish that were true.

And if you really want to administer a test that takes more than thirty minutes, I think they’d be more acceptable much later in the recruitment process. Or failing that, offering to pay isn’t a ridiculous suggestion, though I suspect most employers would argue otherwise.

Afterword: After writing all this, why am I even taking the tests? Mostly because I’m currently between jobs so it’s difficult to argue that I don’t have the time.

After-afterword: I passed the test. I still don’t like them.