Manage Learn to apply best practices and optimize your operations.

The software experience report: Record what you learn

Each software project provides an opportunity for learning. By documenting our experience in an experience report, we are able to reflect and share what we learned. In this tip from frequent SSQ contributor Chris McMahon, you'll learn the benefits from diversifying the projects you work on and recording your experiences to share with others.

As software professionals in a community of software professionals, the most important thing we have to share is our experience. Software is such a diverse industry, there are so many different ways to make software, and there are so many different ways to use software, that what seems utterly routine to one person may be a revelation to someone else. For learning about software and for teaching about software, there is no better vehicle than the experience report.

Software testers are in a unique position in this regard. Unlike every other role on a software team, the most important artifact that testers generate is a species of experience report: the defect report. Great defect reports contain only what the tester has actually seen and experienced. Good testers have a reporter's instinct for factual stories.

The trick is to get a lot of good stories. Good stories come from new and unusual experiences. There are a number of ways to pursue such experiences.

Changing jobs frequently is one way to achieve a diverse range of experience. While it is difficult to face a completely new situation every so often, doing this can be rewarding in terms of gaining wide experience. Another possibility is to change teams or to change roles frequently within a single company. Many companies encourage and reward such actions. Another possibility is to spend some time as a consultant, working on a variety of different project for different clients over time.

In my fifteen years in the software industry, I have had nine different jobs, all but one lasting two years or less. I have worked with mainframe systems, telephony networks, stock market software, networked security video, large-scale email marketing software, social networking applications, human resources software, and a courseware application. I spent a year working for Thoughtworks, the well-known agile consultancy. Each of these has provided unique experiences, some wonderful, some terrible, but interesting things have happened in every job I have ever had.

Nurture a sense of curiosity. Learn to use a debugger in order to watch code work. Learn how networks work to see how data gets moved around by software. Learn a few programming languages at least well enough to be able to create something useful. Learn how operating systems work. Learn databases and file systems. Being curious about such things leads to new understanding and new experience.

In my very first software job I learned to use a debugger well, not realizing how unusual that was. Not long after that I taught myself to write a little code in Perl and Ruby, which led to working on Watir and Selenium in the very early history of those projects. I even ended up as a character in a book by Brian Marick because the first article I ever wrote turned out to be a really excellent experience report about needing to handle a large number of files with a script. At one point I needed to learn how to network-boot some hardware, and because of that, ended up sending GCC debug files simultaneously to a senior developer at Apple, an instructor at the University of Utah and another developer who was working with Linus Torvalds at the time. Because of that work, it is now possible to network-boot both FreeBSD and Linux with the same bit of code. Good things happen when you get deeply curious about how software works.

No software process is perfect. In any company, for any role on a software team, there is almost certainly some change to be made that will make things better. Perhaps the code could be reviewed better, or the build system could be improved, or the test data or the test environment better managed. Inventing new ways to do things in the service of improving one's own software development experience is a great source of experience reports.

Once I worked with a third-party system whose test interface was almost always broken. Much to the surprise of the developers on the team, I wrote a little emulator for that system in Perl, and saved hundreds of hours of development time. Once I worked on a system where we could only do three smoke tests per week. I changed things so that we could do six smoke tests per day. That had surprising results, and that story ended up in a couple of articles of mine. Once I learned to use an unusual automated testing tool. I was on the phone to their customer support line almost daily. They became so interested in my work that their CEO and the head of Customer Support got on an airplane to come and see the system I was building.

Everyone fails sometimes. Failure is by its nature interesting. One sets out to achieve something, but something else happens instead. What actually happened is almost always an excellent story.

As a tester, I have worked on many teams who have released terrible bugs to production. I have stories about race conditions not found, memory leaks undiscovered, system rollbacks, unmaintainable code, vicious backstabbing clients, horrible management, financial meltdown, bait-and-switch tactics, and process breakdowns. It is always awful when it happens, but those are some of the best stories we can tell, because we all learn from experience like this.

Teach experience
There is a saying that experience is the best teacher. But having learned, it is far better to share that learning than to keep it secret. Bring on the experience reports.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.