A lot of people think Agile is about working faster, but that really isn’t right. It would be more accurate – and perhaps alleviate many of the arguments against agile practices – if we thought of agile as being about working slower because we’re being more deliberate. BUT, at the same time getting rid of all the crap that doesn’t add value, so that we do, indeed, end up delivering more functionality in a shorter period of time.

I like to think of Agile as the Just Do It methodology. In software development, we’re really great at this thing called “yak shaving.” If you’re not familiar with the term then take a moment to read: So There I Am, Shaving a Yak…. Go ahead, I’ll wait. It’s really funny, I promise.

“So there I was at the zoo, shaving a yak, all so I could take a few pictures of my dogs at the park.” – Bill Gaiennie

A really huge part of yak shaving – at least for me – is trying to figure everything out so that I can make sure I’m going about things the right way. Oh boy, I can plan and research and do proof of concepts like nobody’s business. But at the end of the day, I’ve got a bunch of “stuff” with no actual working software for the app I’m supposed to be building.

Agile instead says “You’re never going to know everything about the app until it’s already been written. Cope.” and instead gives us tools to continue to move forward by focusing on what we do know. And then, a funny thing happens. The more of the application that we build, the more we learn. And so, we’re able to move forward, not by focusing our time on what we don’t know, but rather by focusing on what we do know and building actual value out of it.

Read More…..

Bob Martin’s Craftsmanship and Ethics presentation is now freely available. Think of it as a 45 minute video on the key principles of agile programming. Or, if you’d prefer, a tutorial on how to become a professional developer.

As developers, our main product is our code. And, so, to be considered professionals, we must craft our product (code) in a disciplined manner. We should always, for example, check in the code a little cleaner then we found it so that our systems are always improving (as opposed to degrading). However, in this industry, one of our biggest problems is that we almost always check it in worse then we found it. Uncle Bob jokes,

"It’s difficult to call ourselves professionals when our primary outcome is a huge, stinking mess!"

"How many times have you been significantly slowed down by bad code? Martin asks and we can be sure all programmer hands went up. "Then why did you write it?" he asks. There is laughter because of the truth in his question. We have all been slowed by bad code and yet, we continue to allow bad code to be written on our projects. And why? Because we didn’t have time to write it well?

We fool ourselves into thinking we can defer the problems of bad code until later. But the problem is that the slow down is not something that occurs months from now, it’s immediate. "How many of you have stared at code you wrote 2 hours ago and thought, ‘what the hell does that do?!’"

"Bad code is not something that slows someone else down months from now. It slows us down immediately. We must not write bad code. Period. This is a fundamental issue of professional behavior."

And, so, Uncle Bob presents us with a number of principles we can follow if we want to become professionals. In doing so, he offers justification behind many of the agile practices – iterative development, pair programming, TDD, avoiding Big Up Front Designs (only Uncle Bob likes to call them "Turgid, Viscous Architectures"). And, what I think is arguably one of the most important lessons of agile, which is that "the only way to go fast is to go well."

I can’t help but feel my code is getting harder and harder to read as I wade through an ever increasing number of if != null checks before finding my way to the real logic that I actually care about…

God, doesn’t your brain just want to shut down even trying to look at it? I’ve been trying to manage this by creating an endless number of private methods whose sole purpose is to check for values in a null safe way. This at least makes my public methods easier to follow so that I can understand their logic…

Read More…..

Bob Martin’s Clean Code: A Handbook of Agile Software Craftsmanship is finally out and the UPS man just dropped a shiny new copy on my doorstep. It kicks off with these fine words of wisdom:

"The only valid measurement of code quality: WTFs/minute"

Thought I’d take you with me on my quick skim in case your UPS man wasn’t as nice…

Chapter 1 begins with "You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers." Includes sections like The Total Cost of Owning a Mess.

The Functions chapter earns bonus points for its opening image of the hookah-smoking caterpillar from Alice in Wonderland. I’m not quite sure what Uncle Bob is suggesting here, but this chapter includes goodness to the likes of Have no side effects, Prefer exceptions to returning error codes, and classic Uncle Bobness such as:

"Functions should do one thing. They should do it well. They should do it only."

The Formatting chapter explains how to avoid "a scrambled mass of code that looks like it was written by a bevy of drunken sailors" (hmm, I think I’ve seen that code before). And the Objects and Data Structures chapter (which starts with an image of Data from Star Trek – I swear I couldn’t make this stuff up) has some interesting looking sections like Data/object anti-symmetry, The law of Demeter, and Train wrecks.

Read More…..