Mock Free Example, Part 1: Project Intro

Previously, I presented mocks as nuclear weapons. Unsurprisingly, commenters wanted examples. I exist to serve.

This series will discuss a partly-completed project that I have lying around. The project isn’t perfect. But it will serve to discuss some of the ideas. Since it’s only partly complete, some ideas visible in this stage that would likely become much more subtle with another few days’ work. Or so I hope.

It’s also a full project. The ideas blend into each other at the edges. I am not creating an example to demonstrate an idea; I’m showing how those ideas interact with each other in the wild. This will make the examples more difficult to follow. Sorry. I’ll do my level best to guide you to the areas that I find interesting (whether positive, negative, or simply unfinished).

Continue reading “Mock Free Example, Part 1: Project Intro”

How I Learned to Stop Worrying and Love the Mock

I learned something very useful from Marty Nelson’s blog entry on the proficinecy levels of TDD. It was the first time that I saw a construction which included mock objects as a good thing and that also passed my sniff test. So, I hereby recant: Mocks are no more Evil than are nuclear bombs. I’ve learned to love them, as the tools of mass destruction that they are.

Actually, Continue reading “How I Learned to Stop Worrying and Love the Mock”

Architecture That Doesn’t Make Arlo Sad

Layers make Arlo a Sad Panda. They result from, and reinforce, thinking of the product in terms of technical components. They make it hard to vertical-slice the problem.

So what pattern is the architectural correlate for planning and building in vertical slices? Continue reading “Architecture That Doesn’t Make Arlo Sad”

Learning From My Agility Metric

Huh. I generated my Agility Index off the top of my head. Which means that I can read it and learn stuff about myself.

I notice that all but the last two items in the list are maximized by doing something useful in smaller increments.

Also, Continue reading “Learning From My Agility Metric”

An Agility Index (of Goodness)

Someone at work today asked someone else for an Agility index / KPI. The one gave the other a link.

I followed the link. I was underwhelmed.

  • It measured practices, not outcomes.
  • It ignored engineering (the most important practices of all),
  • and learning (the second most important category).
  • It heavily stressed planning (only slightly less important than head cheese to a well-run software organization),
  • and management structure (mostly important in that it can really screw up an otherwise good team).

I figured that I could come up with a metric that’s at least as wrong Continue reading “An Agility Index (of Goodness)”

Agile Team Roles

I was recently asked:

Within the team we have a person working as “development lead”, and a second person working as the “solution architect”.  What responsibilities and deliverable artifacts we should expect from of each of these roles?

As usual, I’d answer “that depends.” Here are some various answers Continue reading “Agile Team Roles”

Developers and Testers

Eric, a smart guy at work, said the following on an internal mailing list (emphasis his):

Developer tests (I avoid “unit tests” because “unit” means 13 different things) are all about proving that code works and will continue to work in the future. … I agree with the others that defining boundaries between people can be counter-productive, though I do think defining boundaries between activities can be useful.

Eric emphasized the right word Continue reading “Developers and Testers”

Quantifying Technical Debt

While talking with people at Agile Roots last year, someone asked me how to measure technical debt. I came up with a metric that, while highly susceptible to gaming, can be really handy for a team to use internally. Continue reading “Quantifying Technical Debt”

Decoupled Design

Recently, I’ve had a large number of discussions around the use of mocks for testing, probably because I keep saying that Mocks are Evil.

As a result, I’ve had to articulate how I design systems. Continue reading “Decoupled Design”