Author: Jim Grey

Writer. Photographer. Leader of geeks.

Categories
Quality Testing

The tester’s three mental models

By Jim Grey (about)

It’s a common mistake among new testers: test it all, every time. But the weight of all that checking soon crushes the tester, and s/he starts looking for ways to test less without missing anything important.

And so begins the journey of understanding risk likelihood and impact: how likely is a thing to be broken, and how bad is it when it is. Smart testers prioritize likelihood and impact, and test in priority order. That way, should time run out, only low risk and low impact areas of the product remain untested. Heck, you might even skip tests that are ranked low enough. Maybe you should skip those tests, as they’re likely to find bugs nobody cares about. A radical thought!

But how to rank risk and impact? This reminds me of an old joke.

Ice cream board
I wish all chalk marks could be about ice cream.

There was an engineer who kept the big machine on the shop floor running faithfully for 30 years. After he retired, the machine promptly broke down. Nobody could get it running again. In desperation, the company called the engineer and implored him to come back and fix it.

The retired engineer returned, albeit reluctantly. He spent a day looking the machine over. Then he called everybody together and marked an X in chalk on a particular component. “Replace this, and the machine will work again.” Glory be, he was right! “Send us an invoice,” the boss said.

And the engineer did: for $10,000. “Ten thousand dollars!” the boss cried. “You need to justify that!” The engineer said he’d send an itemized invoice. Here’s how it read:

One chalk mark: $1

Knowing where to put it: $9,999

Testing for risk and impact means knowing where to put it — that is, knowing where to go to find the most serious bugs. You get good at that by building these three mental models:

Code

What impact on the rest of the software will these code changes have? In other words, what is likely not to work as desired after these code changes are made?

This means you have to learn how is the product is designed and built. That doesn’t mean you necessarily have to be able to read code, although it doesn’t hurt. You just have to pay attention as you test the product and listen to the developers’ explanations of the product’s technical details. You will know you’re building this model when you articulate how you think the product is built to a developer and they say something like, “Yeah. Those aren’t exactly the words I’d use, but they’re accurate enough.”

The code mental model helps you assess risk likelihood. “That part of the product is a little brittle, and every time something interacts with it, things are broken,” or, “I know we designed that function to handle a certain throughput, but what we’re contemplating is 10 times that, and so I’m concerned it’ll fold under the pressure.”

Customer

What parts of the product, when not working as desired, will be a problem for the customer or user? How severe a problem will it be?

To build this model, form good relationships with your support and implementation teams. You might even do rotations through support from time to time, and review customer-reported problems and seek clarity from support on how difficult they were for customers.

The customer mental model helps you assess impact. “If we ship this bug, customers are going to scream,” or, “I think support can talk customers around this bug,” or, “Customers are probably not going to even notice this bug.”

Business

What parts of the product, when not working as desired, put the company’s revenue or reputation at risk, or interrupts smooth and efficient company operations? How severe a problem will it be?

The business mental model gets at how your company makes money and grows the business. This is often the hardest mental model to build, but to the extent you build it, you can make much more nuanced test coverage decisions. To start, you can form an understanding of the kinds of product issues that get customers to call the CEO and threaten to cancel or sue. You can come to understand the kinds of problems that place heavy burden on the support and implementation teams, or would cost the company money in terms of time taken away from revenue-generating activity or services given for free to help regain an angry customer’s trust.

Come to understand which customers, especially the most lucrative ones, are up for renewal soon, and which are unhappy with your company and why.

The business mental model helps you further assess impact. “If this doesn’t perform well, customers are going to quit us,” or, “Bugs in this part of the product always flood us with calls and disrupt our ability to deliver more software.”

Categories
Career

Three things I wish someone had told me when I started my career

By Jim Grey (about)

It’s summer, and the college interns have arrived in software-development shops everywhere. Here’s a story I wrote for my personal blog a couple years ago about some advice I gave a young intern who worked for me.

offtowork1988
Me in 1988, almost 21 years old, leaving for my summer job. (Those were my heavy metal years.)

I felt like a fish out of water when I got my first career job. I’d had jobs before, the kind anybody could do — ushering at a theater, working the counter at a Dairy Queen, driving for a courier service, that sort of thing. But my new job as a technical writer for a software company involved a specialized skill, it created real value for the company, and it had a future. It felt like the big time, the real thing — and it sent my anxiety off the charts. I didn’t know how to behave!

This summer I hired an intern to test my company’s software product. This bright engineering student from Purdue started a couple of weeks ago, and was he ever nervous. He had a hard time looking anybody in the eye and when he spoke, his voice always trailed off. His body language was shouting, “What the heck am I doing here? I have no idea what I’m doing!” So I took him aside and gave him some advice — three key tips I figured out on my own over the years, but that I wish someone had told me back when.

Act like you belong here. Have you seen the film Catch Me If You Can, based on the true story of master forger Frank Abagnale? In it, he forged and faked his way into jobs as an airline pilot, a chief resident pediatrician in a hospital, and as an attorney. He was not trained for these jobs, but he skated by because he behaved confidently, as if he had earned his right to be there just like his colleagues who actually did. Stop short of breaking the law, of course – but anywhere you go, take this one play from Abagnale’s book. And you have an advantage over Abagnale: We know you legitimately have what it takes to do the job. You made the cut, and we want you here. Stand confidently on that.

Know who to call. I turned 22 shortly after starting that first career job and someone threw a small party in the office. When I revealed my age, all the middle-aged guys just shook their heads and wouldn’t say a word. I’ve been through that a few times now that I’m their age — they realized that they had been working longer than I’d been alive. It makes a man feel old. But that age does bring some wisdom, and those guys showed me the ropes. Lots of people helped me get better at what I do over the years, and I still reach out to some of them for advice. Everybody knows you don’t know anything, so relax and ask all the dumb questions you want. Even after you leave here, don’t lose track of the people who were the most helpful. They might stay helpful to you — and it will surprise you one day when you find yourself able to help them.

If nobody is leading, you do it. There is no shortage of people who will simply wait to be told what to do. If you want to distinguish yourself, be someone who figures out what to do and does it. Don’t be afraid to do that when working directly with others, either; it’s startling how often people in a group will stare at each other hoping someone else will take the lead. But be sure to ask what your team’s and your company’s goals are, and make choices that help achieve them. You are bound to make some wrong decisions, but you will learn and grow from them.

The fellow seems to have taken my words to heart; at least he seems a lot less uncomfortable around the office.

What advice do you wish someone had given you at the beginning of your career?

Categories
Quality The Business of Software

It’s remarkable that the “Great Glitch of July 8” doesn’t happen more often

By Jim Grey (about)

It was never a coordinated “cyber-attack,” as several news outlets speculated.

GlitchForbes

It was simple coincidence that several separate systems failed on the same day, last Wednesday, July 8: the trading system at the New York Stock Exchange, many systems at United Airlines, and the Web site of The Wall Street Journal.

Technology fails all the time. You just don’t usually recognize it. Have you ever noticed a page on a site loading unusually slowly? Or have you ever been unceremoniously logged out? I’m sure that as long as the screen finished loading, or that you were able to successfully log right back in, you shrugged it off and moved on. It might have been random Internet gremlins or lousy Wi-Fi. But it could also have been a failure in the service. Perhaps monitoring software noticed it and quietly performed a restart. Or maybe a few minutes of high drama unfolded in some technical operations center somewhere as technicians righted the situation.

But why do such systems fail? Several reasons:

GlitchNBC

Legacy systems patched and updated for so many years that the code has become sclerotic. Big, old companies like United Airlines are bursting with old systems. I wouldn’t be surprised if some part of their reservation system involves a mainframe! Systems like these have been repaired and extended for years upon years, and by now none of the original programmers and technicians still work there. The code has become difficult to restabilize after any change. It’s prohibitively expensive to build a new system from scratch, and even if you could afford it, you’d just introduce a whole host of new problems anyway.

System integrations and data migrations gone wrong. Company A buys Company B. There’s a lot of overlap in the technologies they use, so they integrate them or migrate the data from one to the other. In any such project, a thousand edge cases lurk that, when triggered, can cause failure. Even the most crack project team will miss some. There’s never time and money to find them all anyway. Missed edge cases are just ticking time bombs.

GlitchCNN

Poor original engineering. Because software engineering is still a nascent discipline, we’re still figuring out how best to do it. Every methodology has challenges and limitations. Smart engineers do the best they can to design a system that will work well, but are always limited by time and money. Sometimes revenue pressure leads engineers to favor fast over good. And even then, it’s very hard to imagine all the demands that will be placed on a system over time.

One of my past employers had a Web service that pumped customers’ backend-system data into our database. It was fast and reliable until we sold the product to a customer that wanted to blast in 10 years of historic data. We’d never done that before, nobody checked with the engineers first, and sure enough it made the Web service fall right onto its face. All of our customers experienced an outage.

Good old-fashioned hardware failure. United blamed its July 8 outage on a failed router. Some years ago, squirrels brought down NASDAQ by chewing through some power lines. These things happen, and most companies hedge against it with redundant hardware. But even then, sometimes a failure gets through.

Imperfect failure planning. Almost every company has failure plans in place. Most of them use as much automated failure recovery as they can. But there are just situations that evade even the best plans and the best automation.

Perfect technology is a myth. Occasional failure is certain.

Categories
Career Quality Testing

Endangered species: Managers and Directors of Quality Assurance

By Jim Grey (about)

I lost my job a month ago. The software company where I worked cut expenses to fit revenue. That’s business.

I was Director of Quality Assurance. I built and led a team of functional testers, software engineers (writing code-based tests), and technical writers, and developed the strategies and processes the company used to test and deliver its products. It was a role my whole career had prepared me for, and I was glad to have it.

But now I’m working my network, looking for my next gig. It’s been fun. I’ve spoken to a few dozen CTOs, VPs of Engineering, and even CEOs so far in my search, usually from startups and young companies.

I’ve delivered so much software using waterfall and “scrum-fall” (the developers sprint, and testers try to keep up, but final testing still happens after developers are done) at various well-established companies that I thought that full-on agile was a myth, at least here in Indiana.

Rosie
Endangered.

But the startup leaders tell me they’re all in: it’s agile, continuous integration, and continuous delivery all the way. And while all of them have or will soon need testers, they are all hedging on hiring specialized managers for them.

One CTO, a fellow I worked with several years ago, told a typical story: “I have a few scrum teams, each with one tester. But I can’t imagine ever hiring somebody to run QA as I don’t consider it to be a separate function. Testing is part of the scrum team. I’d have to think QA management jobs will eventually dry up everywhere. I’m sorry; I’m sure that’s not welcome news for you.”

When waterfall ruled the world, it made sense to have a QA department with its own leadership hierarchy. After all, the testers truly were a separate team with their own schedules, methodologies, and needs for care and feeding. But in agile, testers feel fully part of their scrum team rather than part of the team of people who test.

I admit to some anxiety over this evolution, entirely because I’m unexpectedly on the job market after several years of being Manager and Director of QA. But I think these changes are good for quality software delivery.

And these changes are creating opportunity, because there are things a good QA leader knows how to do that a CTO or VP of Engineering probably doesn’t. I networked my way into another startup CTO’s office just to introduce myself and ended up walking out with a short-term consulting job. It turns out that he’s ready to hire his first tester, but wants guidance on how testing should integrate into his team and how the tester should approach the work to find the most important bugs early. So I’m testing alongside his developers for now to get a feel for their context, and will develop a strategy and process his team can follow after I’m gone.

In my conversations, over and over CTOs are telling me they need people to coach and guide on functional testing strategy and technique, or on building test automation and performance testing practices. One VP of Engineering I’ve talked to had an unusual take: that I should be able to help him build and manage his end-to-end software delivery process, including engineering and testing, because he sees process as key to predictable and reliable software quality.

I certainly have experience in all of these areas. I imagine many Managers and Directors of QA do.

I don’t want to count my chickens before they hatch, but I feel pretty good that at least one of these threads will lead to a full-time job soon. And with it, I’ll step out of the waterfall/scrum-fall past and into a present I previously didn’t know existed.

Categories
Career Technical Writing

Software technical writing is a dying career (but here’s what writers can do to stay in the software game)

By Jim Grey (about)

I had lunch recently with a fellow I worked for several years ago. He gave me my last job as a technical writer and my first job as a software tester. He’s currently leading product development at a different software company. “Times have changed,” he said. “I don’t have any technical writers anymore. These days, I want the UX to be good enough that documentation isn’t needed.”

A few days later I had a drink with another former boss. I managed testers and technical writers while I worked for him. Since then, he’s started his own consulting company. “Technical writing is dying off,” he said. “It’s all about clean, engaging UX now. I have talked to more than a hundred startup and small software companies as I’ve built my business. Almost none of them have technical writers, and almost all of them have UX designers.”

Wild
Smart tech writers see the writing on the wall.

It’s clear: companies are leaning into good user-interface design and stepping away from online Help systems and printed/PDF documentation.

It’s a relief. Nobody wants to have to read something to learn how to use a software product. When usage falls right to hand, users are happier and more likely to use the product more. Good UX really can reduce the documentation burden.

My last company had mighty good UI design. One technical writer worked for me, and she kept up with about ten developers. In past companies with lesser UIs, I needed one writer for every four or five developers. It took more words to explain those products’ cumbersome usage.

Admittedly, the latent technical writer in me wants to holler, “Users need instructions for even the best designed products!” Some interactions are incredibly hard to design well enough to forego usage instructions. And users will always need usage reminders for seldom-executed tasks.

But the writing is on the wall. If you’re not finding fewer technical writing job openings yet, you will soon. Fortunately, your skills transfer to other jobs in software development organizations. You will need to build some new skills for many of these jobs, but you might be able to land that first new job without them and build them as you work.

Tester or quality assurance engineer

Testers explore software systems looking for bugs. In some shops, they write and execute detailed test cases; in others, they explore based on high-level test charters. The goal is to report, usually by writing bug reports, on the level of quality the developers have delivered so that decisions can be made about when to ship.

Technical writers routinely find product bugs. At my last company, my lone writer routinely found really important bugs. The VP of Engineering even noticed: “She finds outstanding bugs,” he said. “It must be because she thinks like a user.”

When I shifted into testing 15 years ago, I designed my tests in much the same way I designed online help: by first asking what tasks users would perform in the system. Then I set about making sure those tasks worked. You can do this too. You’ll have plenty more to learn about testing, but this is a great place to start.

Existing skills you will use: Creating and articulating mental models of software systems. Exploring software to discover how it works. A basic understanding of how software is built and delivered. Writing.

But build these skills: Database skills, especially writing queries. Light coding or scripting, to help you automate tests. System administration, to help you better understand and manipulate the environments the software lives in. (Don’t be daunted. I’ve seen many writers surprise themselves when they quickly start to learn these things. It’s as if they soaked up technical abilities by osmosis, just by being around lots of people who have them.)

Product owner, product manager, or business analyst

All of these jobs involve understanding customer needs and translating them into user stories, specifications, or requirements that the developers and testers use to build software. They may involve building a vision for what a product needs to be to meet its market’s needs. These people usually work closely with developers and testers to make sure the vision is realized, and to resolve implementation challenges.

Existing skills you will use: Understanding of customer needs. Creating and articulating mental models of software systems (though, in this case, often systems that have not been built yet). Writing. A basic understanding of how software is built and delivered.

But build these skills: Negotiation, as you might need to manage expectations of customers, the development team, and sometimes even management. Estimation and project management, as you might have to participate in sizing work and projecting delivery dates.

Various UX roles

The UX field includes a number of jobs that, together, create the way the software works and feels for the user. Typical titles include UX Designer, Information Architect, Visual Designer, Interaction Designer, and Content Specialist. These roles involve work such as creating wireframes of screens, designing user workflows, performing usability testing of prototypes, interviewing users and sometimes even shadowing them as they work, writing field labels and error messages, and choosing typography.

This might seem like a real stretch for a technical writer. But my experience is that writers often have innate insight into bad UX: if it’s hard to write about, then it’s hard to use. I find that technical writers can often extemporaneously evaluate product usability and give very useful ideas on how to improve UX.

Existing skills you will use: Interviewing. Understanding of customer needs. Creating and articulating mental models of software systems. Writing.

But build these skills: This depends heavily on the role, but: Design, in general. Graphic design. Usability testing. Prototyping.

These jobs crackle with career growth. But if you’d rather stay true to writing, you can shift into marketing communications, instructional design, or even good old-fashioned business writing (policies and procedures, disaster recovery plans, and the like). My town’s biggest employer is a pharmaceutical manufacturer; lots of software writers here have shifted into validation writing, which is an FDA compliance activity. You might even be able to move into writing technology articles and books; I’ve done a little of that. And some software technical writing jobs will likely always remain in regulated industries, and on government contracts, and for highly technical products.

Nostalgia for my former technical-writing career makes this a sad passage for me. But I think this trend toward effective UX is better for the user, and gives writers good paths for growth.

Categories
Quality Testing

Myths of test automation – debunked!

By Jim Grey (about)

I wrote a post last year criticizing test automation when it’s used to cover for piles of technical debt and poor development practices. But I still think there’s a place for automation in post-development testing. There are two keys to using it well: knowing what it’s good at, and counting the costs. Without those keys it’s easy to fall prey to several myths of test automation. I aim to debunk them here.

Myth: Automation is cheap and easy

It is seductive to think that just by recording your manual tests you can build a comprehensive regression-test suite. But it never seems to really work that way. Every time I’ve used record and playback, the resulting scripts wouldn’t perfectly execute the test, and I’ve had to write custom code to make it work.

St. Paul's Episcopal Church

What I’ve found is that it takes 3 to 10 times longer to automate one test than to execute it manually. And then, especially for automation that exercises the UI, the tests can be brittle: you have to keep modifying scripts to keep them running as the system under test changes.

I’ve done straight record and playback. I’ve created automated modules that can be arranged into specific checks. I’ve led a team that created tests on a keyword-driven framework. And I currently lead a team that writes code that directly exercises a product’s API. The amount of maintenance has decreased with each successive approach.

A side note: given the cost of automating one test, can you see that you want to automate only what you are going to run over and over again, because otherwise the investment doesn’t pay?

Myth: Automation can test anything, and is as good as human testing

Automation is really good at repeating sets of actions, performing calculations, iterating over many data sets, addressing APIs, and doing database reads and writes. I love to automate these things, because humans executing them over and over is a waste of their potential.

This gets at a whole philosophical discussion about what testing is. I think that running predetermined scripts, whether automated or not, is just checking, as in, “Let me check whether clicking Save actually saves the record.” This subset of testing just evaluates the software based on predefined criteria that were determined in the past, presumably based on the state of the software and/or its specification or set of user stories as they were then.

The rest of testing involves human testers experimenting and learning, evaluating the software in its context now. This is critical work if for no other reason than the software and its context (environment, hardware, related software, customer needs, business needs, and so on) changes. An exploring human can find critical problems that no automated test can.

I want human testers to be free to test creatively and deeply. I love automated checks because they take this boring, repetitive work away from humans so they have more time to explore.

Myth: When the automation passes, you can ship!

It’s seductive to think that if testing is automated, that passing automation is some sort of Seal of Approval that takes out all the risk. It’s as if “tested” is a final destination, an assurance that all bets are covered, a promise that nothing will go wrong with the software.

But automation is only as good as its coverage. And if nobody outside your automation team understands what the automation covers, saying “the automation passed” has no fixed meaning.

It’s hard to overcome this myth, but to the extent I have, it’s because as an automation lead and manager I’ve required engineers to write detailed coverage statements into each test. I’ve then aggregated them into broad, brief coverage statements over all of the parts of the software under test. Then I’ve shared that information — sometimes in meetings with PowerPoint decks, always in a central repository that others can access and to which I can link in an email when I inevitably need to explain why passing automation isn’t enough. Keeping this myth at bay takes constant upkeep and frequent reminders.

Myth: Automation is always ready to go

Hope Rescue Mission

“Hey, we want to upgrade to the next version of the database in the sandbox environment. Can you run the automation against that and see what happens?”

My answer: “Let’s assume I can even run the automation in sandbox. If it passes, what do you think you will know about the software?” The answer almost always involves feelings: “Well, I’ll feel like things are basically okay.” See “When the automation passes, you can ship!” above.

Automation is software, full of tradeoffs aimed at meeting a set of implicit and explicit goals. Unless one of those goals was “must be able to run against any environment,” it probably won’t run in sandbox. The automation might count on particular test data existing (or not existing). It might not clean up after itself, leaving lots of data behind, and that might not be welcome in the target environment. It might depend on a particular configuration of the product and its environment that isn’t present.

Even in the environment the automation usually runs in, it might not be ready to go at a moment’s notice. Another goal would need to be, “must be able to run at any time.” There are often setup tasks to perform before the automation can run: a reset of the database the automation uses, or the execution of scripts that seed data that the automation needs.

Myth: Just running the automation is enough

When I run automated tests, part of me secretly hopes they all pass. That’s because when there’s a failure, I have to comb through the automation logs to find what happened, figure out what the automation was doing when it failed, and log into the software myself and try to recreate the problem manually. Sometimes the automation finds just the tip of a bug iceberg and I spend hours exploring to fully understand the problem. Some portion of the time, the failure is a bug in the automation that must be fixed. When it’s a legitimate product bug, then I have to write the bug in the bug tracker.

I am endlessly amused by how often I’ve had to explain that just running the automation isn’t the end of it: that if there are any failures, the automation doesn’t automatically generate bug reports. The standard response is some variation of “What? …ohhhhhh,” as it dawns on them. So far, thankfully, it has always dawned on them.

Myth: Automated tests can make up for years of bad development practices

I’ve just got to restate my point from my older post on this subject. If your development team doesn’t follow good practices such as writing lots of automated unit tests (to achieve about 80% code coverage), code reviews, paired testing, or test-driven development, automation from QA is not going to fix it. You can’t test in quality — you have to build it in.

If you’re sitting on a messy legacy codebase, one where your test team plays whack-a-mole with bugs every time you make changes to it, you are far, far better served investing in the code itself. Refactor, and write piles of automated unit tests.

You want on the order of magnitude of thousands of automated unit tests, hundreds of automated business-rule tests (which hopefully directly exercise an API, rather than exercising a UI, for resiliency and maintainability), and tens of automated checks to make sure the UI is functioning.

I’ll belabor this point: Invest in better code and better development practices first. When you deliver better quality to QA, you’ll keep the cost of testing as low as possible and more easily and reliably deliver better quality to your customers and users.

Categories
Quality The Business of Software

Flickr has smartly repositioned itself to reman vital in photo sharing

By Jim Grey (about)
FlickrCameraRoll
My Flickr camera roll.

When I started my personal blog, which is largely about film photography using vintage cameras, I found a great use for my languishing Flickr account: hosting most of the photos for my blog. Flickr has been a great tool for sharing my photography everywhere on the Internet.

The other day, I uploaded my 10,000th photo to Flickr. That’s a lot of photos! It’s so many that finding one particular photo on my computer is nigh onto impossible. From the beginning, I should have used the photo organizer that came with my copy of Photoshop Elements. But I’ve let too much water pass under the bridge: years and years of photos remain unindexed in folders on my hard drive. It would be a big, unpleasant job to organize them now.

It turns out that the easiest way for me to find one of my photographs is to search for it on Flickr. I’ve left enough bread crumbs in the titles, descriptions, and tags that with a few words in Flickr’s search box I can find anything I’ve uploaded.

It also turns out that I was inadvertently leading the way. Flickr recently made some changes to the site that makes it easier than ever to store all of your photos and find any of them in an instant. I think these smart improvements reposition Flickr well in the new world of photo storage and sharing, and give it a solid chance at remaining relevant and vital.

And it’s not a moment too soon. Flickr had been geared toward people interested in photography who wanted to share and talk about their work. Many users appeared to carefully curate their photostreams, sharing only their best photos. It remained wonderful for this purpose. But in the meantime not only have digital cameras almost entirely supplanted film cameras, but camera phones have also largely supplanted dedicated digital cameras. People were taking pictures on their phones just so they could share them on Facebook and Instagram — and Flickr was getting none of that action. It was falling behind.

Flickr finally awoke from its slumber in 2013 with a new, more modern user interface, plus one terabyte of free storage — upwards of a half million photos — for anyone, for free. Flickr’s mission had shifted: please do dump all of your photos here. And then last month Flickr rolled out yet another new user interface, and has added several powerful new features meant to make the site the only photo storage and sharing site you’ll ever need:

Automatic photo uploading. Flickr can now automatically upload every photo from your computer and your phone — every past photo and every new photo you take. Flickr marks them all as private, so only you can see them, until you choose to make them public. To enable this, you have to download the new Flickr app to your phone and download a new “Uploadr” application for your computer. But after you do, you may never again lose a photograph to a crashed hard drive or to a lost or stolen phone. And if you do have such a mishap, Flickr now lets you download any or all of your photos en masse.

Tags

Image recognition and automatic tagging. Flickr now uses image-recognition technology to guess what’s in each of your photos, and adds descriptive tags to them. You’ve always been able to tag your photos manually; those tags appear with a gray background. Flickr’s automatic tags have a white background. These tags make photos easier to find in search. It’s not perfect — a photo I took of a construction site was mistakenly tagged with “seaside” and “shore.” But it works remarkably well overall, and Flickr promises that they will keep improving the technology.

Camera roll and Magic View. Flickr has introduced an iOS-style camera roll as the main way you interact with your own photos now. Flickr is criticized for stealing this concept from Apple. But they’ve gone Apple one better by adding Magic View, which organizes photos by their tags — including the automatically generated ones. It gives you astonishing views into your photos, grouping them smartly. Finally, all of my bridge photos are in one place, and I didn’t have to lift a finger!

FlickrMagicView
Flickr found 105 photos of bridges in my photostream.

Improved searchability. All these new tags makes Flickr even more searchable. You can find any of your photos in seconds on Flickr.

All of this makes Flickr a compelling place to store all of your photographs, and be able to easily find them. They’re stored on Yahoo! servers and are always backed up. With a couple clicks or taps, you can share them from there to most of the popular social media sites, including Facebook, Instagram (but only on your phone), and Twitter.

The best thing: You can still use Flickr for everything you could before. You can share your best photographs and have conversations about them. You can explore the beautiful photographs others have taken. You can geotag your photos and save them to albums and groups. And if you want nothing to do with Flickr’s new features, you can just ignore them.

I’m astonished by how well Flickr has shifted to its new mission without leaving legacy users behind. As someone who has made software for more than a quarter century, I can tell you: it is enormously difficult to do this.

Still, many of Flickr’s longtime users feel alienated. They’re expressing far less paint-peeling rage than they did after the 2013 changes, thank goodness, but they’re still quite upset. The leading complaint: there’s no way to opt out of automatic tagging, and no way to delete at once all the tags already generated. Longtime users who have carefully chosen their tags find Flickr’s automatic tags to be an unwelcome intrusion.

Flickr should probably address that. But first, they should congratulate themselves. They’ve done journeyman work.

…
A slightly revised version of this is cross-posted today to my personal blog, Down the Road.

Categories
Career

Renewing the network

By Jim Grey (about)

I had lunch with a favorite colleague recently, someone I worked with several years ago and think the world of. She’s among the best at what she does, and is fun and warm and genuine while she does it. I’d work with her again in a heartbeat.

She moved here from elsewhere to take her current job, and finds herself wishing to be better connected in our city’s software industry. So she has been talking to everybody she knows to find out who the movers and shakers are, and try to get introductions to them.

Angel lighting the way
She met angel investors – not this kind.

She ran through the litany of people she has met and wanted to meet, a dozen names or more. We were both astonished that I had worked at some point with all but one of them, most of them as they were on their way up to enormous success. It made me realize I may have let something valuable slip through my fingers.

I told her funny stories about some of these people. One fellow owned a software company where I was a first-level manager. He was a veteran bathroom talker — you’d be standing there draining the tank and he’d come up next to you and start a conversation. And it wasn’t always small talk. You could end up making important business decisions right there at the urinals. Men everywhere know that this breaks the Guy Bathroom Code: no eye contact and absolutely no talking. In, out, move on. But not this CEO.

He sold his company and started a venture capital firm. Through his investments sits on the board of pretty much every growing software company in town. I hadn’t seen him in four or five years when he spotted me in a restaurant last year and came over to say hello. And my colleague said he was hard to meet because he’s so sought after.

I’ve worked with scores of people in my 25-year career, but keep up with just a handful. If I used to work with you and sometimes meet you for lunch, you’re not just a colleague, but a friend.

But lunch with this friend and colleague made me realize that I am very well connected — and I’ve let those connections languish. It’s a shame not only because these people might help me into a better gig someday, but primarily because they’re interesting people who do big things.

When I worked with many of them, there was no way to know that they would do so well. Most people I’ve worked with have not risen so far, actually; most of them are still writing code, or testing, or writing documentation, or leading teams. But so many of them are interesting, too.

But I’m an introvert of working-class roots — a fellow who prefers to keep to himself and let his work speak for itself. At least that’s what I tell myself so I don’t feel so bad about not reaching out to the good people I know. But if I could go back to the beginning of my career and give myself one piece of advice, it would be to not lose contact with the people I enjoyed or admired.

Fortunately, even though a quarter century has slipped by, it’s not too late to start now. I can reach out to people I’ve worked with recently, and rekindle some long-ago connections. I’d like to build a habit of keeping in touch. Maybe I’ll be able to help someone along in their career, or maybe someone will help me along in mine. If not, simply catching up and swapping stories will be ample reward.

Categories
Career

Twenty-five years in the software salt mines

By Jim Grey (about)

Tomorrow it will have been 25 years since I started my career in the software industry.

It might seem odd that I remember the day only until you know that I started work on Monday, July 3, 1989, making my second day a paid holiday. The office was nearly deserted on my first day. My boss regretted not having me start on July 5 so he could have had an extra-long weekend too.

I was 21 years old when I joined that little software company in Terre Haute. I’m 46 now. I have worked more than half my life in and around the software industry.

I taught myself how to write computer programs when I was 15. When I was 16, my math teacher saw some of my programs and praised my work. He encouraged me to pursue software development as a career. He began to tell me about this tough engineering school in Terre Haute.

I graduated from that tough engineering school hoping to find work as a programmer. Jobs were hard to come by that year, so when a software company wanted to hire me as a technical writer I was thrilled just to work. And then it turned out I had a real knack for explaining software to people. I did it for twelve years, including a brief stint in technology publishing and five years managing writers.

I then returned to my technical roots, testing software and managing software testers. I learned to write automated functional and performance tests – code that tests code – and it has taken me places in my career that I could never have imagined.

Office
My office at one of my career stops

I’ve worked for eight companies in 25 years. The longest I’ve stayed anywhere is five years. I left one company in which I was a poor fit after just 14 months. I’ve moved on voluntarily seven times, was laid off once, and was fired and un-fired once (which is quite a story; read it here). Changing jobs this often isn’t unusual in this industry and has given me rich experience I couldn’t have gained by staying with one company all this time.

I’ve worked on software that managed telephone networks, helped media buyers place advertising, helped manufacturers manage their business, run Medicare call centers, helped small banks make more money, enabled very large companies to more effectively market their products, and gave various medical verticals insight so they can improve their operations and their business.

Some of these companies were private and others were public; so far, I’ve liked private companies better. Some of them made lots of money, some of them had good and bad years, and one of them folded. Some of them were well run and others had cheats and liars at the helm. Some were very difficult places to work, but those were crucibles in which I learned the most. Others have brought successes beyond anything I could have hoped for a quarter century ago.

I did, however, hope for a good, long run in this industry, and I got it. But I’m also having a hard time envisioning another 25 years. It’s not just because I’d be 71 then. I really like to work, and – right now at least – I plan to do so for as long as I am able. But I’m starting to have trouble imagining what mountains I might yet climb in this career. Maybe that’s part of reaching middle age – indeed, many of my similarly aged colleagues, some with careers far beyond mine, have gone into other lines of work. I’m still having a lot of fun making software, though. I currently manage six software testers, one test-automation and performance-test developer, and one technical writer. I get to bring all of my experience to bear, and encourage my teams to reach and grow. I don’t want to stop just yet.

…
If this sounds familiar, it’s because it’s an update of an eariler post. Cross-posted to my personal blog, Down the Road.

Categories
Uncategorized

A paean to BASIC

By Jim Grey (about)

It’s the BASIC programming language’s 50th birthday. The first BASIC programs ran at Dartmouth College on May 1, 1964.

Photo: old-computers.com
I cut my teeth on one of these. Photo: old-computers.com

BASIC proliferated in large part thanks to early personal computers, so much so that for a long time to be able to operate a personal computer meant to program it in BASIC. Like so many geeks my age, my first encounter with a personal computer (a Commodore PET) brought me face to face with BASIC. I was drawn in. My dad bought me a Sinclair ZX-81 so I could teach myself the language. I later moved on to a Commodore 64 and an Apple II.

I spent untold hours writing BASIC code. I fell in love with being able to make a computer do the things I wanted it to do. I wrote whatever felt good to me, programming just for the joy of it. I mostly wrote simple games, but I even once wrote a reduced version of BASIC in BASIC just to see if I could do it.

When the geometry teacher got wind that I had written a program that drew any regular polygon on the screen, he asked me to demonstrate it to his classes. He liked my work so much that he suggested that I could study this in college and do it for a living.

“Wait – what?” I thought. “People do this for a living?” It may seem astonishing now that the idea hadn’t occurred to me, but in the early 1980s software development was still an unusual career choice. His encouragement got me to apply to engineering school, where I studied mathematics and computer science, which led to my first job working for a software company. That was 25 years ago and I’m still in the industry.

It was easy to criticize BASIC back then because it was so rudimentary. But all of us who first learned to code using it built upon that knowledge as we explored more powerful languages. I next learned Pascal, and then C++, and later a little Visual Basic. All of those languages featured complexities that were easier for me to scale because I had already mastered standard control structures in little old BASIC.

It’s been a long time since I’ve written any code. I fell into the testing side of software development and I’ve happily made my home there for a long time now. But I’ll forever be grateful for BASIC for being my guide into this world.

More reading: a Time Magazine article about this anniversary (here), and Dartmouth’s celebratory site “BASIC at 50” (here).