Changes

So you want to change your [company, team, world]? Its a daunting task.  You want them to do TDD, ATDD, using the flavor of the week toolset. You want to have business-driven, value-adding features. You want quality to be paramount. But for some reason you can’t get anyone on your team to follow you into the breach. I think we tend to lead people to a specific tool to encapsulate an idea. For example: I want to make better software? TDD! So, I should introduce my team to TDD? This is a backwards approach.

For a team to become a “highly functioning agile team” (a dubious thought in its own right), they first have to sit down and come up with a collective set of values. That everyone believes. If only one of the team members believes a certain thing, leave it off the list. Only come up with a list that everyone agrees on.

I would expect that some things will make the list out of guilt; someone says they love a certain thing and everyone else agrees to it because they feel obligated to. Try to avoid this. The most important part is that everyone MUST BELIEVE the things on the list. It can’t be half-hearted. I have met many a punk that claims to believe a certain set of values, preached and espoused them all the while just doing so because they were trying to fit in, or trying to impress some entity. True belief is the only way this will work long term.

Once you have a list, come up with [agreeable] actions to embody those beliefs. The important concern to keep in mind here is there are many ways to skin a cat. If everyone on the team wants to do pair programming because they all believe in better intra-team communication, great. But that is not the only solution.

These practices can’t be forced on people who do not want them. Make practices that tie back to the teams beliefs; that the team wants to do. If you can come up with a way to make better software without TDD, great! Use it. Don’t pigeonhole yourself to a single practice. Get buy-in. Remember that each of these practices needs to tie directly (and observationally) back to one of core beliefs that team shares. Make it clear how each practice ties back to one or more core team beliefs.

Its hard, but necessary, to take small steps. If you try and go zero to 25,000 mph in one-tenth of a second, you will not get where you wanted to go, and have some gooey floor mats (and no vehicle for that matter). As the team experiences more success and starts to discuss what’s working and what isn’t (which someday you may refer to as retrospectives), the team can add more and more tools and skills to support their core beliefs. After long enough, the team can re-evaluate those beliefs to see if they still apply, or a more explicit vision arises. If you start with nothing and go straight to advanced skills, you will fail and you will receive massive pushback.

PS: TDD is not the same as I wrote some stuff before I wrote some other stuff. TDD takes more skill than people give it credit for. If you try to implement it poorly your result will be useless and the prevailing belief will be that TDD sucks. So be careful...

What the Hell Are You Doing Here?

I suspect that we have all been on projects that were more akin to building a bridge in Hell than that of an IT project. If you haven’t, I congratulate you; Carry on. For the rest of us, I pose a question: How do you deal with the soul sucking reality you live[d] in every day? While you think about that I am going to layout the WRONG way to deal with this...

It is easy to give up, take the lashings, and go about your business. To not try anymore. To live on that job, or project, no longer adding any real value. To accept defeat and recuse yourself to a life of pain and misery in pursuit of the once-mighty dollar. This begs the question: What the Hell are you doing here?

You are now the Problem:

Imagine a new guy comes in, all full of vigor. He is going to make it better, God damn it! And he has to deal with you. You stopped caring, you don’t try anymore. You are now his roadblock; like that guy you used to complain about. Yes, you are THAT guy.

So... Why would they trust you:

When they hired you, the organization expected big things. You had a great attitude, you had a fresh perspective. Now, you are just like every other shmuck they have. Sure, in some way the organization failed you, but now that you are indistinguishable from any other clown doing the job, why would you get a new, exciting project. Why should anyone give you a new opportunity over anyone else?

So... Deal with it:

I heard it put once, you can change your company, or you can change your company. That sums it up. Either fix it or get out. If you have no intention of providing value for your current position, leave. If you want to provide value, do it. Remove roadblocks yourself. What’s the worst they can do? Fire you? Since you were leaving anyway (based on premise one), that really isn’t all that bad.

It is easy to slip into the rut. And every once in awhile we all need reminded of this: You have a choice. You can choose to make it better. It isn’t going to be easy.

Linear and Non-Linear

Just a quick one; to get something off my chest, as it were. Story points confuse me (leaving the issues I have with large numbers being psychologically satisfying out for the moment). We selected to use story points for the sake of estimating complexity (a non-linear scale). In order to represent that we used a fibonacci scale (also non-linear). But because we need to make sure we are doing a meaningful, estimate-able, understandable, and (most importantly) valuable quantity of work, we have also decided to limit the scale in which we use between [1-8] (or so; b/c to high a number means we don't understand...). To sum up the effect of story cards so far: 5 is more than 3+2 in complexity, because complexity is non-linear it should take longer to complete one 5 than a 3 and a 2.

Interestingly, we then use addition to compute the velocity and burn-up/down for an agile team. In effect, we consider that a 3 and a 2 are the same volume of work units as a 5. This seems wrong to me. If one sprint a team completes 3 5s and the next 5 3s, would that not (assuming decent estimates) mean that sprint 1 accomplished more work (ya' know based on the complexity argument). What really happens, I assume, is that a team would really only compete, say 2 5s in one sprint, and 5 3s the next. My fundamental issue is, that an additive scale loses the non-linear complexity (which was the point of using a non-linear complexity value in the first place!). What does this mean? Burn-ups/down based on velocity cannot really be used to estimate release/completion because the charts do not take into account the relative complexity of each piece of work.

This gripe is not that I have a better solution. I have heard of t-shirt sizing, or no points at all to alleviate the short-comings of story points. My gripe comes squarely from a mathematical point-of-view. Treating a non-linear scale in a linear fashion creates an incongruity. 

That is all.

The Technical Debt Continuum

For those practicing agile for any length of time the concept of Technical Debt is not new. Certainly there are varying beliefs on what an acceptable amount of debt there is, ranging from zero (unattainable) to infinite (unsustainable). For the sake of this post, I am going to look at it in economic terms. For example, a single line of code will have some technical debt, or a marginal increase to technical debt. Much like opportunity cost when evaluating an economics scenario, we can consider an opportunity cost for technical debt. Refactoring can reduce technical debt by another marginal value. For clarity, when I use the word marginal I do not mean it as insignificant (as we say marginalized to mean nominal or not important). I do mean it as a delta value current technical debt – previous technical debt yields a marginal value.

Now that the terminology and disclaimer are taken care of, lets get to the white meat. Anyone who has studied (or even seen) econ, will have seen a basic supply and demand curve:

In the case of the above graph, the point at which they intersect is called the equilibrium point. That is the most efficient point in the market because the same amount of goods are being offered as are being consumed, for that price. For the sake of argument, I propose a similar curve for Technical Debt vs. Business Value, detailed below (no these are not exact corollaries, as the concepts do not fit exactly, near (0,0), no griping about that!) :


On this graph, we can see the war between Technical Debt and Business Value. If we allow Technical Debt grow too much the business value decreases. If we allow too little technical debt, no value is being “purchased” in any quantity, or more accurately no product is being delivered; since any line of code is some technical debt, no technical debt means no code, QED no product. Much like in the supply-demand graph, the values are asymptotically zero when at zero cost and zero product delivery. In the case of supply v demand, there is nothing being bought or sold, in the case of my graph, no product is being delivered no lines of code being written. Consider the equilibrium point. Here we have maximized Business Value for: Lines of code written, product delivered; and the cost to the customer. At that point we have also minimized technical debt (again for that amount of code, the product delivered, the cost, etc...).

The key take away from the above graph is: There is no such thing as high business value and zero technical debt. At some point you HAVE to accumulate technical debt in order to provide business value. Of course, on the other hand, you have to be careful to not allow for technical debt to accumulate beyond where business value is provided. As we increase our marginal technical debt, we increase business value, to a point. Interestingly, if we are at equilibrium and we refactor, thus reducing marginal technical debt, we actually DECREASE business value.

I can hear it now: “What you say?”

How do you define business value? Perhaps we could define it in a unique way: Delivery of Stuff Customer Wants divided by Cost to Do So. If you pre-optimize your technical debt, that costs the customer more money, thus reducing value. Sure maintainability is marginally increased, but does not offset the loss in Business Value. Once your technical debt exceeds the equilibrium point, thus business value is decaying, then refactoring or otherwise reducing the marginal technical debt needs to be done to maintain maximum Business Value.

The continuum of technical debt can be viewed as a snowflake. It is pretty and small and causes no threat. It also doesn't individually provide value. But our snow flake hits the top of a mountain and gathers with some friends. After a bit they are rolling together as a snowball. Slowly the snowball rolls down hill, gathering more snowflakes. Since no one has been tending to the snowball, it has now grown to the size of a small person and it continues down the hill. Eventually it reaches the size where it is uprooting pine trees, killing small animals. And now it is completely out of control. OMG. It is heading into town, people are sure to be crushed. Bad things ensue. And all we wanted was a damn snowball. But, you see kids, it grew so big that no one could stop it and catastrophe was born. Don't pre-optimize. But don't let it get out of control.

The Agile Strawman

This might be a bit of a stretch, but stick with me. I don't intend to simplify the world in to two groups, but lets just say there are at least two types of people when it comes to agile and understanding. Group A has read a lot of content on agile, and they like how it feels on the whole. These folks try to implement the agile to the best of their abilities by doing a list of x things. Because, obviously, if we do x things, then we are agile. Group B has a slightly different understanding of agile. They believe it to be a philosophy, an ever changing and improving one at that. Group B questions every concept in order to attain a deeper understanding of agile.

Now we all know what a strawman argument is, right (if not, it is here ; I'll wait; really, no is going to see you click that link, its okay, go ahead). Back? Excellent. Now that we all understand what a strawman argument is, I can go on to describe something that happens all the time in the agile world. Much like anything that has become somewhat evangelized, you end up with two classes: the ins and the outs. Either you believe in agile, or you are a loser who will not be considered for inclusion (in any reindeer games). If you are in, you believe in agile, you then might fall into one of the two groups listed above. People from Group A tend to quote the agile reference of current fad as though it were scripture. When they are not getting what they want they start building the Agile Strawman. They say things like: “I don't believe in technical debt.” Or: “I believe everything should be dry.” Anyone with a shred of dignity would never make an argument like this but, rhetorically speaking, they are incredibly effective. How do I argue against that? If I disagree, do I believe in technical debt, or that duplication anywhere and everywhere is acceptable?

The only effective counter that has come up is the Counter Agile Strawman: “I believe in providing maximum business value to my customer!” And I do. The bottom line of agile and lean processes are: Increase business value, decrease waste. Thats it. Look at the manifesto. It does not list anything about Dry or SOLID design principles. These are tools, processes that CAN (but may not) support agile. Agile is not a noun. You cannot give it to someone. If you do these X things, you are not agile. Agile is a self-improving philosophy, or perhaps a team/organization improving philosophy. It all starts with an individual taking the first step on a journey. The journey's destination is not Agile (since it is not a place), but instead to self-realization. We will never reach omniscience, but along the way you just might get a little bit more agile.

If Perception = Reality QED Delta Reality = Delta Perception

I suppose your first impression of the title might be that I have taken too many math classes (or perhaps that you have taken too many math classes, since you understand it, right?). In many corporate environments we, as professionals and developers, may want to affect some change in the organization. And it always seems like we come up short somewhere. Despite the best effort of the greatest change motivator in the world (if (s)he exists), the corporate culture remains somewhat immune to change. If you ask anyone between the ages of 20-60 I surmise that they would describe corporate america in what would be a roughly similar answer. Suits and processes, rigid and frustrating, politics and puppets. Somehow, despite our collective best tries, Office Space is still a mostly viable example of software development in internal IT organizations.

I suspect this frustrates you as well. One of the reasons that affecting change can be so difficult is the old adage: “Perception is reality.” When we focus on the changing an environment we try and change processes to better fit development. We try and eliminate waste in our own ways. Everyone tries to push their own agenda.

I propose the only way to affect change is to affect perception. Increase the positive perception around the things you'd like to do more of and the things you want to add. And increase the negative perception around the problems in the process, the things that need to go. Although I didn't bother proving that change in perception is exactly the same as change in reality, there is an easy logical step. All we need to do is to make our reality come true is to change our perceptions to the perceptions of those around us. In some case that may mean taking on the perceptions of others, and many other case, asserting our perceptions on the world around us.

The important point is that this goes both ways. We are not perfect, or at least not all of us. Some perceptions I have are good and righteous others are wrong and should be fixed. I need to allow the incorrect perceptions to be affected by others around me, and hopefully do the same for the rest of the world.

Bad Quotes - "I Used to Be a Developer"

Quick tirade...

Every once in a while I will hear these words when someone is trying to argue a point that does not have any data, or any other factual reasoning (or any reasoning at all). The argument that, “I used to be a developer,” is not only annoying, frustrating, and stupid, it also backfires on any dope silly enough to use it. Why? Because I do not suddenly respect you opinion if you are/were/aspiring to be a developer. If you were any good at your job, I hope, you would have used fact based and logical arguments. If I disagree with you, it is not because I believe I have a superior background, it is in fact because I think your idea is disagreeable. It also makes me wonder why you still aren't a developer. Maybe you sucked at it so you got some cushy job telling other devs what to do. Or maybe you couldn't hack it with the problem solving and you should leave that to people who are qualified. Most likely it's because all one has to do to qualify as a “former developer” is once accidentally backed into a position that had anything to do with HTML or VBA, and your company might have been stupid enough to think that those are development positions, and since you were so good at Excel, they thought to themselves, “How much different can it be?” 

See, I am a developer.  I will never cease (greater power willing) to be a developer.  Even if my primary job is not to develop professionally, I will continue to do it in my spare time. Development is not like riding a bike.  If you stop developing that does not stop the world from changing. So if you used to be a developer, you likely have allowed yourself to become and out-of-date tool, like the 286 in my parents basement, you no longer have any relavent use to the development world. 

A pal of mine likened this to a different comment: "I used to be a track coach." What in the world does this have to do with anything.  If I were looking for track advice, since I was NOT a track coach, sure you might have some insights. But if I too am a track coach, you idea of three marathons a day still sounds stupid, even if you were once a coach. Maybe you took a state champion track team and drove them into the ground and that is why you are no longer a track coach.

In any case if you ever feel this comment about to leave your lips, can it. I don't care, and it doesn't lend credence to your utterly inane suggestion. And do your best to keep the debate about things that are relevant to the current conversation, never stop being a developer (it will temper you from irrelevance), oh yeah, and have a point.