Didn't You Get the Memo?
“If it was up to me I would love to be able to craft code a bit more carefully.”
Hearing that statement stopped me dead in my tracks. Here we go again.
My history is somewhat similar to what Martin Fowler mentions in the preface of his book on Refactoring. In early 1997 when I began a contract gig, I walked into a large room and saw complete chaos – typical back then. After a little while though, I noticed in the middle of this chaos was a little island of sanity and when I dug further I discovered this little island consisted of 5 ex-Smalltalkers. Very grumpy ex-Smalltalkers, they were told to learn Java.
But it was amazing watching them, some crazed manager would come running up to them yelling stop the presses! The requirements changed, what's the damage, how many months is this going to set us back?! They'd calmly consult with each other, turn around and say: it will take us anywhere from 5 minutes to 2 days to fix this, and darn, 90% of the time it was a 5 minute fix. It was like watching Neo at the end of the first Matrix when the agents raise their guns and fire a hail of bullets at him, and he puts his hand up and the bullets stop in mid-air and just fall.
After 10 years of C including a failed attempt to understand "why C++?" I thought I'd better latch on like a pitbull until I figured them out. One of them was my husband Frank.
In the 14 years that I've known this guy, for a good chunk of that time I've watched him saunter in to work late and leave early, and yet he was far more productive than anyone else that I know. And that's because he did things like refactoring and applying agile principles (see last blog entry).
And because he did that, he had plenty of free time to read and keep up with what was going on. And, he kept stumbling on efficiency tips and tricks that kept making him even more productive.
Since then I've worked in some extraordinary environments, so I know what's possible because I've lived it. My biggest frustration since 1997, is that when not everyone is on the same page, it becomes so much harder. I try to stay on a short leash because simple designs and simple code are the only way for me to build robust systems and ensure that my highest priority is always my fiduciary responsibility to my paying clients and users. It allows me to handle more complex projects in the long run, instead of doing simple things in a complex way.
Funny thing is, even though there are people like Frank who have deeper technical skills than I have (my background is much more broad), they try to keep themselves on a short leash as well. Granted, there is talk about software craftsmanship and aesthetics and yes, some of us are definitely OCD. There are glittery baubles like ScrumMasters and daily stand up meetings. But I think it's important to understand the core, not the superficial trappings (like the quote: "don't Do agile, Be agile"). For me, based on my experiences, the heart of the real reasons are as follows:
When things are refactored and clean you can add functionality as quickly 8 months down the line as you did the first couple weeks of a project.
Even if you're a rockstar, you're invariably going to have to work with developers who have less experience than you. Better to take the time to build something understandable and maintainable than to have to spend the time explaining the design every time someone new comes on board.
More normal working hours and therefore more time to spend learning and researching and even day dreaming which invariably leads to those weird, accidental leaps that can result in a new idea, new project, new way of thinking, etc. (DeMarco Slack).
You relish getting in and working on the code, you don't dread it. When we were working on iDefer we worked on it practically every minute we could, not because we were on some death march but because it was a joy. On other projects I've had to grit my teeth and muster up the courage to dive in and work on something that I knew needed to be cleaned up.
When you work in emerging technologies and are pushing the edges of the envelope, you may run into things like an obscure bug in UITableViewController. Or design constraints with UISplitViewController. Or you're grinding your gears because you misunderstood the intent of these powerful frameworks. It's nice when these things stick out like a sore thumb, you'll be howling enough as is. It's far worse when these things are obscured because you're shooting yourself in the foot with bad designs sprouting hacks upon hacks.
I keep myself on a short leash because I shoot myself in the foot regularly anyway. My bugs tend to be giggle “that was stupid” bugs. No longer those bugs where the hair on the back of my neck stands up and my brain goes into overdrive as I think: great, how am I going to get myself out of This one?! For me a bad smell is when someone says: that was a really, really subtle bug...
Let's look at the other end of the spectrum, at those extraordinary minds capable of prodigious programming prowess. People who should be standing shoulder to shoulder with the luminaries of the IT industry. They are capable of doing things I will only dream of, but they don't realize a 300 line method is not clean code. And so they pour their extraordinary talents into building a system that is ever more extraordinary in its ability to hold it together for a very, very long time before things finally implode. By then you're halfway to Pluto. They are the strongest of the weakest links, and I would venture to say they are far more dangerous than anyone else. Because they're still human and they make mistakes, but when they hiccup they're liable to take out anything and everything within a ten mile radius.