We seem to have gone from software is eating the world to being terrified of being eaten. As if software were a tiger in a pen at the zoo just waiting for someone to fall in and be devoured. The author of this article on The Atlantic thinks engineers need to start thinking about saving the world from software.
The author is a journalist and recalls several important software problems — Therac-25, recent hacking of car software allowing the hacker to take control, 911 system failures. There is a lot of strange things to unpack about what is wrong with software (developers not prototyping their code first) and how to fix it (developers go extinct and software is made through WYSIWIG editors). I want to add a dash of realism to the argument that is actually based in industry experience.
A colleague posted a question in a Skype thread about convincing people they work with about the value of a project. They have some co-workers that are very into 6 Sigma type process, where each aspect of a company is measured and accounted for (or so they think). My colleague was asking for some evidence that a test automation project might have return on investment. Or more concisely, that the money spent on a test automation project will some how come back in terms of revenue.
My initial take on this question is that it is perfectly reasonable. Software companies exist to make money, and any addition of employees or projects aren’t there for fun. They are added because of their potential to help the company bring in more revenue. My second take on this question, is that if you get to the point of having to answer questions about ROI, you have probably already lost the debate.
In a recent article, my colleague, Justin Rohrman, put the idea of stock options to shame.
The percentage of venture-funded startups that achieve even modest success is small. There are a thousand losers for every Facebook or Google. Riding the startup carousel is a great way to waste your twenties. Picking on the benefits of stock options in trade for life is an easy game.
Even worse, equity, often in the from of grants, can be a replacement for compensation — the company can below-market wages plus stock options.
As my friend Scott Barber put it, those stock options are essentially a lottery ticket. In most cases, investing twenty dollars in scratch-off tickets at the gas station is a better deal. You still get the cheap thrill, but don’t like the time.
Like I said, easy to pick on … but that’s not quite my life experience.
Allow me to tell you about it. Continued »
I got an email from a company today claiming they are planning to kill the resume.
I recently gave up on a several year experiment of not having a resume. Sometime around 2013 I stopped updating my resume with each job change. After a while, I forgot where the file was on my computer or in the cloud, just gave up, and declared resume bankruptcy. At that point, I was able to rely on my professional network, public reputation, and acquaintances if I wanted to get an interview.
I gave in and made a new resume 2 weeks ago. The no resume strategy only works for certain people in certain stages of their life. It isn’t working for me at the moment and I’d like to talk about that.
I read an indictment about work culture in the Silicon Valley last week. This article describes companies where employees working what used to be normal shift, 9 to 5, are now thought of as losers. Venture Capitalists throw money at founders who throw far less money at impressionable people. These people work 50 or 60 (or more) hour work weeks under the impression that they are building something important, or that when a liquidity event occurs they’ll get rich. The reality is that the VCs get rich sometimes, the founders get rich less often, and everyone else never gets rich. Never.
Work-life balance problems, and taking advantage of the good will of ambitious people is not a silicon valley problem. This happens anywhere you find software. I of course have my own story.
Most of the process I have experienced in my last several years while working at software companies was designed to create the illusion of speed to market, but very little actual speed. The development teams get a sprint backlog of entirely too many changes, work their way through them by spending too many hours in the office, and them move all the cards over to ‘test’ in JIRA. Testers get a few days, get through as much as they can and then the release date comes calling.
The teams I see going faster, have slowed down.
I spent most of last week helping a team of people run a software testing conference. The 10 months leading up to last week were spent hunting down venues and doing negotiation on rate, looking at hotels, reviewing catering, coordinating with speakers, and all of the million things that go into putting on a conference. Our event was 4 days in total. We kick off with a day of tutorials, that is followed by two conference days, and then there is a post-conference event on the last day for a smaller group of people.
This was my first time being so involved in a large technology event, so of course I have a few thoughts for other people that might be doing this in the future.
One of the questions was “What does good software testing look like?”, which I found fascinating.
Take two teams. One has strong tooling that runs for every commit, that scales out to a grid of 256 simultaneous servers, giving feedback in five minutes. Another team has a component architecture; they make small changes and deploy them independently. The second team has high confidence that a change only impacts that one component, automated “contracts” to check correctness, but no end-to-end GUI checks. Instead, team two does the rollout, checks a few flows in production in a test account, and relies on incremental rollout and intense monitoring to find problems.
Both of these could be excellent software testing in context. For that matter, good testing for a pacemaker or avionics controls could also look very different. I want to describe a model, a sort of checklist, to see if testing is “good”, and what gaps exist.
Between the question and lightning talks later that day, I came up with BRR I TV. Continued »
I got a phone call from a technical recruiter last week. These calls are usually painful, but I had a couple of minutes and could use some entertainment, so I took the ride.
The recruiter said she had a remote testing position available and had found my resume in their database. I haven’t kept a resume in several years, so how she had that is a good question for another day. She started asking me questions, and I felt like I was running through a check list. Can you program in Java, how many years experience do you have programming in Java? Can you write SQL, how many years of experience do you have writing SQL.
Luckily the call was short, maybe 10 minutes in total. I didn’t perfectly line up with the checklist, and the company this recruiter was representing was low-balling on the hourly rate, so we said goodby and parted ways. This 10 minute phone call reminded me of what I like in good technology recruiters.
I had a breakfast meeting today with a local tester / manager type person that has recently decided to venture out and build his own company. He was working as a test manager for a company in another state and over time the company decided that role was no longer necessary. Over his tenure, he built up a practice group, broke up the independent test group and moved testers to development teams, and built a sustainable model.
Of course, once the teams were merged with development and had learned to sustain themselves, there wasn’t much need for full time management.