Quality Assistance

I’ve had a gut feeling for a while that the existence of a dedicated QA team actually leads to more bugs, not fewer, by letting developers off the hook for the quality of their software.

It was fascinating for me to learn about the approach that Atlassian takes to ensuring the quality of their Jira product. The presentation below by the head of QA for the Jira team sums up their almost heretical approach to quality assurance, which they think of more as quality assistance.

I love their idea that QA experts should function more as testing consultants that are charged with helping the developers to be better testers themselves, with the ultimate goal of the testing consultants moving on to other things once the developers are self-sufficient.

Instead of pair programming, how about pair testing—where a QA expert pairs with a developer to do exploratory testing of the developer’s work.

It’s so interesting to see how they’ve basically inverted the typical flow of activity during an iteration. The QA input comes before the development work starts, not after it’s done (well, “done”).

All in all, learning about a fresh approach like this gives me hope that as an industry we can come up with better ways to resolve the tensions between development and QA in an Agile context.

My Job Went to the Cloud

In my post Be the Automator I discussed the inevitability of automation in the software profession, and the need to embrace this automation lest you be automated.

I read a thought-provoking post by Forrest Brazeal recently called The Creeping IT Apocalypse that discusses the specter of The Cloud, in particular...

It’s not that these tools have democratized IT or software development, exactly. Rather, they’ve enabled technical work to be done by a vastly smaller absolute number of people.

Companies still need tech-savvy people, of course, just like factories need people on the floor. But instead of five backend developers and three ops people and a DBA to keep the lights on for your line-of-business app, now you maybe need two people total. Those two people make great money, they’re plenty busy, and they have lots of technical challenges to solve. But they’re not managing a database cluster or babysitting a build server or writing giant stored procedures to do some non-differentiated task, like OCR on insurance forms. The cloud provider can do that (and is adding more capabilities all the time).

As Forrest points out, this is not the “my job went to India” type of fear. Instead of someone cheaper doing your job in a foreign country, the job disappears from the human labor force, to be done by a server farm in rural Washington.

I can say in my experiences inside of big enterprise IT organizations, the number of people doing repetitive, mechanistic, tedious jobs—jobs that should not be done by anyone—is staggering.

The economy will take a small dip, or your department will get re-orged, and you will lose that job as an operations engineer on a legacy SaaS product. You’ll look around for a similar job in your area and discover that nobody is hiring people anymore whose skill set is delivering a worse version of what AWS’s engineers can do for a fraction of the cost

Even the big, slow companies that are dragging their feet on cloud adoption will eventually figure this stuff out, because all their competitors are figuring it out. Dark clouds are on the horizon.

Job Ad Red Flags: “Unlimited Vacation”

Nothing makes my spidey sense tingle in a job ad quite like the phrase “unlimited vacation.”


It’s one of those transparently ridiculous perks. Like how free sodas in the office are an amazing perk. Or how long meetings are fun if there’s “free” pizza.

Obviously, the vacation is not unlimited. So why say that it is?

There are certainly companies out there that have the best intentions for their employees. But stating that you have an unlimited vacation policy and leaving it at that is frankly irresponsible.

“I took 3 months off from my job last year because my employer has an unlimited vacation plan!” — No One

The Myth Of The Unlimited Vacation Policy

Again, I don’t believe every company that has such a policy is nefarious, but the end result is the same. As a Hacker News commenter points out:

It's a means of weaponising ambiguity into guilt. Everyone knows it's not unlimited, because you can't take 3 months off. But because there's no boundary, the real limit has to be found by stressfully, riskily probing it.


I think a much better policy is a minimum vacation policy, with unlimited discretionary days on top.

We require a minimum of [high number] vacation days are taken by each employee, and we allow unlimited additional vacation days beyond that.

Now that is a true perk.

Career Philosophy: Stack Chasers vs. Evergreens

One way of pursuing a career in software development is to perennially jump from technology to technology, or you may say, tool to tool. The idea is to keep a close watch on the emerging trends and invest serially in the trends that seem most promising early enough that you can command a nice salary (or contract rate) for the short period of time where the demand is cresting and the supply of developers is lagging.

Not 'Everdeen'

I flirted with this path for a time in my own career, until I realized that it was not sustainable for my temperament. I had to admit to myself that the only way I could sustain a career this way was if I genuinely enjoyed jumping on new tech continually. Because so few trendy tools ever sustain a high demand for more than maybe a couple years, this process must continually repeat, jumping again to yet another trendy tool until its 15 minutes of fame again subsides. I came to terms with the fact that I’m not actually the kind of person who cares about technology for its own sake, instead preferring to focus on solving real business challenges with proven, reliable tools, using software as a means to an end.

I’ll borrow some terminology I witnessed on a Hacker News discussion today, and refer to this career dichotomy as the Stack Chasers vs. the Evergreens. Hopefully it’s clear by now that I have sided with the Evergreen camp.

Eduards Sizovs, whose post started the Hacker News discussion, reminded me of the Lindy effect, which I had never thought about as being career advice, but I like it…
The Lindy effect is a concept that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.
In Eduards’ case, he decided to spend 80% of his learning efforts on evergreen principles of software development and 20% learning a Lindy-approved boring technology: the Spring Framework, a 16-year-old application framework for Java:

The longer a technology is on the market, the safer investment it is.

Don’t rush to learn new technology – it has a high probability of dying.

Time will show which technology is worth investing. Time is your best advisor.

Amen from the Evergreens.

The Enterprise Archaeologist

The Programmer-Archaeologist churns through this maddening nest of ancient languages and hidden/forgotten tools to repair existing programs or to find odd things that can be turned to unanticipated uses.

- Programmer Archaeologists

One of the aspects of working as a developer in an “enterprise” is that you often find yourself knee-deep in ancient piles of software, developed by some long-dead civilization, who left behind only ambiguous scratchings on stone tablets as documentation.

How on earth will I extract this method?

I will say that there’s a certain element of adventure to these things. You’ll discover tantalizing clues that you’ll piece together to divine the intentions behind the creators of these strange, crumbling structures.

And just as “maintenance” programming is some of the most difficult programming I’ve ever had to do, enterprise archaeology has been some of the most interesting.

The past needs you!

Risky Business

I’ve often thought about how to explain the differences between working for small/medium businesses and an “Enterprise”. Well, Ian Miell breaks it down better than I could in his article Why Are Enterprises So Slow?

I would sum it up thusly:

The priority of the Enterprise is risk avoidance. They have a huge, successful business and don't want to screw it up. A startup is the opposite. They have a tiny, fledgling business and must take risks constantly to be successful.

Risky Business

A huge, old company has seen just about every way someone can screw something up, and they’ve written a rule that applies to everyone that intends to prevent it from ever happening again.

It’s very important to the Enterprise that when something goes wrong there’s “One Throat to Choke.” As Ian explains..

From ownership comes responsibility. A lot of the political footwork in an enterprise revolves around trying to not own technologies. Who wants to be responsible for Java usage across a technology function of dozens of thousands of staff, any of whom might be doing crazy stuff? You first, mate.

The ability to always have some specific person within the organization to blame for something leads to the laborious “Change Management” in the Enterprise. As Ian explains..

In order to ensure that changes to systems can be attributed to responsible individuals, there is usually some kind of system that tracks and audits changes. One person will raise a ‘change record’, which will usually involve filling out an enormous form, and then this change must be ‘signed off’ by one or more other person to ensure that changes don’t happen without due oversight.

There’s absolutely nothing wrong with preferring working for an Enterprise over a smaller company…in fact there are many advantages depending on one’s point of view.

Just realize that the Enterprise is above all else risk-averse, and hence, slow.

Read the whole of Ian’s article for more wisdom:

Why Are Enterprises So Slow?

Opportunistic Agile

I recently came across Martin Fowler’s article on “Opportunistic Refactoring”:

If you don't spend time on taking your opportunities to refactor, then the code base gradually degrades and you're faced with slower progress and difficult conversations with sponsors about refactoring iterations.

From the beginning I've always seen refactoring as something you do continuously, as regular and indivisible a part of programming as typing if statements.

This made me think back on all the times I’ve blogged about this spirit of doing things opportunistically in the process of developing software.

From Opportunistic Programming, to the Boy Scout Rule, and If You Can Lean You Can Clean, I see a common thread.

The “just-in-time” spirit of Agile is opportunistic. Doing things when they’re needed, not before, not after. And capitalizing on the bits of value that are in front of you right now.