Moving to Berlin and auf wiedersehen to friends

It’s hard to believe it’s been almost two years since InfoEther was acquired by LivingSocial. Since then, we’ve built the strongest development team I’ve ever known. We’ve set records for e-commerce transaction volume. We’ve grown at an incredible pace, both as a business and as technology team. We’ve shipped a lot of software, and made millions of people’s lives more interesting in the process.  I’ve had the privilege to work with some of the most admired engineers in on industry. I’m proud of the team Aaron Batalion (from whom I’ve learned a ton about running a consumer internet product) had assembled before InfoEther arrived and of the team that ultimately grew from that foundation.

As I mentioned when I announced our Hungry Academy program, for me personally the experience at LivingSocial has been intense. As I said in that post, “These last 8 months at LivingSocial have been the best 4 years of my career.” That holds true today.

Playing the role of Senior Vice President of Technology and serving on the senior executive team at LivingSocial has been a rewarding learning experience.  I’m humbled by the talent and experience of every member of that team, and since my first day have been awed by Tim O’Shaughnessy’s business sense and natural leadership ability.  I look back on my career, and a handful of teachers and mentors stand out that have had a significant impact on me. Tim is now in that very short list.

All the while, though, I’ve known that I would eventually go back to a more hands-on role, personally building products and solving technical problems. I am, after all, a Passionate Programmer.

Kelly and I have also had  a goal to (before we get too old to fully enjoy it) live overseas again.  Our time in India, was a huge influence on both of us, both personally and professionally, and we’ve long since hoped to gain a similar experience in a different part of the world, specifically Europe.

So that’s what we’re going to do.  I’m taking a role as CTO of a technology startup in one of our favorite cities: Berlin.  I’ll be working hands-on to develop cross-platform software with a small, talented team of engineers, designers, and product managers. I’ll be transitioning from my role at LivingSocial for the remainder of January and will be relocated to Berlin and starting the new job in mid February.

As excited as I am to move to the next adventure, it’s always sad leaving a great company like LivingSocial.  I’ve made some friendships that will last forever, and I’ll miss the team immensely. I know, however, that they’re in good hands and that 2013 is going to be a fantastic year for the business. 

Leaving a Legacy System revisited

Early last year, I posted about how we’ve unfortunately turned the word “legacy” into a bad word in the software industry.

At Nordic Ruby and again at Aloha Ruby Conf this year I turned this idea into an exploratory presentation. I think it turned out pretty well and is an important topic. Watch it and let me know what you think!

Practicing Fear

	I must not fear.
	Fear is the mind-killer.
	Fear is the little-death that brings total obliteration.
	I will face my fear.
	I will permit it to pass over me and through me.
	And when it has gone past I will turn the inner eye to see its path.
	Where the fear has gone there will be nothing.
	Only I will remain.
	                   Frank Herbert
	                   Dune

Fear isn’t necessarily a bad thing. It’s a defense mechanism. But it can be paralyzing.

What makes fear good or bad is how we react to it. Fear can make you stupid. It can make you forget to think. (is this part of the evolutionary response to fear?)

Examples of fear reaction practice

Difference between practice and desensitization

The art/craft/commodity continuum

When you create art, the purpose is self-expression.

When you create software, the purpose is rarely self-expression.

When you create software, someone somewhere wants it to perform a set of functions and has a stake in how well those functions are implemented. The definition of “well” is up to the stakeholder.

When you create art, you want it to be beautiful, or beautifully ugly, or ornate, or plain. You, the creator, are the stakeholder. You may hope that others find it beautiful, but if they don’t, it’s art—who’s to say what’s good and bad?

When you attempt to judge the quality of a commodity good solely in terms of its aesthetic appeal, you ignore the objective evaluation of how well that product meets the needs of its stakeholders.

When you attempt to judge the quality of a piece of art solely on some objective measure, you miss the point of the object as an expression of art.

Craft falls somewhere between commodity and art. Craft items have both subjective, aesthetic appeal and objective function.

This is a beautiful Christian Dior dress:

Beautiful but largely impractical. Try to wear this on the subway or even in your car. Try to fit it through a standard door. It’s a beautiful piece of art, but it fails as a useful article of clothing for most people.

This is a Paul Smith suit. It’s practical, extremely well made, creatively designed, and probably very expensive:

This is a pair of pants on sale at Wal-Mart:

Beautiful? I don’t know many people who would call this beautiful. Completely unremarkable.

And so it goes…from art to craft to commodity.

Now consider yourself as the customer here. My guess is that most of my readers, even with an appreciation of the quality of the Paul Smith suit, would be much more comfortable in the Wal-Mart pants.

When we create an item for another person, we have to consider whether that person is looking for art, craft, or commodity. We may wish to always be creating art. Or craft. But sometimes our customers want commodity. Not only is commodity cheaper but it’s what they prefer.

Re-thinking Software Development Education

Where have I been lately? Good question. When asked over these past months, I jokingly say something like, “These last 8 months at LivingSocial have been the best 4 years of my career.”

But I don’t just mean I’ve been busy. I’ve been focused on building the best software development team I can to do what I think is some important and industry-changing work in the world of local commerce.

And when I joke about these 8 months being the best 4 years of my career, what I really mean is that I feel like I’ve learned 4 years worth of lessons and gained 4 years worth of experience. What we’re doing isn’t easy. It’s the kind of work I’ve always sought out.

I am a self-taught software developer. To date, my formal education consists of two 3-day training classes on specific programming languages (Java many years ago and Erlang in 2008). During my first work experiences in IT, I remember the shock of discovering that a Masters degree in software development doesn’t necessarily translate to knowing how to effectively use a computer. I was a saxophonist and system administrator and would regularly teach the computer scientists I worked with about things I would have assumed they learned in college.

As I headed further into the workforce I noticed another odd thing: people with tens of years of experience as software developers weren’t necessarily very good at it. My assumptions were based on what I had previously learned as a jazz musician. Jazz musicians polish and hone their skills throughout their careers. The longer a jazz musician has been playing, the more likely he or she is to be an excellent jazz musician.

Programmers, though. As far as I could tell the average programmer spent his day complaining about his co-workers and waiting for 5pm.

So what’s the disconnect? Some of it, of course, is just the people. Some programmers are passionate and some aren’t. Those that aren’t, aren’t going to be radically successful. Assuming this is the case in all fields, what’s really frustrating to me is that I continue to run into passionate developers who just don’t know the right stuff.

When I started out in this field, I was lucky enough to stumble onto a mentor. That too was probably informed by my experience as an aspiring jazz musician. Jazz musicians take the idea of musical lineage seriously and look for someone from whom to receive direction on how to parse the potentially overwhelming task of going from novice to master jazz improviser. My mentor in the software field did the same. He told me: first learn these three things. He picked topics that were diverse but complementary. He picked skills that set a foundation on which it was easy to build the next set. Most new developers don’t get so lucky.

And It’s not just technology skills. The developers I work with are entrepreneurs at heart. We aren’t sitting around polishing our tools and conducting thought experiments. We’re delivering stuff that matters and we hate working on projects that drag on or don’t deliver value. Becoming a great developer involves not just learning the ins and outs of software development but understanding how businesses work and exactly how software systems fit into that picture. It’s about delivering value quickly and iteratively. Great developers understand what Kent Beck and the rest of the authors of the agile manifesto were getting at a decade ago. And what people like Eric Ries are teaching today.

I’ve often thought “just give me 3 months with a smart person and I can have them running circles around the average developer.” Have you thought that too? I know a lot of my colleagues have.

It’s time to rethink how we educate software developers. Computers used to be huge scary machines in big white rooms that very few people touched. Today you probably have at least one computer ON YOUR BODY most of the time. They’re ubiquitous and friendly and just NOT that hard to work with. The technology landscape has changed. The system of educating developers should change along with it.

My colleagues are clearly thinking along the same lines. I’ve seen speakers such as Joe O’Brien talking about it this year. And we see programs popping up all over. Software Craftsman Ken Auer is launching the Craftsmanship Academy to teach apprentices the art and craft of software development in an intense hands-on residency-oriented program. Code Academy is a part-time 12 week course to accelerate the path to web development or design.

Today we’re launching a new program at LivingSocial called Hungry Academy. Hungry Academy is a five month intense entrepreneurial immersion that will take raw, hungry talented programmers (and aspiring programmers!) and develop them into ultra-productive software engineers. Those that make it through to the end will be offered a position on our development team and paired with a mentor from LivingSocial’s growing list of some of the industry’s most talented software engineers. Best of all, we will pay you to attend. Your job for five months is to take your craft and career to the next level.

This isn’t going to be easy. Some people will get in but won’t make it to the end. Those that do will spend five months gaining the best 4 years of experience of their careers.

Leaving a Legacy…System

Ever since reading David Heinemeir Hansson’s post Enterprise Is the New Legacy over five years ago, I’ve been chewing on something. The gist of the post was that “enterprise” is and should be a bad word, just like “legacy”.

But why is “legacy” a bad word to begin with? The word makes most software developers and IT people ill.

In other fields and in life in general, the word “legacy” isn’t thusly encumbered. It refers to an inheritance left to those behind you. Your life’s work. Your essential story.

In software, that story is assumed to be a tragedy.

But even in the case of software, “legacy” is an indication of success. Sure, old software was written with old technology. And most software (or indeed most things created by humans) has its share of warts and dark corners. But the fact that we refer to a piece of software as “legacy” indicates that it was successful enough to have been deployed and to have been used for enough good that it is now something we’re “left with” and that we must either maintain or replace.

That isn’t so bad, is it? In an industry where more software projects fail or are ‘challenged’ than succeed, getting to legacy status is cause for celebration!

Here’s a sad idea: as developers, even when we do succeed, we tend to create things that are abandoned at great cost only a few years after we pour our hearts and souls into them. As rough as your last project might have been and as hard as the deadlines were, chances are your project will be disparaged and terminated within 10 years of its birth.

So, what do we developers leave as a legacy? In most cases, we don’t leave much of anything.

At a previous job, a mission-critical core system ran on an ancient, customized mainframe with a custom TCP/IP stack and a custom relational database system. At the time, the system was over 25 years old. It performed well. It survived Y2K. It was well understood. It reliably ran our (big) business.

That was ten years ago. I’d be willing to bet it’s still running. If not the whole system, at least a subset.

That would make it 35.

Sure, it had its ugly parts. And most of us were terrified of it. But, hey! Still running and doing its business after 35 years. I hope I ever create something that successful.

How would I create something that had that kind of longevity? How different would my designs be if I believed I was creating software to last 40 years?

It’s daunting, isn’t it? My knee-jerk reaction might be to do a Big Design Up Front. But how could I possibly design an entire system with 40 years of future knowledge in mind? I couldn’t. Even predicting next year is hard.

So maybe I’d need to design something that was ultimately flexible. A framework of frameworks where everything is pluggable.

Any software developer who lived through parts of the 90s knows these systems buckle under their own weight.

I don’t know how to design a system that could live a long and healthy life. I don’t know because I haven’t done it yet. Have you?

Note: This wasn’t a rhetorical question.

The Harajuku Moment

A few years ago, sitting in the July heat on a wall in the Harajuku district of Tokyo, I came to a conclusion: I had let myself be a loser. At least, I had let myself become a partial loser. I was fat and unhappy. My skin looked grey. I was slowly killing myself. I was obese. I made excuses to myself and others. I used my success in other areas as a justification: I just wasn’t a fitness guy.

It was bullshit.


Me (on the right) and Michael Foord

These days I’m still not an elite athlete, but I’ve turned things around. I’ve lost nearly 100 pounds, gone from a max ability to run 45 seconds at a time to running a half marathon, and lost 10 inches around my waist.


Me after losing 70 pounds (photo by Duncan Davidson)

Before, I was incomplete. I allowed myself to believe in a partial picture of myself. Now, I’m closer to the real me. I’m still a smart, creative guy. But I can also do more pushups in a row than the average American male, and can run longer and faster than most guys my age. And I feel great. I feel noticeably better almost all the time.

I’m often asked by other obese and overweight people how I did it. People see me at conferences and other venues and literally don’t recognize me. How did I make such an incredible transformation?

If you’ve asked me this question, this post is for you.

It’s a long story. But I’m going to give you the very very short version: it was easy.

I could tell you exactly which system I devised and exactly what worked for me. But that would be missing the major point. The most important element of making a change like this is that it is easy.

If you could trade your body for one that is 50-100% better in a year, what would you give? If you had asked me in early 2008, I wouldn’t have even believed it possible. I would have given a lot. What about 6 months? Obese or overweight people, what if I told you that in 6 months you could be in almost unrecognizably better shape? Would you jump on whatever I was selling?

The secret? I’m not selling anything. It’s just true. Choose any non-bullshit system and actually stick with it for 6 months and you can and will experience life-changing results. You can extend your life span significantly.

If you’re reading this and you want to change, here’s what I want you to do:

1. Recognize how deep in denial you’ve been
2. Measure yourself now. If it’s weight that’s your issue, get on the scale immediately. Stand on it and cry. You probably haven’t been measuring it, and it’s probably worse than you think. Embrace how far you’ve gone in the wrong direction. This is the end of that long, drawn out series of lies you’ve been telling yourself.
3. Find any program that doesn’t look like snake oil and try it for 20 days. Measure your progress. If you don’t know what to try, start with 45 minute light cardiovascular exercise sessions 4 times per week (find a TV series to watch on a treadmill…a one hour show without commercials is about 42 minutes), forcing yourself to eat a protein-heavy breakfast within 30 minutes of waking, cutting out empty calories and sugars (coke, sugar-heavy “coffee” drinks, beer, etc.), and eating 5 small meals per day.
4. After 20 days, you’re almost 1/6 of the way through a major transformation. You have probably gone down one clothing size or are close to it. How far do you want to go? Pick something you didn’t previously think you were capable of and commit to it. Maybe it’s a bike race or a triathlon or doing Cross Fit.

The funny thing about huge change is that making it happen isn’t usually as huge an effort as we think. We just get stuck. All you have to do to go ALL of the way is to go SOME of the way.


Note: I wrote a more detailed account of my weight loss story in Tim Ferriss’s best selling book, The Four Hour Body. I have no financial interest in the book, but having re-read my own chapter when Tim sent me a copy of the book last December, I was inspired enough to double down on my efforts to go from OK to awesome. I’ve lost 20 more pounds since January 1. Tim’s advice for weight loss is solid, and (if I do say so myself) my chapter alone is worth the cost of the book.


Caring Like Crazy

I’ve just finished reading Gary Vaynerchuk’s The Thank You Economy. From the outside it looks like a book about marketing. It looks like a book for companies who need a “social media strategy”. On the inside, it’s much more.

Everyone doing business of any sort has an important lesson to learn from The Thank You Economy. Here’s that lesson in Gary’s own words (from last year’s RailsConf keynote):

  "Giving a Fuck is comin' on strong!"

Gary uses this phrase over and over in the book: “caring like crazy”. What does that mean?

Joel Spolsky wrote a whole book about how what you need out of people you work with is for them to be smart and to get things done. Having hired a ton of people myself (hundreds) and worked with a fair number of others, I have to disagree. Smart and gets things done are both excellent, important qualities. But ultimately I don’t care if you’re smart. I’ve worked with my share of brilliant people who just don’t care.

Look at this exchange between Corey Haines and Justin Gehtland from a few days ago:

I worked with a CEO in India who embodied this idea I remember the first time I noticed it. We walked in the front of the building and he noticed some trash on the lawn next to the security guard who was stoicly standing there staring at nothing. Trash in India. It’s everywhere. I certainly didn’t notice. It seems like an impossibly uncontrollable problem.

In mid-sentence, he stops and runs over, picks up the trash and hurries back over to the guard who learns that we’re not going to have trash in our lawn and if the guard doesn’t care about his workplace he can go somewhere else. He wasn’t mean about it. He was matter-of-fact. The guard tried to take the trash from him, but he wouldn’t have it. He took it himself and threw it away. He did this constantly. Eventually, all of the guards started doing it. Then the programmers started doing it. In fact, anything broken, or dirty, or at all not right got fixed by whoever saw it. We were a culture of caring and it was going to be both superficially and deeply ingrained.

One of our people got severely injured a few months later in a motorcycle accident. He wasn’t wearing a helmet, as is very very common in India. From that day on, our CEO or I stood at the drive into the building refusing to allow employees in unless they were wearing helmets. A couple of the employees couldn’t afford them, so our CEO personally bought them the best helmets he could buy.

He cared about the business (even the building it took place in) and he cared about the people. And you can be damned sure he cared about the work. It was infectious. It was viral.

If you REALLY care and you’re capable, I don’t care much how smart you are for most work that needs to be done. Give me someone passionate over an apathetic genius any day of the week.

So this is my takeaway from The Thank You Economy. Care like crazy. Whether you’re running a company or just running your career. It’s sound obvious, but it’s oh too easy to forget and let it slide. Let a little apathy in, and it makes a mess. A cyncical remark, or a posted Dilbert cartoon are all it takes to start the wrong kind of culture of apathy. Care like crazy.

A forum for The Passionate Programmer

I’ve setup a Facebook page for The Passionate Programmer. Please Like it, Share it, and post your own questions, experiences, act-on-it reports, or doubts.

Be Careful Of Who You Work With

You instinctively know that who you associate with matters a lot. Our parents bring us up steering away and toward others who influence us.

But most of us don’t realize just how much those around us influence us.

As I recall in the introduction to The Passionate Programmer, there was one specific event that turned the tide for me. I had been chugging along in my slightly-above-average corporate job and experiencing what I considered to be the height of success. Then I had an intense period during which, for a few months, I had the opportunity to collaborate with a whole new level of software developers. It all came to a head when I went to the eXtreme Programming Immersion that Object Mentor taught. After a week surrounded by brilliant developers and leaders in the field, I knew I had to do something different.

I had to be as much like them as I could.

In The Passionate Programmer, I quote Pat Metheny’s advice to young musicians: always be the worst musician in every band you’re in. As a musician and as a programmer, I’ve tried Pat’s advice. You play with a group of people better than you, and you’ll almost always play better.


http://www.flickr.com/photos/jazzuality/3613370192/

That’s good anecdotal advice. If you don’t trust Pat, how about Nicholas Christakis? Nicholas is a social scientist at Harvard University. Together with James Fowler of UC San Diego, his research focuses on how behavior and then even EMOTION spread through social networks. Can behavior be epidemic?

Here are some things their research has shown to spread through social networks ilke disease: Obesity), Smoking, Alcohol Consumption, and….HAPPINESS! Yes, emotional state is contagious.


http://www.flickr.com/photos/saintbob/165829023/

These aren’t insignificant numbers, either. For example, obesity chances increase 57% if you have a friend who is or becomes obese. And, more disturbing than that, this is an effect that is conducted through more than one node in the social graph. If your friends’ friends’ friends are obese, you are 10% more likely to be obese

If behavior spreads through social networks, then working in a toxic or slow-moving corporate environment is really really bad for you. If you’re a consultant, you MUST fire the clients that bring you down a notch and seek out clients that pull you up. If you’re a teacher, go where the students care about what they’re learning.

Automation and Outsourcing

What’s the difference between automation and outsourcing?

I don’t know if it’s the same everywhere, but here in the USA we’re deluged with fear-driven “news” reporting, decrying the theft or export of our jobs to low cost, less skilled, offshore labor. Or even onshore “illegal” labor. It might be Mexico. Or China. Or India. In the 80s it was the Japanese. And it was robots and computers.

I’m not going to argue whether any of this is true or worth being upset about here. I’ve done it elsewhere. What I’m interested in here is the question: what if, as individuals, instead of fearing outsourcing, offshoring, and automation, we decided to use it to our advantage?

The standard argument against offshore outsourcing goes like this: Offshore people don’t understand the work, or the culture, or don’t care about quality or just aren’t as good. They might be cheaper by the hour, but they’re more expensive in the long run.

OK. That’s a hard one to disprove. It’s also kind of hard to prove. Regardless, hold that thought


http://www.flickr.com/photos/dancoulter/21042744/

In this day and age, we’ve collectively gotten over the fear that computers will replace us all. We’re used to the idea that certain tasks can and should be automated. For the younger readers, did you know that there was such thing as a spreadsheet before computer existed? That’s right. It was roughly the same except a person had to calculate each value! And if any numbers changed, guess what happened? Someone had to recalculate them!

Anybody want that job? I didn’t think so.

So that’s automation. If you think really hard about what you do every day, I bet you can come up with a few things that could be automated so you wouldn’t have to do them anymore. You wouldn’t feel bad about those things. You’d be saving yourself time and saving your employers money if you could automate them. Software developers spend their careers doing this for others.

Anything that could be done by a computer or a robot (roughly) just as well as it could be done by a human should be automated. That frees the people up to think. That’s what we want, ya? Hurray!

Some tasks are almost automate-able. But they just need that little extra push. For example, human language is hard to parse. It’s not exact enough to write reliable programs (usually) to read and act on. So what do you do with those tasks that seem mundane enough to automate but can’t actually be done without a human?

Outsource!

Outsourcing might mean giving the task to a more junior person you already work with. It might mean hiring someone on another continent who costs a fraction per hour than you do and can be trained to do the mundane work you do. It might mean taking on an apprentice and teaching them as they handle the “easy” stuff.

But, the fact of the matter is, in the work that most of us do every day there are things we could have someone less experienced do for us. And if that person is happy to do it, benefits from it in some way, costs less than we do, or is just willing when we are not, it’s not a bad thing to try.

If you continually do things that are “below your pay grade”, you’re wasting precious time or money.

At the end of the day today, think about what you did today. Given a little time, how much of it could have been automated?

Given a little time to document what needed to be done, how much of it could have been done just as well by someone else who is maybe less skilled or less expensive than you?

McDonalds, Six Sigma, and Offshore Outsourcing (notes)

These are notes from a talk I’ve given in various forms at SCNA, CodeMash, and Magic Ruby. I’ve mirrored them here from the InfoEther weblog.


Me at SCNA
Photo credit: Monty Ksycki

The presentation is called “McDonalds, Six Sigma, and Offshore Outsourcing – Unexpected Sources of Insight”. Here’s the abstract:

We software developers like to think of what we do as an art form (or a craft, if you’re at this conference). I was once asked to come up with a set of guidelines for creating great software so our (huge) company could more effectively use an offshore development team that had been delivering amorphous piles of crummy, nonworking code. I was frustrated and responded with something like this: “Give me a list of guidelines for how to make a beautiful song!” The nerve! Repeatable processes? Who did she think she was talking to?! This is a creative process! This is ART!!!!

I’ve since grown up a bit and I’d like to talk about how I was wrong and how we can all hopefully learn from my mistakes.


The Art-Craft-Commodity Continuum (from my presentation)

In it, I tell the story of my experiences with the Six Sigma quality methodology and with offshore outsourcing, urging developers not to blindly write off potentially useful software development strategies based on hearsay and misunderstanding. I also propose a customer-driven, data-driven approach to software engineering, dovetailing off of InfoEther’s Chief Scientist, Glenn Vanderburg’s recent ruminations on “Real Software Engineering”.

The original, scary Ronald McDonald
The original Ronald McDonald (Willard Scott)

Videos from SCNA will be posted on InfoQ eventually, and I’ll link mine here when that happens. In the mean time, many people asked me for pointers to some of the books and resources I mentioned during my presentation. Here’s a link dump that you might find useful:

Rails 3 Recipes needs tech reviewers!

UPDATE: We got 8 times as many volunteers for Rails 3 Recipes reviews as we need. You people are awesome! Closing the call for help now.

The original Rails Recipes has been used by tens of thousands of Rails developers as they’ve worked toward mastering everyone’s favorite Web framework. Five years later, and after the release of Rails 3, we’re seeing a new wave of Rails developers. Through my work with InfoEther and The Pragmatic Studio it’s clear that an updated version of this classic would help a huge group of new Rails developers.

So here comes Rails 3 Recipes!

I’m a little over half way done with the new edition, which is full of both substantially updated and entirely new content. Now I need your help.

Before we take the book to Beta, we need technical reviewers. To tech review, you need to either already know Rails fairly well or be interested in trying to use the book to learn (some Rails knowledge is assumed).

In return for your comments, we’ll give you a free copy of the electronic and paper versions of the book as well as a mention in the book itself.

Interested? If so, please contact us at rails3recipes@gmail.com and let us know your level of Rails expertise. We can only handle a certain number of reviewers (probably 15), so we’ll be limited to accepting the first who get in touch.

To those who are interested, THANK YOU!!!!!!

If the original Rails Recipes’ success is any indicator, Rails 3 Recipes is going to be the book every Rails developer will have sitting on his or her desk over the next couple of years. I’m very excited about it and looking forward to some feedback.

width 120

How Rails Developers do Ajax (with jQuery) in 2011

Wanting to survey what the current state of the art in Rails Ajax development is, I asked this question on twitter:

Rails developers, how are you doing Ajax with JQuery these days? .js.erb templates? Rendering partials back old-style?

I got a lot of great responses! 44 last time I checked. Here’s what I found out people are doing:

  • mustache.js
  • Sending JavaScript back down to the client using .js.erb template files (Ryan Bates linked a couple of examples here and here)
  • JQuery templates
  • Hitting RESTFUL endpoints and responding with JSON data to be manipulated on the client
  • Using backbone.js
  • Rendering partials and updating elements on the page with their raw content (the original old-school Rails way of doing it)
  • Use SammyOnRails

There is definitely a divide and a lot of opinion (suprise!) between those who are OK with delivering JavaScript and/or HTML from the server to be rendered on the client and those who prefer to deliver data and have the client process it. I’d characterize the former as the less clean, more pragmatic approach and the latter as the idealistic cleaner approach. It seems that tools like mustache.js, backbone, JQuery templates, and Sammy.js are tightening the gap between quick + dirty and slow + clean.

What do you think? What did we miss?

I Don’t Know

I had the pleasure of watching Scott Chacon keynote at CodeMash this week. He spoke about how Github “manages” its development team and product development. I enjoyed the talk, and encourage you to download his slides if you weren’t at the conference.

Scott is a very energetic speaker and talks really fast, so he ended his keynote with a lot of time to spare (something I wish I would do more often). So he took questions from the audience.

A lot of the questions were about trying to fit Github’s process into companies of very different profiles. So, for example, “Would this work in blah blah blah environment that is totally different from Github?” Scott’s answer was excellent in these several cases:

“I don’t know.”

He didn’t blow the questions off. He then discussed possibilities. But it was incredibly refreshing to hear “I don’t know” from a speaker being questioned in front of an audience of almost 1000 people.

I wrote in The Passionate Programmer about the difficulty and importance of learning to say “no”. I think “I don’t know” is scarier and harder and maybe more important.

When someone regularly says “I don’t know”, you trust them more when they say they DO know.

Dead-End Jobs: Are You Suffering From Stockholm Syndrome?

Have you heard of Stockholm Syndrome? It’s a name given to the condition wherein hostages develop positive feelings toward their captors despite being held in negative, unfavorable and even life-threatening conditions. Victims of Stockholm Syndrome will even inexplicably stay with their captors even when given the chance at freedom.

Hopefully nobody reading this is literally being held hostage right now. If you are, good luck!

For the rest of you, why might I suggest that you are suffering from Stockholm Syndrome? Because employment relationships can manifest themselves in this very way.

In the article, Love and Stockholm Syndrome: The Mystery of Loving an Abuser, Dr. Joseph Carver says that the following four situations serve as a foundation for the development of Stockholm Syndrome:

<quote>

  • The presence of a perceived threat to one’s physical or psychological survival and the belief that the abuser would carry out the threat.
  • The presence of a perceived small kindness from the abuser to the victim
  • Isolation from perspectives other than those of the abuser
  • The perceived inability to escape the situation

</quote>

Looking back at my own career (specifically some of the extremely intelligent people I’ve met who are stagnating in oppressive companies or positions) I have recognized that many of these people (and sometimes myself) have felt “stuck” for no obvious reason. Some people seem just plain crazy when you look at their skill sets, ability, and the low quality of work or environment they’re willing to put up with.

So I contacted Joseph Carver to ask his opinion. Could this be Stockholm Syndrome? He agreed. In email, he said “SS is most likely to develop when the employee feels trapped, perhaps by a high salary, fear of losing a career, or fear of humiliation.” So let’s look at his four conditions:

Perceived threat:

Getting fired, being humiliated, not being a “top 20%” employee, not getting a raise. Employers wield a lot of perceived power over employees, especially for those in very traditional corporate jobs. The employer must be willing to carry out the threat. Every business is under the right conditions. It’s how businesses work.

Small kindness

Got a Christmas bonus once when you really needed it? Make a competitive salary? Great benefits? Get to work on a technology you don’t think you’d be able to work on elsewhere? There ya go.

Isolation from other perspectives

Again, a big corporate environment is ripe for this kind of isolation. If you work for BigCo, you learn to do things The BigCo way. The company’s organizational structure becomes a blueprint for your career progression. You start to lose sight of what industry pay and incentives look like since you have a homogeneous population to compare with. Unfortunately, from what I’ve seen even the best run companies create this kind of isolation of perspective and group-think. Charismatic leaders are particularly capable of creating a culture vacuum around a cult of personality.

Perceived inability to escape

According to the Bureau of Labor statistics, American adults spend by far more time working than any other activity. That’s a lot of your waking time being trapped in a routine. In a Stockholm Syndrome situation, the captor chips away at the self-esteem of the captive. So for most of our waking hours, those of us trapped in dead end jobs like these are exposed to environments which systematically destroy our self-confidence. Not only that, a persistent fear and feeling of failure makes it harder to actually explore the options for leaving the bad situation. The instinctive self-preservation reaction in this kind of situation is to work harder to try to avoid the perceived threat coming to fruition.


So, what if this describes your job? You owe it to yourself to find a way out. Hopefully recognizing the signs will show you that the real situation is far less grim than you might believe and that you have control over how you choose to spend the majority of your adult life.

I’m writing this for the many people I’ve met (and the countless I haven’t) that are senselessly stuck in bad job situations. Please stop wasting your precious time.

Software developers: how do you know when it’s the right time to do a big software rewrite?

Yesterday I asked this question on twitter:


Software developers: how do you know when it’s the right time to do a big software rewrite?

I’ve written about this topic before (The Big Rewrite). I’m revisiting it for a presentation Rich Kilmer and I are doing this weekend at JRubyConf.

I got a bunch of replies. Some serious, some sarcastic, some obviously filtered through the jading effects of a few Big Rewrites played out. The answer ranged from “NEVER!” to “as soon as you feel like it’s necessary”. The one consistent theme is that software rewrites are scary and the decision shouldn’t be taken lightly.

Drivers include maintenance cost, programmer happiness, politics, and fear.

Here’s what the developers on Twitter said:

when the mud (from big ball of mud) falls into your eyes

seriously, though, i believe when you lose confidence implementing changes it’s probably a good time to consider a rewrite

when you find yourself monkey patching areas that you wrote at 2am on a Saturday thinking “ugh, I just want this done with” 🙂

the right time is after reading your infamous blog post.

for us the big rewrite was: Scale fail (Can’t support more than 100000 titles) and customers want linux and not windows

almost never. Incremental rewrites of specific components results in better isolation and less risky code.

My team did it once. The first dev team was gone, the code, design and database were a mess, there was no docs, no unit tests

the bugs were all over the place, the chances were slow and risky and we needed to add tons of features.

The CIO figured out that it would be more expensive to maintain the current product than to create a new one

when you’re singing “WTF! WTF! WTF! Holy Christ! WTF!”

when you look at a code made by you and curse the programmer behind it

when the pain starts to exceed the political pain required to get that kind of authority

– when you have enough in the bank to survive its possible failure to deliver on time and within budget

When the fundamental design algorithm is O(n!)

when you just can’t stand it anymore

About the same time you start asking that question 😛

By having a ‘feeling’ about it. However, big software rewrites mostly fail. Better to start something new!

When you spend more time trying to understand code than writing code

when only god know what are you trying to do

wasn’t the answer “Never”?

That’s a question searching for a rule that doesn’t/shouldn’t exist.

, it’s time to do a big sw rewrite when adding small features/fixes requires a lot of time fixing/changing the existing code.

I prefer never. I gradually employ targeted rewrites. The app will be eventually rewritten w/out the cost of stopping the world.

When I sit around thinking, “Gee, how can I screw myself and bankrupt my company in one action?”

you’re netscape, you have crazy market share, your code smells, and Microsoft decides the internet is important. Oh, wait.

, or when the cruft/ick factor in your code base causes good developers to quit.

it’s rarely the right thing imho.

I’d say when the creativity/crap ratio is about 1:10 and still declining.

I’ve never seen a good time to do it. Incremental change has always worked best, for me.

probably when you have to ask yourself that question + 1 week

When you haven’t written anything yet?

When Code comments warn me that I couldn’t possibly understand what follows, and that it can’t be changed.

when the features you’d be trying to preserve by avoiding a rewrite never should have been written in the first place.

I guess we don’t. But the turning point is usually when it gets too painful to keep it and too difficult/unstable to refactor.

When the overly-sensitive head architect of the project leaves the co. because adding a form field becomes a herculean task.

when it is painful to make even a minor change

The more defects become stories with architectural impact the closer you are to that point!

you should divide and conquer; unless it’s a new paradigm in a new language.

I would suggest it depends on how well the project works currently and whether it can be done a piece at a time RT big rewrite?

@RobotDeathSquad BigRewriteQuestion does have a useful side effect: the earnest responses tell you “where that person is at”.

when someone ponies up the dollars for it

When your velocity is very, very low because of design and architectural problems in the code. Its a big hump though.

90% of the time it makes more sense to refactor the existing code. Unless it’s a ColdFusion app 😉

It’s time for the big rewrite when the most experienced developer has lost all faith in the code base.

However, before beginning a big rewrite, you need to “fix” the management responsible for a codebase that needs a big rewrite.

> i do not wait for this moment, i try to refactor everytime 🙂

Big rewrites only occur when both product and engineering management act “unprofessionally” per @unclebobmartin’s definition

when i realize i’m spending more time compensating for existing code than writing new code.

when everyone you ask says “oh that class? Yeah it’s garbage. Nobody wants to touch it.” Chances are, it’s not the only one.

if the cost of adding value now is higher than rewriting and then adding value? I usually feel a rewrite is the scary option.

When I start to consistently feel loathing rather than excitement when I think of better designs.

@thomasfuchs I am pro-“abandon ship” as well. The need for big rewrites are signs of more sinister problems.

We rewrote our app once when the original app was unbearable to maintain.

For us it’s whenever the boss tells us to 🙂 We converted an app from VFP 9 to #rails in just under 2 yrs

That’s the hardest question I’ve ever had to answer in this biz. You never know, you just guess and hope you’re right.

It’s time for the big rewrite when things are screwed-up or messy AND nobody is bikeshedding – in other words: never

Secondly, if given the opportunity, I like walling in the existing app and building new apps around it to extend function.

I try to avoid big software rewrites as they tend to be a death march. Instead try to chip using a strangler application

When developers don’t look happy while coding. The less enjoyable it is for programmers the more rewrite is needed 🙂

Must consider context, so right answer is “it depends”. But the raising of the question itself is probably an indicator.

When maintaining the system in production gets too expensive (include running costs of hardware and admin time).

a rewrite takes less time and has less risks involved than a functional conversion but results in lower quality as well.
by functional conversion I mean a rewrite-from-scratch scenario, and by “rewrite” I meant “refactoring”