Development Central

Bill Sorensen's software development blog

Notes: Agile's Dirty Secret

Notes on a talk by Tim Gifford at Iowa Code Camp.

CelebrityAgilist.com - GitHub community

Agile Manifesto - no processes are listed.
See also the related 12 principles.

SAFe Agile process (new RUP?) - speaker has seen companies turn the PSI's from that into little waterfalls - easy to lose track of what the customer values

Incremental - you don't see the whole picture until everything is done
Iterative - see the picture, but it starts out fuzzy
(Like interleaved graphics downloading)

User Story Maps - read more on this!

Weinberg's Law of Raspberry Jam - the wider you spread it, the thinner it gets (poor understanding)

Testing Boundaries problem
3 code paths with 10 paths each - need 1,000 end-to-end tests
If we get a defect in one code path, 100 tests fail.
Spend all your time fixing broken tests.
10/10/10 unit tests + 200 integration tests + 1 end-to-end = 230 tests
Only 22 or so fail if there's a defect.
(Same combinatorial problem Mark Seemann talks about on Pluralsight.)

Large problems need leadership & courage.

Large Teams
More people => fewer questions => less learning
Interpersonal issues - why not split them up on clique boundaries?
Responsibility is spread out.

Small Feature Teams
Top-to-bottom, delivering customer value.
More opportunities for leadership roles.

He's using Feature Toggles.
He's very much in favor of it, but there's a downside.
You need to make sure you're truly releasing the software, not just delivering with features turned off.

It's important to still have a release plan.

Give pilot teams learning time - an extra point per story, etc.
You don't start out with TDD/BDD/ATDD at full velocity.

You cannot teach craftsmanship. Knowledge does not change behavior.
(There are marriage counselors who are divorced.)

"It's always a people problem" - Weinberg's 2nd Law of Consulting
(Secrets of Consulting is Weinberg's book)

Drowning in Defects
Agile practices can help with new defects - but what about legacy?
Defect age ranged from 2 hours to 2 years on one of his projects.
The variability resulted in angry customers.
What if we do defects in the order in which they were received? FIFO?
What about the old ones? Ignore them - if they're important, they'll be reported again.
Prioritization can be waste.
Capacity needs to align with demand - the business needs to step in if the bug requests are overwhelming the developers (more hires or stop reporting bugs until developers catch up).
Leadership doesn't come from authority. If you see a problem, fix it.
Why do we let defects accumulate?

In order to run fast, you need to run clean.

Don't start coding until you have a Given-When-Then scenario.

That's not TDD

I'm currently reading Pro ASP.NET MVC 4 as part of learning web development. So far it's been a good tutorial, but I take issue with the author's coverage of Test-Driven Development (TDD).

I applaud the coverage of unit testing, dependency injection, mocking, separation of concerns, and other best practices. It's the details that bother me.

In chapter 6, the author says he will follow the TDD approach in a unit test example. He starts out by writing the system under test and having it throw a NotImplementedException. Bzzt. Write the test first. There is a reason for this: the tests guide your design. You write the API you want to consume.

Next, he writes the unit tests. All of them. In TDD, you write one test, see it fail, write code to get it to pass, refactor, and then repeat. While there's no law that unit tests must be written in that fashion, changing the process means you're not doing TDD. If you don't want to do TDD, fine, but don't call it that.

Several of the tests violate the guideline of one logical assert per test. The only justification I can see is brevity. This comes at a cost: when the first assert fails, subsequent asserts are not run. In addition, messages have to be added to the asserts for clarity; it's much better to include this information in the test method name.

// These should be three separate test methods
Assert.AreEqual(5, TenDollarDiscount, "$10 discount is wrong");
Assert.AreEqual(95, HundredDollarDiscount, "$100 discount is wrong");
Assert.AreEqual(45, FiftyDollarDiscount, "$50 discount is wrong");

The author encourages use of the ExpectedExceptionAttribute. This is far too coarse-grained, and is one reason for avoiding MSTest (which the book also promotes).

I encourage everyone to go to the experts to learn TDD and unit testing. Two good sources are Test Driven Development: By Example and The Art of Unit Testing.

The book's coverage of dependency injection is incomplete as well; the authoritative work is Dependency Injection in .NET.

I'm being harsh for a book on ASP.NET MVC. If you're going to cover these topics in detail, though, please get the details right.