Nimble Code: Category Project Management

Things I Figured Out

2006-07-03T09:58:00-07:00

And now for something different (and shorter, for those recovering from the length of the last post). Insanely talented Internet prankster Rob Cockburn recently posted a short and sweet article Things I Figured Out, where he listed a bunch of interesting and slightly stupid revelations he’s had over the years. This has been followed by 15 pages of reader comments chronicling their own brilliant insights and forehead-slapping moments.

I think this is a brilliant idea for an article, and I’ve certainly had my moments of utter brilliance and sheer stupidity (even this blog probably has examples of both). So, I’m going to post a few of the things I’ve figured out on my own or, failing that, learned the hard way. But since this is a technical blog only, there will be no personal idiocy. Just technical things I now know better about now

XML is Not For Everything Great for long data files, lousy for configuration files, downright terrible for love notes. It’s not one-size-fits-all.

XML Is a Minute to Learn, a Lifetime to Master It’s easy to gloss over some of XML’s subtleties when you begin, but they’ll get you later if you aren’t careful. Sadly, very few resources articulate some of the things that’ll get you, but maybe there’s a future blog post about that.

Somebody’s Done It Better Already I’m being glib here, but one of the joys of Open Source is that if you need a generic component, it’s best to look for someone who’s created it already. For instance, if you need a logger, you could write one on your own, but there are excellent libraries out there and your time is better spent writing stuff you can sell.

HTTP Blows Away Raw Sockets Unless you absolutely, positively have no choice, there is no reason you should use raw sockets instead of HTTP protocol for remote services. Sure, it might be harder to set up in the short run, but it’s so much easier to debug and maintain in the long run this is a no-brainer. Especially since small, light, and fast HTTP parsing libraries are available for all.

Often Too Much Is Worse Than Too Little Or as Donald Knuth put it, “Premature optimization is the root of all evil.” I’ve been stung so many times by trying to be clever, I’ve finally realized I should see if it’s slow before I try to fix what ain’t broke.

Stored Procedures Are Evil DBAs swear by them because they’re supposed to control access and speed up performance. In reality, they move application logic out of your program into an awkward language (SQL) that will usually fall out of sync with your application and aren’t kept consistently in sourcesafe or migrations. Worse still, they’re the trenches for warfare between developers and operations.

Developers Black-Box Way Too Much It’s too easy to leave this with a cliché admonition to “think outside the box,” but it’s sadly true. As developers, we’re taught early the useful technique of abstracting away complexity within black boxes. This is useful for that third-party API or calling operating systems, but it’s very easy to fall into that trap in your job (“we’ve always done it this way”) or your life (“I’ll just wait for career advancement to come to me”).

Physical Contact Matters The Internet still hasn’t annihilated geography yet. And personal, physical presence still matters. Meeting people is so much better than emailing them. Which I guess is just a roundabout way of saying, yet again, I should’ve gone to Railsconf. Sorry!

You’re Going to Screw Up The First Time. Just Accept It. It’s so easy to fall into the fear of not getting it right the first time, you never get started. Get over it. Accept you’re going to make mistakes the first time around and you’ll fix it later and do the best you can. And if you can, write unit tests to make it easier to clean it up when you start.

Things Break Slowly, Rarely All at Once It’s rare you can pinpoint a single decision or piece of code where everything catastrophically failed. Instead, the road to failure and mediocrity is a gradual and painful process, of many small failures along the way. It’s hard to resist the downwards momentum, because it always seems feasible to reverse. I would like to see more project management texts that tell you how to stop digging that hole.

If You Can’t Explain It, You Shouldn’t Do It. Sometimes I think half of IT operates by overwhelming your natural instincts and confusion with so much jargon, your brain just gives up. It’s a mysticism of sorts, but the wakeup to reality again is painful. My rule of thumb is if I can’t explain it in plain English using metaphors, and optionally table utensils, then it’s not worth doing. Because it most certainly will not be maintainable.

Okay, that’s all I have so far. But I’m sure the realizations will keep coming. Happy 4th of July everybody!

Are You Happy?

2006-05-31T15:25:00-07:00

I read a lot of feeds. A lot of feeds. In my hobby trend-spotting (it’s like a dorkier birdwatching), I read my feeds to monitor the zeitgeist to see what the real Alpha Geeks are into. And the last year has had some interesting trends. For instance, dynamic languages like Python and Ruby are now firmly the new wave, although functional languages (Haskell, OCAML) and prototype languages (Io) seem to also be attracting interest. Web2.0 is a term bandied around casually, mocked, and even litigated over , but the concept seems to be here to stay. The most novel aspect I’ve seen about Web2.0 is that the Web has become a source of real tools many developers are using to manage their lives; as a holder of Sun stock much diminished in value, I guess I can at least take comfort in the fact that their adage “The network is the computer” seems to finally be coming true. Sure, it’s about 6 years later than predicted, but it’s happening.

But most interesting to me is when the alpha geeks flock to ideas not directly related to coding frameworks, business plans or the like. For instance, six months ago it seemed like every serious hacker was devouring Getting Things Done and blogging about organizing their lives. And now the new obsession is Flow. A conceptualiztion first coined in a book fifteen years ago, Flow is a term Mihaly Csiksczentmihalyi (don’t ask me to pronounce that) coined for that mental state where work is stimulating but not frustrating, intention translates effortlessly into action, and happiness and productivity are intertwined. Csiksczentmihalyi teased out a description of Flow by looking at the mental states of people practicing Zen mindfulness or risking bodily harm in extreme sports like rock-climbing or surfing. But he could just as easily described the euphoric states of serious computer programming. Small wonder this book has now been “discovered” by the alpha geeks, this fleeting feeling is what we find so addictive about programming in the first place.

The basic concept of Flow is that certain tasks make us happy to do them because they exist within a narrow channel between fear and boredom, because they encourage us to improve our skills but do not overwhelm us with too many challenges at once (for Donnie Darko fans, the goal of flow is to find the middle of the fear-love axis). We developers are well-acquainted with that fear. It’s the fear that keeps you from refactoring that legacy system because you’re not sure what would break, the fear that keeps us using a clunky library because we can’t test changes, the fear that makes deploying the new version to the server nail-biting because it’s crammed full of changes that might take it down. In short, fear and specifically fear of change is a constant state of mind for too many programmers, but it doesn’t have to be. A state of happiness is possible if you can conquer the fear.

Flow is the reason why some frameworks like Ruby on Rails are so appealing to programmers; it straddles that line between utter boredom (coding a web site in PHP like always) and high anxiety (having to master a complicated system like Cocoon just to print out “Hello World”). The key is allowing people to add capabilities (like authentication, tagging) as their skills grow, but not require everything to be planned up front. It conquers the fear of change, but hacking change into smaller steps. What makes a framework good (the same is true for languages, methodologies, testing, architectures) is how it destroys this anxiety.

For most of my career, the basic question asked of developers was are you productive? Computer programmers are naturally obsessed with productivity. This is after all a field where good programmers can outperform bad coders by several orders of magnitude. and for years the industry has marketed to this by selling tools that promise leaps in productivity. The key to productivity was seen only through uses of higher-level toolsets/IDEs or APIs. This is a philosophy Cote has memorably termed Right-Click Coding because of all the right clicking and fiddling you have to do to get anywhere. This was seen as a development accelerator, because it enabled poor developers to do complicated things like enterprise integration and GUI development without needing to actually write code or learn details of how things work. But, I think that overall such tools have actually decreased developer productivity in several ways. Like a teacher teaching only to her worst students in class, the wizards and libraries stifle and frustrate more able programmers. And since they remove developers from using the underlying code, wizards only accelerate bloat and complexity in their underlying code bases.

Worse of all, the fear was still out there. Indeed, like air conditioner output makes city streets hotter, they’ve made the situation worse. By piling away programming within massive APIs and single-purpose wizards, this approach has created a nightmare of complexity waiting to ambush more able developers. Now the question becomes are you compliant? Being savvy to the latest standards, libraries, or buzzwords is touted as the key. But the difficulties people have had using SOAP is but one example of how compliance doesn’t really help either. Just mention “interop” to any CTO or high-level architect and you’ll see what I mean. The complexity (and the fear) are still there, standards compliance just blames the programmer when things go wrong.

Instead, it’s time for a new question: are you happy? I think the growing interest in Flow and GTD and higher-level languages and test-driven development and agile project management reflects a sea change in attitude by the alpha geeks. Trying to find happiness through artificially increasing productivity is like putting the cart before the horse. The key point of Flow is not that productivity fights fear and creates happiness, but recognizing that creating happiness is what creates productivity. I think it’s about time, if we want to avoid the descent into compromises and disillusionment common in computer science. So, get in touch with your feelings when deciding about that design, language, system, api, etc. and ask yourself “am I happy doing this?” I think your instincts are a better guide than you know. Trust them. And don’t be afraid to be happy.

Update: I added some links to the original book as well as discussion in a short take posting. Happy reading!