We’ve covered the decline and fall of IBM here at uncharted waters – including the economics that drive staff reductions (“layoff”) in favor of low-wage countries.Particularly vulnerable are the more senior tech workers, which in today’s market is anyone over thirty-five. IBM, in particular, has a reputation for layoff of technical staff around the age of fifty.
Today’s question: Is that sort of staff reduction really required, does it make sense, and is it the right move for management?
Not only is my answer no, but I believe the “no” answer is embedded in the MBA curriculum at nearly every major university in North America. That no one seems to be reading it is the tragedy.
So I’ll start with a story. Continued »
There are plenty of approaches to software testing. The most common is probably what I like to call “wamby-pamby confirmatory tests.” These take the requirements, turn them sideways, and test one simple example for every type of test. So, for example, a good log-in in works, a bad username or password does not. Confirmatory test are simple, cheap, obvious … and they miss a lot.
One huge category that confirmatory tests miss is the platform. Printers, for example, have problems when the tray is removed mid-print. Laptops used to have problems when the lid was shut during work. Websites fail to render as the user resizes the screen. Add to that invalid, blank, or incorrect input — it is common that programmers fail to consider incorrect input, so the results, while unpredictable, are probably not “right.”
Quick tests, sometimes called “quick attacks”, are a set of tests that cover these sorts of problems. They easy to come up with, cheap to run, yield bugs fast, and do not require an understanding of the underlying platform. Continued »
For as long as I can remember agile has been synonymous with sprints. To do agile, we had to use some sort of iteration, and today that means a two week sprint. We also had to do the required ceremony and ritual of multi-hour planning meetings where the team commits (aka, gets tired of talking about it and says fine) to how much work they can get done over the next two weeks.
I’ve been asking what if questions lately — what if we don’t have a standup every day, what if we don’t do sprints anymore — to get conversations going around what these things really do for us. The team I’m working with decided to do an experiment to find out an answer to one of those questions. We haven’t done sprints for the past few weeks. Here is how that is working.
The other day I was talking to Jim Holmes about test improvement. He pointed out that just starting out with Exploratory Testing is only improving one area in isolation. Working on that one system cannot transform the entire organization. Jim isn’t alone, Fred Brooks argued the same thing in his 1986 essay No Silver Bullets: Essence and Accident in Software Engineering. Brooks borrowed the subtitle “Essence and Accident”, from Aristotle.
I would argue that starting with test can provide the opportunity to improve the entire organization.
Let me tell you how.
Google was well known at one point for having a requirement that 20% of employee time be spent off project and on innovative work. This is where GMail, Google News, Google Talk and so on came from. OK, so not all of those are exactly smash hits, but GMail is basically synonymous for personal email now. GMail happened because Google saw the value of letting people pursue the intersection of personal interest and company value a few hours each week. Most companies are hesitant to offer innovation time. There is risk that employees will use it as an excuse to surf the internet for a few hours, or just mentally check out and go home.
I want to talk about a good experience with time spent in innovation and exploration.
The problem comes when none of it works. Continued »
Linkedin keeps suggesting that I friend request ALL 978 of the people I have EVER emailed who are also on Linkedin. I am considering clicking “add connections” so it will just stop. Some of those people will invariably click the “I do not know this person weirdo stopit” button.
Except it will not stop.
LinkedIn has figured out the same viral strategy that made Sid Meier’s Civilization series so addictive. As soon as you finish one challenge, another appears. Invite someone you don’t know to LinkedIn, and you’ll see a page of potential people to invite. Tag someone having expertise in some_subject, that person will be replaced with another. Click the link to fill in the information about your high school, you’ll be asked to fill in information about middle school.
Surely the experts at LinkedIn know this annoys us. As networks fill with people we sort of remember from that one office party they actually become weaker. As online profiles bloat it becomes harder to get a quick summary. We lose productivity.
It turns out that Senior Management at LinkedIn has incentives to make the software addictive and viral.
You could say LinkedIn’s own management is addicted to addiction. Continued »
If you’re anything like me, you’ve heard a lot about Blockchain. According to some, it is a distributed ledger technology that will make middle-person companies like Airbnb, Uber, Turo, and Taskrabbit obsolete. Others claim Blockchain will enable people to securely document their land ownership, jewelry, birth certificates, proof of insurance, all while creating restrictions on who can have access to that information.
The software tester sees a lot of hype and not a lot of substance.
Then again, I said the same thing about Mobile Phones. Back in 2000, back when the screen for a phone was something like 6×6 characters of text, Joel Spolsky pointed out that the mobile web was essentially a joke. Joel was incredibly wrong; it was more that the time of the Mobile web had not come yet. We needed Apple to bring us the iPhone. Today, 52 percent of Web traffic is mobile.
So what is the real potential for blockchain (in plain English) and how fast might it do exactly what to change the world?
Today’s column is for everyone wondering just that. Continued »
I spent part of last week at the Targeting Quality Conference in Cambridge, Ontario, Canada. That conference is hosted by the Kitchener-Waterloo Software Quality Association, and is commonly known as “KWSQA-Conf.” During the session I spent some time at the DevOps tutorial with Lisa Crispin, Rob Bowyer, and Mike Hrycyk. One of the exercises was designing your own Continuous Delivery Pipeline.
Given a real, large, familiar website like Facebook, Google or Kayak, we had to come up with a bug or feature request then design the pipeline for that feature.
Instead of dealing the excuses of our painful reality — where the database is non-relational and the transactions need to run in batch overnight and fill_in_problem_here — we started by removing all obstacles and design an ideal state.
It is a good exercise.
The challenge I see is moving from “regression testing” to a continuous delivery model. The problem isn’t coming up with the ideal state, or mapping out the existing state.
The problem is minding the gap.
I stumbled across this Quora question via a Forbes article and then fell into a Reddit rabbit hole. There are musings on how to handle bugs and how to write readable or unreadable code. Someone wrote a note about bad programmers writing a lot of clever code, good programmers writing as little as possible, and the best programmers deleting code. And there was one interesting note stating that programming skill isn’t even important in the life of a programmer.
I haven’t been workin in tech for 20 years, I think I’m close to 15 at this point, I’d wrap it all up as the value of experience. Don’t worry, I have an example.