I didn’t enter last weeks challenge, so I’m not going to insist that you vote for me. (In fact, the last time I forgot to even vote for myself!)
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.
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.)
I 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…
For some reason, when I saw the poster for the new movie “Fury,” I misread it as “Furry” and saw a beard on Brad Pitt that wasn’t really there. I’ve tried to correct these errors.