Agile Anti-Patterns

http://www.theserverside.com/news/thread.tss?thread_id=49239

Nice reading, especially the comments. Anyway these are more or less “incomplete agile”.

Maybe partial Junit coverage is not agile, but it’s definitely better than no unit tests at all.

Nightly build are worse then continuous integration but are better than weekly builds, etc.

I agree that there is a kind of “click”, aka “when the team jells”, that happens when you’re correctly doing agile. Mmhh, I said one? Maybe there are several, one fore each step of agile you reach.

Not really sure anyhow, my personal experience is that when agile start to work, organizations reacts and dismantle agile teams.

Anyway I want to add other two Agile AntiPatterns I saw myself:

Agile Sweatshop

First signs: 40 hours a week is not a practice but a wish that will never came true. Iterations are fixed both in time and features, there’s no time for pair programming, spikes, crc/mindmap sessions.

Consequences: high turnover, personality problems, quality doesn’t improve much over the time. It’s like a tipical sofware sweatshop but usually managed by some “agile guru” with a bunch of underpaid newbies.

Technical Success

It happens when the Customer change his mind every iteration, and the Team continue to provide new estimates for more or less the same functionalities. At the end the project is cancelled because it’s too late on schedule but it’s still a “technical success”, that is a business failure. The best description I heard of this was at a Jeff Patton seminar at the XpDay2007 in London.

CVDD – Curriculum Vitae Driven Design

I’m in debt to Giovanni Asproni for this new acronim. But the fact behind the term is very well known here.

Let’s start saying that it’s a matter of fact, although a sad one, that a lot of enterprise projects are poor designed.

But, as strange it may seem, in my career I (almost) never saw a simplicistic design, they are all wrong on the over-complicated side.

So why is this happening? If they were all producted by morons, they ought to be equally distributed on both side of the Gaussian. Also I have anectdotical evidence that not everybody in the contractor world is a moron (honestly!).

So, as you may have guessed, the reason behind it is a little more complicated and it has Darwinistic-like reasons.

As contractors’ life goes, you need to keep your resume always updated to the latest hype and keywords in order to be recruited. And simply you don’t have enought spare time to learn everything, so…
a solution appears misteriously in front of you: Put whatever is the current buzzword in your next design document.

Add some new fancy framework or library to your current project, and learn it, test it, experiment with it at your usual tariff.  It’s brilliant and convenient!

I’m not sure to blame only the contractors, it’s a response to the market absurd rules. If customers were looking for developers who know how write simple and elegant code, they would get exactly that.
Instead they usually hire developers with the most buzzwords complete CV. And at the end, they will obtain CVDD applications. Unnecessary complicated, with tons of once-popular frameworks, often misused, etc. etc.

Disclaimer: in case you’re considering to hire me, I would never do anything of this sort! 🙂

To agile or not to agile

I know I’m late, actually I’m always late so there’s nothing new here.

Anyway, some days ago, a post of mine in Milano Jug mailing list, has been quoted by .MOz on his blog.

This is his translation (my actual post was in Italian):
“Blockheads, agile or not, will never produce good code, just as even if you can produce the best software in the world but you don’t understand the domain your project is doomed: technical success is a foolish illusion.”

Maybe “blockheads” and “foolish illusion” are a bit too euphemistic for my tastes, but ok, the meaning is there.

Anyway if you don’t know me, you can think of it as a critique of Agile methods from my part, but it is not. I’m still regarding Agile Methodologies as the fastest and the most cost-effective way to develop software.

It’s only that they’re not a goal per se.

Being fair, probably 99% of Agile practitioners do agree here.

Moreover, methodology is not the Most Important Thing in Software Development, and neither the second one… probably it is the third one MITSD.

It’s like having a race between an old Fiat 500 and a Ferrari Maranello:  if the Ferrari driver doesn’t know which way to turn, or if he doesn’t know how to drive a car… he simply cannot win.

About this blog name…

As a matter of fact I like refactoring, I like it very much. I mean the real one, done in little steps without changing the behavior.

That is, refactor/little behavior change/refactor/another little behavior change etc. in this way you can introduce a big behavior change without much pain. Or at least making your suffering as less as possible. If you don’t know what I’m talking about, you can find it explained here.

So, why choosing “if it ain’t broken don’t fix it” as title?

Because I hate when things that work just fine are broken by people with “Big Vision”TM.

Today I found a blog (from a Kde developer) with a still better suggestion:

don’t code today what you can’t debug tomorrow

Btw the phrase came from Terry Pratchett’s Discworld books, here is another one:

Give a man a fire and he’s warm for the day. But set fire to him and he’s warm for the rest of his life.