2013: A Year of Software Development and Testing in Quotes

In this roundup of noteworthy quotes from industry experts interviewed in 2013, read about what constitutes effective agile methods, the year in testing techniques, and why you shouldn't put too much trust in the latest and greatest tools.

“I think that they (CIOs) really need to be executives and start with a business function, and then everything has to be driven toward it. I think the CIO is certainly a position for the future, but there is also a new job title that's beginning to emerge, which is the chief digital officer who is basically pulling everything, from the website to social media to videos, to basically anything you would think of as digital media; this is, to a large extent, an awful lot of the dynamic business function of the company.”

—Eric Bloom on the evolving role of the CIO.

“What I’ve found is that when product owners don’t do a good job of figuring out how to measure the specific risks inherent in their initial strategy, their decisions become subjective and arbitrary. Agile methods can make change cheap, but they don’t ensure smart decisions.”

—Arlen Bankston on the importance of accounting for risks during a project.

“If your product owner, developer, and tester are all the same person, you might not need anything like ATDD. If there is little room for ambiguity in the requirements - say you are attempting a system rewrite, and you can know correct behavior because it matches the old behavior—then you might not need ATDD. If nobody really knows what they need until someone takes a crack and fails, then I'll probably try for some rapid prototyping method, or 'tracer bullet' approach over ATDD.“

—Matt Heusser on what areas Acceptance Test Driven Development (ATDD) may not be as effective a practice.

"I don’t think it’s unique to testing, but to me it seems that in recent years there’s been a lot of focus on tools, whereas automated testing is becoming more and more commonly used. But just like with everything else, tools won’t give you good results unless you know how, when, and why to apply them. If you go out and you buy the most expensive frying pan on the market it’s still not going to make you a good chef."

—Christin Wiedemann on why using tools doesn’t guarantee good testing.

"What I honestly think is that being in social media is like meeting friends at the pub at the end of the day. You're talking in front of a glass of beer instead of in a formal engagement with your customer. You're not sitting in a meeting. You're not in a meeting room with a fixed agenda saying we will discuss this and that. You're engaging with them in a discussion that sometimes takes its own flow. People are much more comfortable and that's very important for requirements from the aspect of an agile development, requirements development, requirement solicitation, harvesting to give the people the ability to tell you exactly what they think."

—Stefano Rizzo on the importance of social media for a development shop.

"It’s ever-expanding, so you have to view software development, in particular, as a store full of toys. They keep adding new toys every single day, and at first you’re like, ‘Wow, I want to play with them all! I want to play with that and that and that!’ And then you kind of despair because you don’t have enough time to play with it all. You pick a couple of favorites, you chuck some out, some you keep forever, you trade toys with friends, but there’s always going to be a change. You can’t expect to go just through a tube from one end to another and then, 'Ta-da! I am a developer now!'"

—Iris Classon on keeping up with the changing nature of software development.

"Many currents can impede continuous improvement but I think the biggest one is having too tactical a mindset. Heroics and fire-fighting are sometimes necessary in short bursts, but we need to think about longer term effects of the decisions and trade-offs we make when we do that. Under duress, organizations simply can't mature. It's everyone's job to help the salmon. Did you know in the "salmon run" there is a scientific term called magnetoception? It is the instinct that all salmon have in order to return to their natal origins, literally the exact same place they were born. What I'm saying is that the whole team swims together. It's not just one person's job."

—Colleen Kirtland on impediments to continuous improvements using the metaphor of salmon moving upstream.

"Also common is the test automation group zombie. This zombie is the practice of assigning test automation to a dedicated team of test automators. The appeal is that we can keep developers focused on writing new code instead of writing and maintaining automated tests. The danger is that test automation inevitably lags development, so feedback from testing is delayed in a way that significantly reduces its value. A further danger is that we often assign test automation to less-skilled programmers, which results in brittle tests that are costly to maintain."

—Dale Emery on one example of a test automation “zombie.”

"When your development team is nimble, quick, and ready to start coding, they don't have time to wait for your research results, so we can't afford to be slow in UX, either. The way to achieve quick results is to be very focused on what you want to find out. Once you have a solid hypothesis for a product persona, you find two or three people that match the profile and interview each one for an hour or so about their daily tasks, their skills, background, and what's important to them. These interviews validate that the persona you envision actually does the tasks you think they do and you're not completely off. Plus, you'll learn a lot more about the users than you may expect."

—Nellie LeMonier on performing persona research with speed and efficiency.

"The key distinction I would make between “quality debt” and “technical debt” is that where technical debt usually focuses on the cost and impact on development and future development cycles (and there are many sub-categories of technical debt,) quality debt focuses on the impact of implementation and quality decisions on the end user and business; how those decisions affect their ability to do their day-to day-job."

—Jordan Setters on the difference between “quality debt” and “technical debt.”

"The tip I would give those that are working to scale an environment that can foster high-performing teams is to assemble a group that models the framework petals. Each petal is really a perspective into the complex system so when a change is being planned all the perspectives can be weighed to craft the change."

—Michael DePaoli on hyper-productivity and teams in the enterprise.

"Input validation. Many, many types of attacks leverage the fact that developers do not do an effective job of validating the integrity of the inputs their programs/interfaces accept. Too often input buffers can be overflowed, executable commands can be sent to a database, or inadequate authentication mechanisms are used to assure the person logging in is legitimate. Just cleaning up our inputs can go a long way toward making software more secure. These types of security issues are also ones that testers can understand and test for without understanding the details of the code."

—Jeffrey Payne on security areas that testers may overlook.