The Binary Fallacy

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
-Robert Frost, The Road Not Taken

Binary Thinking is the process of thinking of things in terms of two opposites. You can either do A or it's opposite B. But that's it. In Neuro-Linguistic Programming, it's a technique for manipulating someone into making the decision you want by framing the choice as a matter of either the thing you want them to do or the opposite, presented as a harmful choice. In Cognitive Behavioral Therapy it's a pattern to be broken to help people gain more control over their lives. In Software Architecture it's a warning sign.



If stuck between two different ways of designing something, the answer is always door number three.

Why do humans think like this? Why didn't Frost just keep walking straight through the woods and not worry about the roads? Why didn't The Clash stop worrying about staying and going and just Rock the Casbah? I don't really know. I'm not a psychologist. I'm just a software architect who's familiar with Analysis Paralysis. The phenomenon of getting nothing whatsoever done because you're locked up in the decision making process. And after years of trying to figure out how to avoid this, I came to one inescapable conclusion.

When you're in analysis paralysis it's because every path you're considering is wrong

In my opinion, this happens when you realize deep down that you're looking at the problem wrong and considering bad options. You can't decide because you know your options are both bad.

So what do you do? Well, that's the tricky part and adages about in which part of the box to think aren't as helpful as people who use them think they are. If thinking of something new was as easy as the realization that we need something new then Elon Musk wouldn't be quite the icon he's become. The important question is HOW? First, you just need to stop and accept the fact that you need to come up with something different. Your first decisions were wrong and you need to set them aside. Don't go back to them. Then I recommend you look at the great Stoic thinkers. You start by asking "What is this and what is it for?" I often tell developers to answer those two questions for every application, for every class they build, for every database and table they create. And you don't build the thing in question until you can answer those questions.

Then you ask if a thing is needed or just wanted. If it's not something you need, based on the answers to the above questions, then you leave it out. You strip away the irrelevant. Often I find myself locked up because I can't find a clean way of integrating the irrelevant into my design. Once I stop and realize the piece that doesn't fit doesn't need to fit, things get easier.

I've often said that software development is 90% thinking and 10% typing. If you understand how to think clearly, how to organize your thoughts, and how to tell the difference between the necessary and the unnecessary then there's little that can keep you from being a great software developer.

You've Got One Job

"If you choose to not deal with an issue, then you give up your right of control over the issue and it will select the path of least resistance." -Susan Del Gatto, Creating Balance in a World of Stress: Six Key Habits to Avoid in Order to Reduce Stress

Never forget that your only job is to provide a solution to a problem



Stick with any career long enough and you start to develop a set of principles that guide your approach to your job. Call it experience, call it being set in your ways, even call it wisdom if you dare. But we all do it. I've got about twenty of them, which I realized after an NCIS binge when I started writing them down Gibbs' Rules style. Rather than blasting them out all at once, over the next several articles I'm going to talk about each one. There's no particular order, other than the order in which I wrote them down. However, if I had to pick one to be the most important, it's the one I'm starting with.


Even at the beginning of my career, I never really thought of myself as a software developer. Rather, I thought of myself as a problem solver, albeit one who tended to approach solutions with code. But that idea has always stuck with me. Always be solving a problem.

Now, not all problems are created equal. Some are quite big. For instance, Linus Torvalds solved the problem of having to pay money for an operating system. Some seem almost insignificant. Recently I've been working on the problem of "I don't know Python as well as I'd like to". Something of import to almost no one other than myself. But that's the point. It's someone's problem, and it's getting solved.

Of course, what I'm really getting at is why you write software professionally. And while we all basically realize that we need to fulfill requirements, implement stories, or however we get the list of stuff we're supposed to write, it's easy to lose track of the big picture when you're in the weeds of the little picture.

The problem is that we, as software developers, don't just like to develop software. We like to develop cool software. However we define that, but usually as "the last new idea I read". Admit it- you do it, too. Goodness knows I do. We like to learn new things, we like to try new techniques, because we like, no we need to grow. This rule is to remind me not to take that too far. Ultimately, it's not about what I want, it's about what solves the customer's problem. Because if I'm not doing that, I'm wasting everyone's time.

I've also ran into situations where solving the problem didn't have anything to do with new software, custom software, or even software at all. I've on occasion been able to trim large portions out of a project with suggested business process changes. Or by pointing out that the requested software doesn't actually solve their problem, and on occasion might even compound it. A good software developer knows when to not develop software.

The idea of solving a problem is a big one, and one that spans several of the principles on my list. But this one gets its own item because it all boils down to this simple concept. You're not writing software to write software. You're solving a problem.

                                                                 

Move Fast and Break Stuff

“Now what is the message there? The message is that there are no "knowns." There are things we now that we know. There are known unknowns. That is to say there are things that we now know we don't know. But there are also unknown unknowns. There are things we do not know we don't know. So when we do the best we can and we pull all this information together, and we then say well that's basically what we see as the situation, that is really only the known knowns and the known unknowns.” –Donald Rumsfeld

I actually wrote this some time ago, got distracted, and forgot about it until I saw this tweet:

"It's not fail often, fail fast, It's learn often, learn fast" - @agilesensei #fastfeedback

— Melissa Perri (@lissijean) October 20, 2015

Okay, I admit that the title is slightly linkbait-ish in that I don’t exactly take the “Move fast, break stuff” approach. So let me propose a clarification: “Move well and don’t be afraid to break stuff”. Why? Because if you are building any sort of process, be it a software development project, a corporate business plan, or just a sales presentation, there are three critical pieces of information you must deal with. The things you know that you know, the things you know that you don’t know, and the things you don’t know that you don’t know. Failing to properly react to any of these introduces enough risk to sink your effort.

Things you know that you know

This is the easy stuff and any process plan should start here. You’re on solid ground and planning
becomes easy. But the common misstep here is to fail to act on what you know that you know. Your
domain knowledge is almost certainly incomplete, but you have something you can act on. This means you can begin working and solving problems quickly. You can gain measurable success sooner rather than later. And anymore, time wasted is success wasted.

Things you know that you don’t know

These things are also pretty straightforward, but are also a common trap. You know you have more
information to gather and additional analysis to do. But far too often the tendency is to stop here until you know all the things you know you don’t know. (If you need to, read that line again. I’ll wait.) Just like act action begets action, inaction begets inaction. The more you wait, the harder it is to begin. This is what “Move fast” means, but really you need to “Move well”. You know the things you don’t know, so while you’re acting, you take these things into account. You try as hard as you can to intelligently anticipate as much as possible. The idea is to have to redo as little as possible while being at ease with the fact that you will have to redo something. It's the acknowledgement that something is better than nothing. Except when it isn't. It’s a balance, and there are no right approaches here. The best piece of advice that I have is to be willing to draw a line and say “Factum dictum!” And that's really the point of "Move Fast, Break Stuff". If you wait until you have all the answers, you've waited too long.

Things you don’t know that you don’t know

This is the tough one. There’s always something you don’t expect. Something you don’t see coming.  You need to accept that as you proceed and accept the fact that something may very well happen that turns everything upside down. There’s both forseeable and unforseeable change. Understand that if your plan failed to protect you from unforeseeable change, that does not mean your plan failed. But also the whole point of “Move fast and break stuff”. If you continue to move, continue to produce, and refine your plan as you have more information, you will be in a better position to react to the things you don’t know that you don’t know. If you don’t, your best case scenario is that you’re only able to react to the unforeseen when you’re far enough into your process that it requires a major amount of effort to react. Worst case, you never move out of the planning and analysis stage because you delay action to account for the unforeseen.

“Move fast and break stuff” does not mean “Be reckless”. You’re process should not resemble a bull in a china shop. Move well and move with the understanding that projects, like life, can get messy. If you do what you can when you can, you put yourself in a far better position to succeed. And, as Melissa Perry pointed out, the learning has to come with the breaking.

A Tale Of Two Service Providers

This is an tale of two services that I recently had performed on my house. It's merely a generalized recount of things that have happened in my life, and not a commentary on DevOps, collaborating with business partners, or the #NoEstimates movement. --Editor [That's me]

We recently needed a new garage door opener, which wasn't a surprise. We knew it would need replaced since the old one had been less and less functional as time went on. We ordered a new one, selected certain other services, including installation, paid, and an install date was set. A date that did not make it onto the schedule and as a result, was pushed. At the new appointed time, the installer got to work. When he was finished he told me that there were problems with the setup. In resolving that problem, certain modifications had been made. He demoed the garage door, but it was using a cable that he then took with him, leaving the garage door opener non-functional at the end. But helpfully leaving instructions on how I could finish the work myself. The next day, we discovered that other contracted services had not been completed. Of the four support avenues we tried, all apologized for the inconvenience, albeit one only after trying to tell me that there had been no work order in the first place. A resolution date was set. A date that came and went with no resolution. We finally escalated the support call, informing the new people we talked to that we would be filing daily BBB and other consumer protection cases until the issue was fixed to our satisfaction. The dip in their ratings on these services were finally the stick needed to get a resolution that leaves us with a fully functioning garage door. However, it is good to know that the original dollar estimate will remain the same.

Somewhat less recently, we needed a new toilet installed. Our plumber came out and showed us his recommendations after listening to what we wanted. He set a work date and estimated price. When the installation was underway, the plumber pulled me aside and told me that there was something we needed to talk about. It turned out that the reason our toilet was degrading so badly was that our water softener was not working. Limestone buildup was corroding our fixtures. Replacing the toilet was necessary, but would not fix the problem in the long term. He told us that if we wanted to push the decision, it would not cause immediate problems. However, if we did not do this work, we would end up buying another new toilet. And probably faucets as well.

He told us his recommendations for a replacement, based on our water usage and gave us a revised quote. Making sure that we knew that the additional work was not necessary for fixing the immediate problem. He also showed us one other small problem, but told us that it was simple to fix. He quoted us a price for the part, but told us that the nearby hardware store had it for cheaper. Our decision. He also told us that the fix was too simple to bother charging for labor. Given all of that, we decided that it would be less of a disruption to our lives to have the work all done at once. We agreed on the new cost and time frame. The work was completed. The cost, time, and our level of involvement were all higher, but we knew why. And all steps of the decision making process were in our hands, with the plumber explaining the cost and benefit of all of our options.

Thank you for you patience with my tangent from the normal DevOps focus of this blog.

Dear Entrepreneurs

"Regard your soldiers as your children and they will follow you into the deepest valleys; look on them as your own beloved sons, and they will stand by you even unto death." --Sun Tzu

An open letter to entrepreneurs, from someone who has worked for quite a few of you.

Normally, I go through a lot of examples and points and then summarize at the end. This one is important to me, though, so I'll give you the summary now. Up front.

Your company is your baby. Not mine. You're invested, not me. To me, you're a job. Just another employer. Unless you do something to get me invested.

In my experience, a good number of entrepreneurs don't quite get this. I get that your company is your baby. You've worked for it, lost sleep for it, and probably skipped a meal or two for it. To you, this is personal. But it isn't to me. Not right away, and not just because you hired me. If I'm going to be personally invested in your company, in your idea, you need to give both reason and opportunity to do so. And it's worth it. If you're just a job to me, I'll walk away as soon as a better one comes by. If I'm invested, I'll have to be dragged out.

To that end:

Just because you believe, doesn't mean I do.

Most software developers I've encountered fall into one of two categories. First you have the mercenaries contractors. They work for the people who give them the best compensation. And I don't just mean money. Pay, benefits, environment, all goes into it. But as soon as they see a better place, they're a developer-shaped puff of smoke in the air.

Then, there are the developers who want to work for the company they work for. Because they want to be a part of what that company does. Believe me- those are the guys you want. But you have to give them a reason. And that's the bit that, in my experience, many entrepreneurs overlook. They think that the fact that they know how awesome the company is, then any employee should, too. Automatically.

Look- I'm a software developer and I'm familiar with the territory. A lot gets asked of us, and we take a great deal of professional pride in delivering quality work. But there's got to be a better reason than "Because I said so". If I'm working 50-60 hours a week just because "That's policy", then I'm probably going to have my resume out in a couple of months. Definitely before my one year anniversary. If I care, then I'll do what needs to be done, but you have to give me a reason to care. 

I've worked at both extremes of this. One entrepreneur mandated 50 hours a week, minimum, 24/7 support, and made us track our time down to the quarter-hour. For few benefits, and frequent communication that profit sharing and ownership would only come to those who deserved it. Which was, at least at the time, no one. I had taken the job in order to gain a specific skill set. Once I felt I had it, I moved on. I had no investment in the company because the founder hadn't given me a reason to care.

I went to another startup. The CEO gave regular meetings, not just on how the company was doing but why they were doing certain things. He told us quite frequently that his vision was to change a market in order to put more power and more control, and thus more opportunity, in the hands of customers. He ended every meeting with "Welcome to the revolution!" He believed. More importantly, he got others to believe. Nights? Weekends? No problem. Answer questions while on vacation- sure. Why? Because I wanted that company to succeed- still do, even though we've parted ways. And even so, I'm a touch sad about having done so. Because I believed.

Sprint Planning Pt. 1: Stop with the Points Already

"Our culture thrives on black-and-white narratives, clearly defined emotions, easy endings, and so, this thrust into complexity exhausts." --Caroline Knapp

I've been doing a lot of reading and thinking about story points lately, and over time I have been edging toward what I now see as a necessary conclusion. Story points are meaningless. Even... Wait for it... POINTless. Yes, I just did that.

To recap, when planning a development sprint, it's customary to assign a user story a point value as a measure of... Well, to be honest, I really can't tell you what it's measuring. I can recap what people say about what it's measuring, however I've become skeptical of whether or not points are measuring what people think they are. And even moreso of whether or not it's a good use of time to do so.

Definition of a "Point"

Here's the root of my problem with story points. What are they and what do they measure? These aren't simple questions, either. If you read here, you get the idea that points are a measure of complexity. However, this StackExchange answer tells the reader that points need to be a measure of size, not complexity. Both will tell you that points are not a measure of time, but everywhere I've run into the practice, someone has always defined a point something along the lines of "What one developer can do in one day". Which certainly implies that points are used to give some measure of time. So I have a hard time getting started here, because I don't even know what I'm supposed to be measuring. Time? Size? Complexity? The amount of effort it takes for two women to have one baby? 

What's the Point, anyway?

I promise- I'll stop doing that now. Maybe talking through why we need points, we can come to an agreement on what they are. We need them for estimating, right? But estimating what? The amount you can do in a two week sprint? The amount of time you need to finish a certain set of features in a product? After all, you assign points, add them up, and divide by about what your velocity has been, right? Because that works.

Except, of course, it doesn't. Addressing the latter poi ISSUE ::ahem:: first, we all know that doesn't work. Regardless of what some may say, points do not mean you don't need to re-estimate. Software development is a process that builds on itself with every build adding to the whole an impacting the effort/size/complexity/time needed for future changes. I'd be very dubious of the point value of any story not going into the next sprint. I'd be even more dubious of any time estimates derived from arithmetic on points, velocity, and time.

So, maybe it's a good way of determining what can be worked on in the coming sprint. Problem is, without definitive answers to the question "What does a point measure", using points to determine what stories can fit into a sprint is a terribly uncertain process.

If we take the definition of points being a measure of the size of the story, then we truly have no idea how long a story will take. In fact, the StackExchange user in the link I referenced illustrated this very thing. He gave examples of the complexity of a 5-point sized story varying by a number of factors, leading to wildly different completion times. I don't really see that as a practical way to plan a sprint. More importantly, I don't think the people who expect me to plan sprints will see that as a practical way of planning sprints.

If we take the definition of points measuring complexity, we run into a different problem. How do you measure "complexity"? It's not like defining the length of a metre or defining a joule. the only way is to compare the complexity of one thing to the complexity of other things until you get something that feels like a match. Inaccurate, sure. But that's why it's called "estimating" and not "precision". I'd be basically okay with this except for a couple of things:

1. That which is complex to one developer may not be to another. Planning Poker is supposed to account for this, but it doesn't. In fact, it ironically exacerbates the problem it claims to solve. My 5 point complexity story may be another's 2 point complexity. To assign it 5 or 2, then, is meaningless outside the context of the developer who will be working on it. And splitting the difference to make it 3 or 4 is just compounding the uncertainty of an already uncertain process.
2. Complexity has nothing to do with the amount of time it takes to do the task. Planning Poker assumes that every developer handles every type of complexity in the same way and at the same pace. Maybe one guy tackles a complex story by diving in and coding until he grinds to a solution. Maybe another takes time to read more on the subject, asking questions, and only starting when he feels he has a better understanding of the subject. Given this, complexity can only correlate with time if every developer approaches complexity the same way.

Either way you look at it, you're trying to objectively quantify a series of subjective data points. Logic 101 tells us that this is a highly inaccurate way of measuring anything.

Velocity

Finally, we get to Velocity, which I'm pretty sure is the whole reason we bother to keep track of points in the first place. Velocity is nothing more than the sum of the points of the stories in a given sprint. It purports to measure the amount of work done in a sprint so you can compare to other sprints and then plan a timeline for future features.

Where to start.

First off, all this gives you is a comparison of how you've been objectively quantifying the subjective sprint over sprint. But as a comparison of the actual work done? All you're doing is comparing arbitrary numbers to arbitrary numbers and pretending it's a meaningful measure of productivity.

Secondly, using this as a future planning tool is a recipe for disaster. In order to make that work, you'd have to give point estimates to everything in your backlog and then continually refine those estimates in light of what the previous sprints have accomplished. Do that for long enough, and sure. your velocity will become a more and more accurate tool for predicting the amount of work the team can handle. But at what cost? At what time commitment?

Conclusion (WHEW!)

I'm not saying we need to stop estimating anything. Projects, stories, releases, versions, whatever unit of work that is needed, all need to come with some idea of what it takes to accomplish them. What I am saying is that we need to re-think the whole point estimation bit and ask ourselves if this isn't just an overly complicated process. Effort, complexity, productivity- these are all complex issues that are impossible to quantify in a simple context. Maybe we need to stop trying. Because I really hate unnecessary complexity. I'm not even much of a fan of necessary complexity. I'm lazy and don't want to work any harder than I have to in order to solve problems.

Next article, what I see as the real root of the problem and what I have started doing about it.

New Challenges

"Be careful of what you wish for. You might get it".

Hard to say where that comes from, although some cite it as a misquote of Goethe. The image, of course, is from the amazing mind of Bill Watterson and his Calvin and Hobbes comic.

Regardless, that is kind of the source of why I haven't been writing much lately and why I'm starting again. I tend to write about what I'm seeing and experiencing. Which, over the last few years, has become fairly routine. After writing a good bit about my thoughts on Software Architecture, it became the task of taking my own advice.

So what changed? A chance to get what I asked for, namely a chance to go from helping insure quality in a software system to helping insure quality in a development team. The company I work for has a relatively new development team that operates fundamentally differently than our other teams. This team doesn't support a product. Instead, they handle smaller projects that have a more rigid "Definition of Done", as opposed to continued development and support of a product. This has come with more than a few challenges. Challenges that I have a pretty free hand to solve, but challenges that will take a lot of solving.

All this has put me in an interesting opportunity. Processes are getting built from the ground up. We have leave to borrow from other teams the processes we feel are helpful, as well as to ignore the things we feel won't benefit us. The end goal is increasing the rate of shipping quality software, and with very few exceptions I don't think the head of software development much cares how it happens. This gives me the freedom to take my biggest piece of advice to anyone designing software. Or, for that matter, anyone currently living and interacting with the world in any way:

“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.” --Meditations, Marcus Aurelius

In other words, "Question everything". Some ideas are worth leaving alone. Questioning the necessity of engagement between the business and development is a lot like questioning gravity. Feel free, just stay away from ledges. But how do you do these things when the business units aren't used to that engagement and don't understand the value in it. And that's not looking down on anyone- how can you know the value of something until it's been shown to you?

Beyond that, what traditional roles in Agile projects do we need? Which can we live without, and which should we live without? What do these roles mean, and how do we make sure everyone knows what an iceberg is?

What about the team? What common practices do we need? What offers us the best value in our situation. Not just what others are doing or what generally works well, but what works well for us?

These are the questions I'm asking myself and the ideas I'm exploring. I'm sure we'll go down some odd paths, and probably even the (hopefully) occasional bad path. And hopefully, my philosophy that understanding the world leads to understanding software still holds.