No Testing, No Documentation, No Problem? – InApps 2022

These days, the ideas of “No Testing” and “No Documentation” are seeing a resurgence in the agile-focus development community.

What exactly are these trends? Quite literally, they are software development without testing or documentation. But this is an intentional decision, not in the too-common way that you run out of time and/or budget to do proper testing or to write good documentation.

For proponents, no testing and no documentation is about putting the onus on the development team to create simpler, more flawless code — stop bugs in their tracks. They believe that testing and documentation costs too much money and time, which of course costs more money.

“When I’m a customer, I know I don’t want to pay extra just for a product that works as advertised. By extension, I’d not want to pay for testing. I want a product that ‘just works’.” — Bob Marshall, no-testing, no-docs aficionado.

Sure the software world is constantly striving for faster, better, and at a lower cost, but is a world without documentation and testing even possible? Would it or could it mean better software? Today we discuss what the #NoDocs and #NoTesting movements mean and open up the debate as to if this can or should be a reality.

Where Do Documentation and Testing Fall Short?

There’s no doubt that bugs fall through the cracks and imperfect software is released without proper testing. And certainly sub-par documentation gets published all the time. These two departments are often the recipients of code that’s written and then thrown over that invisible wall. And they don’t often have time to do their jobs correctly as time and budget always seems to run out.

But it doesn’t seem to be the quality of either of these two tasks that has people attempting to eliminate them.

https://twitter.com/flowchainsensei/status/888312455218302976

“Users hate documentation. It’s never well-organized enough, accessible enough, comprehensive enough, context-sensitive enough, to meet their various needs,” NoDocs proponent Bob Marshall recently told InApps. “Nor, really, could it ever be ‘good enough,’ for just that reason. Designers love documentation because it absolves them from the excruciating work of deeply understanding the users’ needs and of designing to those needs. And managers tend to love documentation because it makes it look like they’re doing their jobs.”

Essentially he and other supporters of this movement argue that documentation and testing are cop-outs for not putting enough into code quality from the start.

When asked if documentation ever has a place, like in the application programming interface (API) space, where users say it’s their number-one decision-making factor, Marshall responded that it is “never necessary. Excepting when product designers can’t be bothered, don’t have the time, don’t have the competence, or otherwise avoid serious deliberation about how to make their products intuitive. Then the users might need a crutch.”

Marshall looks at testing and documentation as a “necessary waste” when effort is not put into quality code.

But what qualifies as this near-perfect code? As Developer Relations Manager at Slack Taylor Singletary told us: “You’d have to pretty damn confident that the inherent value and ease of use your software, API, service provides is astoundingly awesome and intuitive enough that developers would look past all that.”

How Can You Develop a Defect-Free Product?

So how can teams prepare for a world without a need for this pair of crutches?

Marshall says: “Consider the user journeys. These journeys include product discovery, exploration, understanding, etcetera. I rarely — almost never — see product designers attend to these kinds of needs, automatically assuming that there’ll be some documentation, user manual or some such provided after the fact.”

We summarize Agile Testing as: Proactively assuring quality throughout the development process. — David A. Koontz July 4, 2017

Marshall did say that there can be copious code examples, just no documentation. He said that no testing is about approaching product quality from a different perspective — defect prevention and what he calls “real” software quality assurance.

“This necessitates developers who can produce effectively defect-free products — at least, an economic and specified, agreed defect density,” Marshall said.

He continued that then people like coaches and quality assurance teams can support developers in this effort toward perfection.

https://twitter.com/Maj_variola/status/888134753425137664

Software Quality Analyst Augusto Evangelisti offers some suggestions for how to create defect-free code, starting by defining a defect as “anything that threatens the value of the product.” He offers this as an alternative to delivering features too fast, which he says creates a “false economy” that requires expensive rework.

Focus on Defect Prevention

But how do you prevent defects? Evangelisti offers these practices, much of which necessitate a culture of communication and collaboration:

• Testing-first software approach like behavior-driven development (BDD) with its shared communication process to collaborate ahead, and acceptance test drive development (ATDD) where the whole team discusses acceptance criteria with examples at the start.
• Rapid feedback loops so defects are discovered — often through testing automation — and removed quickly.
• Tight collaboration between business and delivery teams so real business value is delivered more often.
• Complexity reduction by breaking things down to simple problems with simple solutions.
• Setting coding standards, like limiting the number of lines of code that can be written and setting naming standards.
• Code reviews and pair programming
• Refactoring

“Because your best piece of code is the one you won’t have to write.” — Software Quality Analyst Augusto Evangelisti

Fix Bugs Just in Time

Evangelisti recommends burning all defect management tools, asserting that we spend way too much time categorizing and prioritizing faults instead of just fixing them.

“It is normal for a developer to fix a defect he finds in the code he is writing as soon as he finds it without having to log it, but as soon as the defect is found by a different individual (a tester for example) then apparently we need to start a strict logging process. Why?” Evangelisti wrote.

He says that whoever finds the bug should walk over and talk to the developer responsible for that piece of code. This conversation should decide:

• Fix that bug right now.
• Or forget about it forever.

Of course, in order for this to happen, Evangelisti points out that it should be recently written code or the developer probably won’t even remember why she composed it in the first place.

He concludes that when that bug is found and fixed, a test for the defect should be created so it can be automatically discovered next time.

Where’s the Happy Medium?

Documentation and testing are commonly associated with the older Waterfall project management process. The Waterfall model is a sequential, non-iterative design process that takes a team top-down through ideation, starting, analyzing, designing, building, testing, implementing and documenting. Agile, on the other hand, is filled with iterations and experimentation. Agile, in its natural opposition to Waterfall, is often pegged against Waterfall-like characteristics like documentation.

As Agilist Leanne Howard wrote: “Agile means more talk and less documentation, doesn’t it?”

But of course, this was how she opens an article that goes at length to put No Docs forward as one of agile’s greatest misconceptions. She says being anti-doc is the work of agile novices, who think the speed of agile cannot include documentation.

This doesn’t mean that you need to document or test excessively either.

Martin Fowler, the founder of modern microservices, wrote back in 2005 about code as documentation, “classifying the code as a major, if not the primary documentation of a software system.”

“The rationale for the code being the primary source of documentation is that it is the only one that is sufficiently detailed and precise to act in that role,” Fowler writes. “It’s important that programmers put in the effort to make sure that this code is clear and readable.”

However, he warns that code as documentation doesn’t guarantee any sort of quality in the code nor the documentation. 

If your code is good enough and clear enough, Fowler argues that you could pursue using code as your documentation, but only if it is reviewed. And that refactoring may be needed to make code clearer.

He writes: “Remember that a code base is owned primarily by a team,” and thus when you’re coding — even in our more individualized development world of containers and microservices — you have to code in a way that everyone who interacts with that code will understand.

In the end, we are inclined to agree with part of the #NoDocs and #NoTesting movement: Certainly, developers should be more conscientious in what they are building and particularly in listening to user needs through the entire process. But that doesn’t mean we are jumping on the #NoDocs and #NoTesting bandwagon.

Feature image by Jordy Meow on Unsplash.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Hightower.