Writing the BDDs... Good Lord, NO!

Listen, you know how it is if you go out to eat and your friend has a big ole chive stuck to a front tooth and you are thinking that you don't want to embarrass your friend by pointing it out, but you also don't want him to walk around looking goofy and let people poke fun at him behind his back? You have a decision to make.

Because I love you and I care about your reputation and your perception in the world I have to tell you something. You sound like a hick. Not a southerner or a mountain person, a hick from some software jerkwater. It's when you say you are "writing the BDDs."

You are not writing the BDDs. BDD is a process. It's not the kind of noun that takes a plural... well, here let me illustrate:

Imagine I told you I was going to "code my programmings?"

How about "I locked my keys in my driving?"

Or possibly "I got a stain on my wearings!"

How bout this one, "Waiter, will my cooking be ready soon?"

Seem odd?

BDD is Behavior-Driven Development. It's a process, not a physical thing.

There is only one of them, that I know of. If there was another, it would probably have a differentiating name. It's a process you use to produce specifications.

If you use a gherkin-like language, you probably save the specifications in .feature files.

You can write specs.
You can write .feature files.

You write each of them, ideally, shortly before you write the code that will make the specification pass (when run as a test).  Writing the behavior-based test is a collaborative, exploratory-thinking exercise. It precedes coding. Heck, it generally precedes scheduling code to be written. BDD describes the collaboration and conversation and the process, the files are calls "specs" or "specifications" or "feature files."

BDD is to spec file as factory is to car.  You're not out driving your factories, you drive a car.

The specs (or feature files) are the residue from having done BDD.

In some cases, feature files are written without any BDD being done at all. You might write the code, and then write some specs (feature files) afterward to use as integration tests or system tests. You might even feel free to call them "gherkin tests" or "integration tests" or even "story tests" -- I'm not here to judge you.

But you are not writing the BDDs.

When you say you are going to "write the BDDs" you are using the words entirely wrong, and with a very puzzling plural.

You're going to sound goofy around anyone who actually uses BDD as a process.

You are not going to sound like a Behavior-Driven Development professional. You will sound like you picked up the acronym from a blog post and don't know how to use it.

I don't want that for you.

I suggest that you "talk the talkings right so your soundings aren't strange" by dropping "BDDs" from your vocabulary.

Nobody wants to sound like a software hick.

Not that there's anything wrong with real hicks. Some of my best friends are hicks. I used to be a minor-league hick myself. I'm not judging you, here.

This is NOT the End.

This is not the last sprint. There will be more after this. You don't have to have everything this week, and it's more important to deliver than to have every possible feature crammed in. Also, there isn't a good reason to not retrospect or plan if we're going to keep working.

This is not the last test.  There are cases not covered yet, and the solution isn't complete. That's fine. We can write another test and then add the code to cover it. Working incrementally means we often have work in some in-between stage. Let's just get this test working, and then write the next. Programming, says Michael Feathers, is the art of doing just one thing at a time.

This is not the last change. We could try to cram it in like it is an unexpected interruption and a special occasion, but it's not. Changes continue until the last user deletes the last version of the software from the last machine where it is installed. Probably better that we make changes like this easier to implement and easier to fit into the schedule.

This is not the final refactoring. As much as we'd like to pretend that the code can be finished once and for all, it's just not true. This is not the last change, and not the last sprint, so the design will have to continue to evolve. If one refactoring makes it temporarily worse, that's okay. Sometimes it's like cleaning the garage in that you have to make it a bigger mess before you can get it cleaned up. So, code goes through stages and steps and evolution. It's okay.

This is not the last project we'll do. This is not the time to stop learning. There are plenty more where this came from. Even if some aspects of this project are awful, it won't last as long as you and I do. Even if it is great, there are still things to learn. We can't act as if all of the future depends on this one, because it doesn't.

You are not the last person who can take on work. You have competent colleagues, all competent to various degrees and in different areas, but there is a lot of overlap. You don't have to always say yes, or promise that you will personally do all the work. You can share work assignments, and you can defer to others. Take care of each other and yourself.

This isn't the only day.  Tomorrow will have new work, and new problems, and priorities. We don't have to have everything perfected and perfectly buttoned up today. We can lean from today and pay it forward as long as there is still a tomorrow. There has always been a tomorrow for almost everybody almost everyday. Forgive what it is, but use some of it to make tomorrow great.

This isn't the only job. As much as we might want this gig to go on forever, odds are it won't. After 36 years I've outlived so many companies I worked for, but the people there are now in other jobs and so am I. The people and the skills you are blessed with and develop are so important. Your longevity in this field depends entirely on the number of people who want to work with you. Be kind. Be helpful.

This isn't the only thing we'll have to learn. The need to learn is relentlessly ongoing. We might as well get used to the idea and embrace the dreadful constancy of it, so that it becomes instead a kind of never ending adventure. We need to love learning, and keep learning, and keep shoveling out room for our curiosity. We can afford to have the next big lesson come only to find us unreceptive. Open up, it's okay.

The whole world is still incredibly incomplete and moving. This is not the end.

The Company: Can we talk about it?

We talk a lot about changing cultures. There's a lot of inspirational, humanistic content in agile conferences and forums and books and blogs. We tell our success tales in front of rooms of people in both corporate gigs and public conferences, and even as some are applauding, we see people crossing arms and lowering their gaze and some even blushing or flushing.

Inspirational stories are great, but not everyone is getting inspired. Some are getting frustrated, depressed, or even offended. The stories don't ring true to everyone, these storytellers seem to see the world through rose-colored glasses.

There is an elephant in this room.

In most software organizations the overt goal is to produce and release valuable code to customers, as early and often as possible. However, if you ignore what you hear and look at what people actually do, the organization is not fully focused on delivering valuable code.

In fact, many of the things they do seem to be focused on preventing the release of code. In The Systems Bible John Gall noted "systems oppose their own best function."

The real primary goal in most organizations?  To preserve and enhance your position within the organization.

I know that it is not very politically wise to talk about this, but can we?  After all, most software organizations can tolerate defects, late releases, and even product failures. But you can get fired for asking the wrong questions or criticizing key policies, or overstepping your authority or even as a result of someone else's play to acquire the influence that you currently enjoy.

Nobody wants to get fired. Most of us can survive it, and might even land a more lucrative job elsewhere (provided we don't get that dreaded negative reference) but it's a given that we want to keep our job and maybe only leave it through promotion.

Not everyone wants promotion, but everyone wants to gather more respect, autonomy, and compensation. To do that, we have to preserve our place in the hierarchy, and improve it if we can.

It's not really a negative thing, but if we try to ignore it then we can't take advantage of it.

I suspect it can become a positive force in our world. For instance, at Industrial Logic we have been creating an organizational directive to call out hazards and risks so that we can resolve them.

To be a good Anzeneer is to call out latent conditions that harbor risks and hazards to our members and customers.  Our place in the world now is to create more safety. The culture is open to questioning habits and policies and choices.

Maybe your covert primary goal can become overt, and actually work in everyone's favor at your company.

Can you talk about it?