Wednesday, November 30, 2011

How to ask intelligent questions

Smart technical people (aka Hackers) have likely dedicated thousands, tens of thousands, or hundreds of thousands of hours of their lives learning, understanding, and generally figuring out how things work. If you find yourself asking for help, I'd suggest approaching it like you would approach asking advice from someone like Tony Hawk on how to do a kick-flip (I apologize for folks who don't know who Tony Hawk or Ryan Scheckler are and further apologize if you don't know what a kick-flip is... you really should get out more. I further apologize for suggesting that programming a computer is in any way as difficult as performing a kick-flip, I've skateboarded since I was...like 13 and still cannot pull one off without doing a no-comply, it's just a useful metaphor that non-technical folks might be able to understand.

To illustrate some approaches:

BAD "Tony, I've never even stood on a skateboard before, but I REALLY want to learn. I've got a spare 5 minutes, could you teach me how to do a kick-flip? oh and could you give me a free skateboard? I don't have one yet and you get them for free so I figure you wouldn't mind giving one to me. By the way, I wouldn't bother you, but Ryan Scheckler seems too busy to help me."

BETTER "Tony, I never land my kick-flips, the board seems to land on it's side, any tips?"

MORE BETTER "Tony, I've been skating for 5 years and for some reason I land my kick-flips on the side of the board. I looked up some tips online and saw your video on youtube, and I think the problem is I'm not flicking my foot hard enough. I've considered getting a different pair of shoes... I brought my board with me, if I showed you could you give me some advice?"

OK, hopefully everybody understand the problems with approach #1. You're asking a professional to teach you something that has taken him decades to learn and perfect and dilute it into a 5 minute lesson (for free). You're unprepared and unequipped to even begin to solve the problem... this is like people who want hackers to troubleshoot their "broken computer" while sitting at the bar after work (while the computer is at home). You haven't even TRIED to solve the problem yourself... this means (to many) you don't even possess the dedication or resolve to even TRY. This is kinda like when someone has a problem and local hacker tries to help and the person requesting assistance decides to go out for coffee. Approach #1 in the hacker community will either: Not get any reponse, or get the equivalent of "FSCK OFF!".

Approach number two is better because it shows dedication, preparation, and makes no assumptions about how much time/effort could or should be put into it. An appropriate response to #2 would be "Practice Harder". Approach #2 is likely to get terse responses, but you won't likely hear any expletives.

Approach number three is most likely to elicit the best response. You've done your homework, you're dedicated, you're prepared, you've got a solution you aren't sure of... rock on! If a hacker doesn't give helpful advice in #3 remember: You're still asking for free advice...I'd personally expect to PAY for personal skateboarding training from a professional skateboarder -- get it, PROFESSIONAL, like, that's how they put food on the table. Free advice from a professional is known as "a favor" and should be treated as such...

For folks who have been in the open source community for a length of time, there is an old article explaining how to ask questions the smart way. While I think that writeup is spot on, I think it's a bit inaccessible. Listen, getting computers to do what you want is very difficult work and VERY challenging (if it wasn't, the job wouldn't pay so well and hackers wouldn't be in such high demand). Yes, I realize it isn't as rare as skateboarding talent, but hopefully the metaphor helps explain why many hackers seem to NOT be helpful... it's not THEM, it's YOU!

I apologize in advance for anyone who is easily offended.

Honestly I don't care if you're offended, but I figure I'd put a token apology in because people who are easily offended are often shallow enough to be placated by a token apology.

Thursday, November 3, 2011

stop branching! agile is soccer, not american football

One trend I've noticed with git users is a habit to create a lot of branch and merge activity. The oft-repeated mantra is "branching is (easy/cheap/safe) in git so I do it a lot". When working on an agile project though, this behavior can cause serious problems. To illustrate the point, compare american football to soccer: American football has highly specialized players and positions as well as a variety of tightly choreographed set pieces. In contrast, soccer has a much lesser degree of specialization, and while there are some set pieces that are choreographed, the majority of the game is spent reacting to the situation as it evolves. Traditional development methodologies are like american football: They divide the work up among highly specialized players and then try to replay an intricate set of movements to make the play "work". Agile methodologies are more like soccer (or to a lesser degree rugby) in that the advantage doesn't come from following the choreography (or even rehearsing it), but from reacting to the current situation on the field and having visibility and vision as to the current state of the field. When teams start creating a lot of branches and working in isolation for large periods of time (relative to release frequency), that means they are often making assumptions about how the plan is supposed to work. Unless this has been worked out well in advance, it often leads to a "massive catastrophic merge" when everybody tries to come back together. To maintain an agile development process, it's important to react to interdependent changes as early as possible and reenforce the notion of a team of generalists who must react and move based on the current situation, NOT by following a plan that was written months before. So, if you're on an agile team of 5 and each of you are working on multiple independent branches and not sharing them on a daily basis, you're probably trying to play american football. Instead of developing vision and dealing with the ebb and flow of the game as it unfolds, you're trying to rehearse what you think your role in the project is supposed to be so that you can execute your portion perfectly at the appropriate time.

Wednesday, November 2, 2011

I beat ruby on rails by 6 months

Waay back in 2003, I got tired of writing the same boilerplate crud apps and longed for a "better way to do things" so I wrote a rapid development framework called thrust. It used turbine, velocity, and torque to build an entire web application scaffold from an xml database schema definition. I look at the code now and kinda chuckle and shake my head, but something I realized is that it predates the public release of ruby on rails by a good six months. Moreover it predates the closest allegory I can find in the java space (Spring Roo) by a good 6-7 years! I'm not just tooting my own horn, because I remember talking to other people who all said things like "we should just use conventions" and "this stuff is just boilerplate, why don't we generate/template it?", but it seems like most folks just built internal-only proprietary solutions. Couple of lessons/observations: #1 promotion is everything... rails languished in relative obscurity until some folks started evangalizing it. My solution died on the vine as I moved on to bigger and better things. #2 Timing is important, but not MOST important. Being first can be an advantage or a liablilty. Grails got to learn from rails and avoid some of the wonkiness (for example). #3 Some times it's good to go back and look at what you've done for inspiration. I had forgotten about velocity templates...which are pretty useful. I also didn't realize that Maven (arrgh) originated form the Turbine project (which is what my framework was built upon). #4 Great ideas seem to burst on the market in a short period of time and one or two solutions seem to end up dominating. It seems that tech trends infect large numbers of developers simultaneously and then go away.