While working on code in the context of a certain task, a programmer often discovers some preexisting quality issue. When this happens, there is a choice to be made:

• Fix the quality issue on the spot, and commit the fix in the context of the task at hand; or:
• Only make changes that are strictly necessary for the task at hand, and introduce a separate task for fixing the quality issue.

Abstract

In this paper I put forth the proposition that contrary to popular belief, 100% code coverage can be a very advantageous thing to have, and I discuss a technique for achieving it without excessive effort.

Biological anthropologists generally agree that humans evolved reasoning to facilitate hunting together as a group; however, there are many other species that hunt in packs, and yet reasoning is unique to humans. Therefore, in order to explain reasoning, it is not enough to consider how it was beneficial to us; we also need to consider what enabled reasoning to emerge specifically in humans as opposed to any other species.

I have a hypothesis which attempts to explain how this happened.

What is the most important quality of software?

Correctness, they say.

And what is the second most important quality of software?

Readability, they say.

That is right, but only in theory.

Abstract

An automated software testing technique is presented which spares us from having to stipulate our expectations in test code, and from having to go fixing test code each time our expectations change.

The term “dependency” is used very often in software engineering, but depending on context, it may mean slightly different things. To avoid confusion, here are the different meanings of the term, and their explanations.