Net Objectives Thoughts

You cannot meaningfully test that which you do not adequately understand. The time to find that out is before you start development. TDD tells us what we do not know. Sometimes, it tells us what our stakeholders don’t realize they also don’t know. Imagine you are developing the software for a casino’s poker slot machine … Continue reading "TDD Tells Us What is not Known"

A typical question those adopting TDD ask is: How much testing is enough? Or, put another way, does everything really need to be tested? How do you decide what to test and what not to test? It’s an interesting question, but I prefer to address it this way: everything will be tested. The real question … Continue reading "How Much Testing is Enough?"

In TDD, the test suite can serve as a tool for quantitatively analyzing the qualities present (or absent) in the production code. One example: A test will need to access the production entity that it is testing, obviously. However, sometimes a test needs to access another entity or entities as well, even though they are … Continue reading "TDD and Coupling"

First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating … Continue reading "What I Think About Scrum"

Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed. Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of … Continue reading "Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow"

Tests pay you back for your effort: When you are writing them.  They help you to understand the problem you are attempting to solve, they reveal gaps in your knowledge, and lead you to useful questions. When they fail.  They inform you of a defect, and if written well, specifically where that defect is. When … Continue reading "The Multiple Values of Doing TDD"

Creating software has several aspects to it. Deciding what to create How creating new software affects existing software How people work with each other The process being used to build it Although all of this creates a very complex process, only the first three are fairly unpredictable, the fourth is not. We understand flow: Build … Continue reading "Time to Say Goodbye to Empirical Process Control"

Note: This was originally published on the Net Objectives blog on October 6, 2009. In May 2009, there were some discussions on the Kanban Dev group about types of processes. The dialog that resulted is an important part of the Lean thought process. It is helpful to reproduce it here. The discussion on the thread about … Continue reading "Types of Processes (by Don Reinertsen)"

A test reacts to everything currently in scope that it does not control.  Ideally, that should be only one thing. Everything else in scope must be controlled by the test, or it may react to the wrong thing and give misleading results. For example, if a production entity uses a service call as part of … Continue reading "Tests are Reactive: They Pass or They Fail"

Automated tests pass by default. A red test turning green proves everything. The red test proves the validity of the test (that it can fail).  Tests that cannot fail indicates an error in the way they are written. The green test proves the code is accurate to the test. The code is written to pass … Continue reading "A Green Test Alone Proves Nothing"