When Repeatability Isn’t A Customer Priority

This might be better as a series of Twitter “thinking about…” posts, but since I don’t really “get” Twitter, I’ll jot down this nagging concern here…

I was reading this excellent post on <a href=”http://geekswithblogs.net/coredump/archive/2007/10/19/116178.aspx”” target=”_blank” rel=”noopener noreferrer”>Seven Essential Practices of Software Development [via Steve Pietrek] as I pondered how to convince my client to schedule the time to develop a “heartbeat monitor” and archive that will show the system’s behavior over the past few days. I think that’s necessary because the system is dependent on external service providers and there are assumptions about correctness and scheduling that, if violated, might lead to very expensive mistakes and lots of finger pointing.

Nor do the external service providers whole-heartedly embrace test-driven QA: there’s no set of mocks of my team’s system and mocks of their systems that can serve as a reference for developing new functionality.

While I’m convinced that investment in automation will pay off, the customer priorities are focused on new features. Why should we worry about all this Defense Against the Black Arts stuff when we’re all friends?

In a sense I’m being defeated by the successes of my team, which, having moved to Scrum, have been rolling out new value regularly; now that we’ve established that rhythm, not delivering customer-facing features in the coming sprint is highly visible.