The year was 1999. Dial-up service was the most popular way to get online, people used to drive to stores to get DVD’s – and compact disks. The iPod would not exist for two more years and MP3 players were awkward and hard to use. What most college students did have was a CD player and the ability to “rip” CD’s to their hard drive.
A young college student named Sean Fanning had an idea for a music-sharing service, which would become Napster.
Sean was a college sophomore without much computer science training. He certainly didn’t have the legal background to do music sharing. If he had, he wouldn’t even have started the project. I call this idea of not knowing something is a bad idea, and doing it anyway, the “napster effect.” It is responsible for a great deal of the innovation in the world — and a fair but of pain for the technical people.
Two months ago I started to take a course on Udemy building secure cryptocurrency. The course walks you through downloading the code for bitcoin, which is open source, then rolling your own network copy of it.
Then this showed up in my Github alerts:
This is a real vulnerability in the core bitcoin code that allowed the “contributor” to steal all the bitcoins from anyone using a bitcoin “wallet” called Copay.
It turns out, like the unsinkable titanic, my secure cryptocurrency isn’t.
It’s December, the time of year when real IT pros are so busy working they look up and realize it’s Christmas Eve. They don’t have anything for family, let alone “Christmas Stocking Stuffer”-sized gifts for friends and peers.
Don’t be that person.
For the fourth time, I’m going to take a crack at suggesting some Christmas Stocking Stuffers for you. And, yes, I’ll do it for free. Continued »
I mentioned in my last post here that I start a new full time position as a developer next week on Monday. I have done a lot of tester interviews over the last (nearly) 15 years, and for the most part they are obscenely easy. To the point it is obvious that most people don’t know how to tell whether or not someone is competent. Normally, I’d get questions about my experience in agile, they would ask a handful of questions about definitions of words commonly used in testing (regression test, smoke test, you know the drill) and then the interviewer would ask me how I would test a thing. The last thing I was supposed to imagine I was testing was a cash register. Sillyness.
This isn’t going to surprise you developers out there, but dev interviews are actually hard and stressful. I was surprised how different they were and in particular how different they felt.
Last week IBM bought Red Hat for $34 million; this week HP Enterprise is buying BlueData. Blackberry is purchasing Cylance; Oracle is purchasing Telari Networks.
In my twenty-odd year tech career, I have been purchased twice. My consulting company has also had one acquisition offer that we turned down in 2014. Many of my peers have gone through acquisitions, and all of us have faced the same set of questions.
- Will things better?
- Should I look for a new job?
- Should I start looking for a new job now?
While mergers and acquisitions are each sold separately, I find that if you look hard enough, you can usually find clues about where things are headed.
Here’s how to find them.
These are my last few days as a tester for the foreseeable future. On Monday, I’ll be moving out of contract work and out of testing at the same time, and into a full time position as a developer. I have been wanting to make this career hop (not exactly a leap) for the last several years, but a combination of fear and being a contractor has held me firmly in place. No one wants to pay a contractor to learn how to write production code, and well, I think the fear of jumping into a new skill set after having spent 15 years dedicated to something already explains itself.
So, why am I doing this?
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.