Big-Agile Is The New RUP

Some of you who follow Joel, even if only to comment that he's largely irrelevant these days, might have found this coming a bit out of the blue. Why would he make a blog post just to have a partial transcript of one of the StackOverflow podcasts?

And then I found this beauty. Wow.

Turns out the transcript on Joel was specifically because he believed that the Big Agile guys were (intentionally or deliberately) misquoting him. Some really exceptional bits from the article and comments:

Joel said that the SOLID principle aren’t “agile”. (sigh). Everybody and his uncle thinks he knows what the term “agile” means. But I’m the guy who called the meeting where the name “agile” was picked. I’ve been writing about Agile development since the term Agile development was created. I think I know what is Agile and what isn’t. And I think I have the authority to override Joel on this one. Joel, the SOLID principles are agile.

Wow. Appeal to Authority much? Oh, wait, then someone calls him out on it. Here's Uncle Bob's response:

“But I’m the guy who called the meeting where the name “agile” was picked.” Appeal to Authority is a fallacy.

Not in this case, since I am one of the authors.

Wow. It's as though he actually doesn't understand what "Appeal to Authority" actually means. He seems to quite legitimately believe that since he was one of the original people who coined the term "Agile" he can define precisely what that means for the end of time.

Let's look back at my original purity vs. pragmatism post. Now let's look at the comments on Uncle Bob's post. Remind you of anyone?

Agile Is The Anti-RUP
The original motivation of Agile Methodologies was to get away from the RUP and other similar staged-delivery software engineering/delivery methodologies. The RUP is a big, rigid waterfall model that pretty much guarantees that your project is going to be a late failure. Each step is rigorously enforced, and you can't move from one step to the other until you've completed all the requirements. Furthermore, all the outputs are rigorously defined so, for example, you must have UML Class Diagrams (and no other type of diagrams) before you can commence coding.

However, even though anyone these days could look at the RUP and instantly see that it had to be a great big failure, nobody had a Name for what all the effective techniques that weren't in the RUP (or were completely diametrically opposed to the RUP) were. So when people who are extremely respected started saying, "Hey, you can be more successful by ignoring the RUP and doing it this other way" people loved hearing that. People gave these new Agile Methodologies a try, and even bought into the ones that were packaged as a cohesive, brand-name entity (because the only way to compete with a single-named overarching methodology is with another one: RUP vs. BSDM, XP, Scrum).

The best part was that "agile" was just a set of generic techniques that you could pick and choose from and still get some credibility. You could easily define what you do to someone by saying "yeah, we're big on CI and unit testing, do 4 week spikes, and have 2 people sitting on the business desk" and someone would understand what you're doing, and say, "hey, that's pretty agile."

Big-Agile Is The New RUP
Nowadays, that's not true. Let's look at some of the problems I see with the Big-Agile community:

Arguments From Authority. I'm sickened by someone saying "I alone have the right to decide what is Agile and what is not Agile because I am The Authority." No, no you don't.

Argument from Authority only works with factual statements: "I was in the room when Martin Fowler's head exploded, therefore I am an authority on whether Martin Fowler's head exploded in that room." It doesn't work for an argument of opinion.

You definitely get some kudos for being in the Agile world for that long, being a generically smart guy and by really helping the community grow. But that doesn't give you a trump card you can just unzip and slap on the table.

Simple Becoming Rigorous. Let's take a very simple concept: write tests before you write the code. Sounds pretty simple, right? Apparently not. Apparently saying TDD means a whole lot of very particular things that if you don't like TDD, you apparently aren't doing. Go back to the Uncle Bob post. Look at the comments. They're conflating concepts (Uncle Bob conflating TDD with having a rigorous testing policy), and not responding when someone makes the most valid criticism of all:

If TDD and SOLID is too obscure that regular-intelligent people don’t get it, then the problem is with TDD and SOLID, not with the regular-intelligent people.

You see this as well with all the people who essentially say, "If you're not using BDSM/Scrum/XP, you can't be Agile."

You're Doing It Wrong. This is pretty similar to Simple Becoming Rigorous, but the basic concept comes back to all the old, original XP arguments: If XP Doesn't Work, It's Because You Did It Wrong. XP will always work by definition, therefore if it didn't work, you failed to do it correctly. Tautology. But you see this all the time whenever someone says "Yeah, I tried Agile Technique X, and it didn't work very well for me/my team," and the response is "that's because you didn't do it right." It's condescending, and it assumes that all developers are exactly the same, and all projects are exactly the same as the project that you've just been on.

Agile techniques are supposed to be so simple that you can't do them so wrong that they don't benefit you. TDD? As simple as "write tests before code." Standup meetings? As simple as "ensure meetings are short by not allowing people to sit down." How do you get those wrong?

One Right Answer.  You tried a particular little-agile technique that you don't like or that doesn't work for you? Obviously you're wrong. That technique is perfect and must be applied in all cases. It never doesn't apply.

Comment The First: "maintaining a system that wasn’t written with SOLID in mind is the opposite of enjoyable." Really? You can't handle working with any system that wasn't developed with your personal architectural concept in mind? They're all rubbish? Each and every one of them? I don't know what SOLID is except for what Joel said. Honestly, at this point, I don't care. If it will warp me and my systems so much that I will never be able to look without hostility at anybody who doesn't use it, it's a virus, and I choose not to be infected.

Comment The Second: "I have never met anyone that has honestly given it a fair trail (20 days or so) and not become addicted for life." Note the use of the term "honestly" to conjoin this with You're Doing It Wrong.

Here's someone who really seems to get it:

Some zealots are giving ahering strictly to dogmatic methodologies (not necesarily SOLID) a higher priority than delivering software and satisfying customers. If your code is incredibly clean, but doesn’t meet the user’s needs, it is useless. Of course, ideally, principles and methodolgies are used pragmatically in delivering software that does meet customer’s needs but I have seen developers forget the objective of the system they were working while obsessing on the details of the implementation.

At the end of the day, nobody cares how high your code coverage is, or how many interfaces your system has, or what mocking framework you use, or anything else. They only care about one thing: are you consistently delivering software of value?

Agile vs. Big-Agile: Game On
I fully expect the Big-Agile crowd will probably find this completely insulting, and rely on all of the above arguments:

• He hates Scrum because he only has a passing familiarity with it
• He doesn't purely rely on TDD because he honestly hasn't given it a fair trial
• He doesn't like Pair Programming because he never did it correctly
• His experience writing use cases down doesn't count because he didn't use the correct size of note cards and didn't use the correct pen colors

At this point, I don't care. Let me put a stake in the ground.

Big-Agile Zealots Are Killing The Name Of Agile Methodologies

I've interviewed with a lot of firms recently, and I actually have to completely qualify the fact that I believe in little-agile methodologies, because at this point, they see the word "Agile" on a CV, and they think that you're TI from the Purity vs. Pragmatism article. It turns them off, because you guys are viewed as ranting zealots.

And you know what, when I then explain what I find works well in the real world with the types of people I tend to work with, they do the same thing and like it. They like agile methodologies, they don't like Agile Methodologies. They just find the Big-Agile crowd all completely unbearable to listen to at this point.

So with that in mind, unless we can get the "little-a-agile" terminology spread, we're going to have to part company, so that Big-Agile can own the now tainted "Agile" terminology, and those of us who are far more pragmatic can have our own word to play with that you can't try to authority-away our rights to self define.

Ordinary People, Super-Stars, Compensation and XP

(Background: "We Don't Pay You to Work Here" on Venture Hacks).

I'm going to completely disregard every single point in there about incentivising (yes, I just typed that word; you may hereby assume I've lost all cred) employees without money, and urge everybody to leave their cynicism at the door (because ultimately, if you have to be taught to do that stuff, and you have to make a conscious effort, you will fail at it and should resort to just paying people more; a quality working environment is an intrinsic part of culture and can't be bolted on by paying consultants).

I'm with the article, and at least finding it a useful POV, until this:

Practices like Extreme Programming, that were designed for programmers with ordinary skills, work even better with extraordinary programmers.

No. No, no, no, no. No, no, a thousand times no. Stop right there.

Whoever typed that should be aware that their chances of actually employing extraordinary programmers or working with them are approximately 0. Maybe of the group of programmers with which the author has experience, the extraordinary ones of that group work well with XP. Not in the real world.

I do not know a single extraordinary programmer who likes or would even be willing to tolerate XP.

• Pair programming just doesn't work with extraordinary programmers (and extraordinary ones are usually the ones who literally shove the other part of the pair to the side and pretend it's normal programming).
• 40-hour strict workweek just doesn't work, because many extraordinary programmers can't switch off voluntarily, and go through manic high and low phases of productivity.
• The phrase "YAGNI" makes extraordinary programmers violent with rage, because they are always more skilled than the person uttering it, and always know that Yes, You F**king ARE Gonna Need It, Moran! (YYFAGNIM? [Welsh?]) They understand agile, but at the same time they also understand overall lifecycles and how difficult it is to retrofit Lack Of Design Up-Front f**k-ups later on.
• Perhaps most importantly, extraordinary programmers understand anyone selling any type of Silver Bullet is lying or naive.

And remember, XP is based on an irreducable model of software development methodology: it's the Three Stooges Syndrome of Agile Methodologies. Proponents explicitly state that without doing every single part, the whole edifice crumbles. I do not know of a single programmer I would consider extraordinary who doesn't have at least a few problems with XP, and who would voluntarily join an XP project (and everything these guys do is voluntary: fear of unemployment doesn't do anything for them).

Perhaps the author of the article needs to meet some real extraordinary programmers.

Purity vs. Pragmatism

I was being interviewed for a new job last week (yes, I am actively on the market), and had a very interesting, frustrating run-in with one of the interviewers (disclaimer: by mutual acclaim, the role and I decided we weren't right for each other; you'll figure out why shortly) at a large bank.

We Frustrate Each Other
The frustrating part of the interview came when I realized that The Interviewer (we'll abbreviate it to TI, not to be confused with the hip-hop artist T.I.) and I were disagreeing on virtually every point of philosophical substance. But that was just a manifestation of a broader disagreement that I think went to the core of why the two of us must never work together: we fundamentally disagree with the core principle of software engineering.

Let me explain with a few examples of where we differed to try to explain what was going on (no, this is nowhere near an exhaustive list):

• He believed that checked exceptions in Java are always wrong; I believe that sometimes they're useful and sometimes they're not.
• He believed that you should only accept or return interfaces (and never a concrete class) from a module; I believe that you pick and choose between interfaces and POJOs depending on the context.
• He believed that setter-based Dependency Injection is always wrong and that only constructor-based DI should be used; I believe that you pick the right one for the context.
• He believed that you can only ever use DI with a DI container like Spring or PicoContainer; I believe that it's an architectural principle that can applied with or without DI-specific tools.
• He believed that you cannot consider yourself a practitioner of agile methodology without rigidly adopting a Formal Agile Methodology (Scrum, XP, whatever); I believe that the whole point of agile methodologies is that you pick amongst the parts that help your team develop better software faster.

What's the major differentiation here? Purity.

Purity
TI's approach to every major difference between the two of us fell down on the side of rigid, unbending application of a principle in the interests of purity. My approach is far more fluid and contextual.

Purity in any endeavor (art, design, architecture, music, religion, software engineering) is attractive because it strips away all thought and all decisions, and in doing so, pushes a concept to its ultimate expression. I can understand the sentiment. When I moved into my flat, every single surface was either white (floors, walls, ceilings, some doors) or gray metal (stairs, shelves, other doors). It's a minimalist, pure aesthetic, and it removes all distraction and makes it very simple to make decisions: there's nothing subjective about additions.

Sometimes, purity is exactly what you want. It focuses you, and allows you to fully explore one concept to its extreme (how white can you get the walls and floors? can you get them the same white even though you have to use different paints for different surfaces? can you keep the floor white even though people walk on it and put furniture on it?). Even the exploration of pure silence has begat its own groundbreaking work.

Purity in Software Engineering
Taking a purist approach to a software engineering matter allows you to nail your banner on the church for all to see: I believe in X, therefore X is always correct; by applying X to every situation, I prove the superiority of X and validate my initial conclusion that X is superior. This comes up a lot, particularly in architectural discussions:

• Asynchronous Messaging is great! Let's use it for everything!
• An RDBMS is great! Let's use it for everything!
• REST is great! Let's use it for everything!
• Google Protocol Buffers is great! Let's use it for everything!
• Cubes are great! Let's use them for everything!
  
• Lisp is great! Let's use it for everything!
  

The converse also happens:

• XML is crap! Let's banish it from the world!
• RPC is crap! Let's banish it from the world!
• Solaris is crap! Let's banish it from the world!
• RDBMSes are all crap! Let's banish them from the world!
• TCL is crap! Let's banish it from the world!
  
• Lisp is crap! Let's banish it from the world!
  

Purist decisions are easy. They don't require thought. They don't require constant critical evaluation.

And that's why I view them as intellectual cowardice: by limiting your choices intentionally, by limiting the scope of tools at your disposal, by closing your mind off, you reduce the amount of thought you have to put in. But as engineers, as craftsmen, we live by our minds: we are paid to think, and the more we're paid, in general, the more thinking we're expected to do.

TI could replace himself with someone far less experienced by simply writing his own DSL that works on the JVM that doesn't allow you to do any of the things that he thinks are wrong, and forces you to do all the things that he thinks are right. It wouldn't be that hard. Then he can simply hand that off to someone and say "here you are; a language that obeys every one of my edicts perfectly; you are sure to do an excellent job now that I've handcuffed you to my beliefs."

[Aside: if TI's beliefs realy were so universal as to allow him to view me with revulsion for not sharing them, why isn't there already the TI programming language? Are you to tell me that there isn't a programming language which targets some target environment (JVM, CLR, raw x86 machine code) that forces the practices that he likes and forbids the practices that he doesn't? Really? Does that tell you something perhaps? Because it's not like we have an absence of programming languages these days. And it's not like it's that particularly hard to write a language and target one or more existing VM environments, so all the hard work is taken care of already.]

In Defence Of Pragmatism
I'm impure. I'm about as tainted as you can get. And you know what? I think that makes me more effective, rather than less. Because what I get out of a lack of purity is pragmatism. The two can't coexist particularly effectively: I think you fundamentally agree with one or the other.

Pragmatism allows me to look at a problem, carefully consider the advantages and disadvantages to each potential solution, and then determine the right approach to each particular situation.

Pragmatism allows me the flexibility to do things that I know in other circumstances would be wrong, but in that particular one would be right.

Pragmatism allows me to have a bag of tricks rather than one, and pull them out as I see fit.

Pragmatism allows me to gradually refine my beliefs by using both my favored and unfavored approaches in a variety of circumstances so that I have evidence and backup behind me when I express my opinion.

Pragmatism allows me to work with a variety of code written by a variety of people and engage with it constructively as it is, rather than seeking to rewrite it before I'd be willing to touch it.

Pragmatism allows me to decide where to focus development efforts based on what's most important that day: sometimes rushing a feature into production to make more money, sometimes spending time testing the bejebus out of a small change before I make it.

Pragmatism forces me to build software which is easy to maintain and consistent in its internal architecture and clean in its modularization and consummately tested, because that's the only way to maintain a complex system over time. Pragmatism also tells me that if I know the piece of development is only there to run a single time, focusing on all of that is wasted time better spent elsewhere.

Pragmatism allows me to assess the strengths and weaknesses of my team, and the constraints of my customers, before assessing the correct development practices that will result in that unique group of people producing the best software possible with the fewest resources in the shortest possible time. Pragmatism forces me to understand that no one methodology could possibly work for all engineers, all customers, and all projects.

Pragmatism allows me to focus on one and one thing only: getting the job done well. Do what it takes, but get it done, and make sure it works properly. And that's precisely what we're here to do as software engineers: engineer software. And engineering, unlike art, design, music, or any purely creative endeavor, requires getting something done that works. We're not in this business to craft a purist expression of an idea. We're here to build things that work.

The irony is that many purists get that way out of a misguided belief that they're being pragmatic: buy choosing a single technology or technique or methodology, they've chosen the One True Solution and don't have to consider the same decision with over and over. Furthermore, they've made sure that those people working for/with them (particularly the lesser skilled ones) don't do The Wrong Thing. But that means that they've closed their minds off to the chance that they've chosen incorrectly. Or, even more appropriately, that there is no one right decision.

That's why purity and pragmatism can't coexist: purity requires that you ignore the results in favor of an ideological ideal; pragmatism is all about pursuing results for their own sake.

And that's why I think TI and I couldn't work together: I'm a pragmatist and he's a purist. The two of us were bound to clash, and at least we discovered it quickly.

But in the end, I know my approach is right. I'm proud to be a pragmatist.

Except when it comes to TCL. Man, I wish I could banish it from the world.....