I have been thinking a lot lately about how I might go about working with teams to ensure they understand the main message behind agile engineering practices. In many ways, the knee jerk reaction of many managers, including me, is to edict the use of common practices and skills. In my past, I have heard many many reasons for why people don’t want to unit test, setup build automation, peer review code, and refactor. What I haven’t heard is a GOOD reason. This has made it even tougher to refrain from handing down a set of criteria to the teams on “how to code”. After all, for me these practices “just makes sense”.

“What” vs “How”
A lot has been said about internal versus external system quality and I think this concept has helped me teach the difference between “what” systems teams deliver, and “how” those systems are built. When starting a conversation with teams about learning the well tested agile engineering practices, I typically hear a common refrain.

“We are senior developers. We don’t need to improve quality. We’re doing great…just ask the business!”

In one way, they are RIGHT. The business loves what they are seeing. But quality to a user of a system is only skin deep. They see half the equation (arguably the most critical) but half none the less. They see the working system. They see the new feature they requested and by gosh it works exactly as expected! The system is performing as expected. There may be a few lingering issues, but 95% of the system is awesome. It supports the business just fine. Mostly, we just need more features, faster!

Lurking Under the Surface
So what don’t customers see?

• They don’t see the manual jobs we kick off behind the scenes every morning to ensure the data “looks right”.
• They don’t see the delays to building products because only one person knows each individual part of the system, and if they are busy (or even worse on vacation), then nothing in that specific module can be delivered.
• They don’t see the painstaking manual testing efforts that go on before we push to UAT.
• They don’t see the manual roll out, roll back, roll out dance we do simply “moving” code to UAT and PROD.
• They don’t see massive nested If-Statements that look like Japanese word art.
• They don’t see the 12 year old version of J++ that their core processing engine is built with, and that if Christy loses the J++ disk she has in her desk drawer, we’re screwed.
• They don’t see how difficult it is to add simple logic to the system each time they ask for something new.
• They don’t see how often even simple changes strike fear into the hearts of anyone relatively new to the team.
• They don’t see the 18 month ramp up time it takes skilled developers to “learn the system”.
• They don’t realize that “regression testing” really means “test whatever we can for the 2 weeks we have left”. (hint: ~10% of features)
• Etc, etc, on and on, ad infinitum -1.

For the above reasons, we need to be better. As technologists, we need to be stewards of our systems. And in many ways, that means protecting both “external” and “internal” quality.

Stewards? What does that mean?
It means if there are time bombs in our code, we have to make those time bombs REAL to the business and advise them how to prioritize up what is critical and to prioritize away what is not. In technical debt terms, pay down your high interest technical debt quickly by prioritizing it as high up in the backlog as possible. Business people will never do this on their own. We have to help them toward this decision.

It also relates to “how” we build systems. As professionals, we need test automation, build automation, refactoring, pairing, peer reviews, patterns, etc. This is where my brain and my emotions clash. On one hand I want to pass down upon high an EDICT, “Thou shalt unit test!” I would say this is my emotional, impatient side. Intellectually I understand that I need to lead these teams toward these principles. More “supposing” and less “proposing”, as they say. The minute I create the rule, the simple and powerful act of automated unit tests lose their power. People begin to test in haste. They write tests that assert nothing so test coverage reports show arbitrarily high numbers. They write tasks for testing and never get them written. They come up with every reason in the book why testing isn’t that valuable for them, in their system. And when rules are imposed, any shortcomings, difficulties, roadblocks, or otherwise ill will surrounding the approach are attributed to external sources…namely, me. After all, this is Jason’s RULE. He owns it, not us.

Grass Roots
So, I am back to the grass roots. I want to rebrand engineering principles (and the stewardship it implies) as a virtue, not a rule. I am back to the task of building a ground swell in our culture. I am back to focusing my efforts around a few key (and critical) early adopters who have seen the value of software craftsmanship. With these progressive folks, I hope to create a magnetic pull. A “why aren’t we doing that” effect that emanates.

With the rest, I have but one request:

“If you don’t think that these principles and techniques are valuable, so be it. In the absence of using these techniques, please show me how you can assure consistent, sustainable, internal and external quality of the systems in which you have been granted stewardship.”

I am being sincere when I say I am open to being wrong about this. If those principles I have come to lean on are of low value for these teams (and in their context), I am anxious for a better answer. More to come!