Fair And Biased

iPod Vending

Here's a regular vending machine selling iPod's along with snacks.  Who would trust a vending machine to deliver an $80 device without getting stuck, possibly at 2:30 AM in the morning, with no one to service the machine?  I mean... what kind of... oh!  They're students at Columbia University.

In all seriousness, should salespeople be worried?  For the last 10 years or so, there's been this fear of outsourcing in the software development profession.  In other words, one person losing their job because someone else is willing to do the same work for far less pay.  In our field, high speed networks and an educated workforce in emerging markets makes this possible.  While all this has been going on, the common mantra of business folk has been "yeah my job requires person to person interaction so I'm safe."

Hold that thought.  Business work, especially Sales, doesn't have to require person to person interaction. Agreed, the iPod vending is a minor threat.  But that's how it starts.  I know I hate talking to sales people.  Even when they know what they're talking about, and aren't generally annoying, like at the Apple store.  The reason is I usually research what I'm going to buy before I go into the store so when the sales person approaches me, it pretty obvious very quickly that I know more about the product's features, pricing differences and competitive offerings. Especially when it comes to electronics.

Amazon.com has built a billion dollar business on this idea.  It's just much more efficient to buy from amazon.  The product reviews are 100 times more informative than talking to an in-store sales person.  For the $3.99 overnight delivery (with Amazon prime), it's practically as quick as going to the store.  Oh, and it's almost always much cheaper than the store.

Sorry store sales people: you've been made redundant.

And I'll take satisfaction in the fact that when I do loose my job to outsourcing, I'll be replaced by a real human being and not a robotic arm.

[photo: nytimes]

The J2EE'ization of Ruby

Well into the acceptance stage of my Java to Ruby grief cycle, I've found practical applications for Ruby as a rapid prototyping language.  When something new comes along, a good way to casually follow the technology is to subscribe to a couple of blogs covering it.  Ideally, from people who aren't afraid to criticize shortcomings (to balance out the cool aid).

Which brings me to this realization: most of the fuss going on in the blogosphere regarding Ruby is about Rails.  This is not a bad thing.  I understand that every technology stack is going to have its superstars.  But it also means that the same thing that happened to Java — where J2EE is the superstar, desktop Java is ignored, and J2ME... what's that again? — is going to happen to the Ruby stack.

Bouncing between the Java and .Net stack, I noticed that the reason for choosing one of these stacks over the other are usually political.  C# is nice, but delegates and structs aren't enough to make me think I'm using something far more advanced than Java.  And since most Java and .Net folks never bother entering the other camp, they don't realize the extent to which this is true.

Ruby is different.  Ruby is not being chosen for political reasons.  The benefit of this is that Ruby folks have actually tried the other two main technology stacks (not to mention python, perl, etc.).  A side effect of knowing all 3 stacks is going to be the amount of "idea borrowing".  As Ruby gains popularity, the Ruby stack is going to grow.  Like it or not, IDEs, build tools, profilers, and <gasp> fRaMeWoRkS are all going to get added.

Ruby, the stack (not the language) is slowly going to bloat just like Java and J2EE did.

There are some advantages to this.  One example is glue.  Glue is necessary to get us corporate consulting folks to use and sell Ruby to our business users.  Java has JRuby.  This was no surprise from the Java camp — the good thing about Java is it plays well with everyone.

Now, the .Net folks have heard the cries of the Java exodus and are working on bringing Ruby to .Net (here, here and here).  This is a great thing.  I just hope they do it right this time, unlike the Java attempt back in the 90s (I still have that Visual J++ IDE I paid for in 1996 to make me weary of that possibility).

Done right, Ruby could be the modern dynamic language of choice with 100% code compatibility between Java bytecode and MSIL (disclaimer: I'm not a compiler expert, and yes, I know how difficult that will be).  Done wrong, Ruby will stay a niche language and Java folks will use Groovy and .Net folks will use Monad as their dynamic language of choice.

Waterfall2006

The waterfall2006 april fools joke is funny, but hits close to home here in Northern Virginia where a lot of IT work is for the federal government — often mandating some derivitive of the waterfall methodology — and iterative is seen as "giving up on design".  The solution is actually quite simple.

The Motive Fallacy

Dave Bock says:

Next time you see someone stirring up some controversy, ask yourself what they might be selling.

Now this is a pretty sure way to commit The Motive Fallacy (a crime against logic).  Just because someone has a motive doesn't mean what they're saying is false. Being aware of motives is helpful but one needs to have other counter-arguments. Questioning motives by itself isn't much of a counter-argument.

The first part of the post is dead on though:

There have been a lot of blogs lately have been predicting the 'death of Java' because of .NET on one side and Ruby on Rails on the other, and there have been a lot of blogs spouting venom back the other way. The truth is much less interesting: This isn't Politics, and it isn't Religion- all of these things are just tools in my toolbox, and Rails can sit nicely beside Java in the tools I can bring to bear to solve a problem a client might be having. Anything else would be too dogmatic for my tastes...

Why I Don't Post Stock Tips Here

The short answer: this is not that kind of blog.  The long winded answer...

After watching the best film of 2005 around christmas, it was time to do some research on what I think the film is about.  Following google links on alternative fuel, I stumbled on a company that seemed "well positioned" called Pacific Ethanol.  Being the end of the year maybe it was time to balance the pension portfolio and buy in.  But I decided it was too quick. I didn't know enough about the industry, which meant I had no idea about the stock's valuation, competition, and other market forces that may affect it.  Sound judgement, right?  Better to setup some high-low alerts, watch and wait.  Here's what's happened since:

US Patent Office to Reject NTP's Blackberry Claim

Today's Nelsonesque 'haha' goes to NTP for rejecting half a billion in settlement money from RIM (angling for more $$$) and then being informed that the underlying patent claim is going to be rejected by the United States patent office:

"The patent owner's arguments are deemed nonpersuasive," said the patent office document [...] "The next office action is expected to be a final rejection of all current claims."

Probably waaaay premature of me, but I couldn't resist.

ex-FEMA Director Becomes Consultant

So I read that the former FEMA director is joining the consulting industry.  (pause for laughs.)  Yep, I'm sure you've read elsewhere by now.  My first reaction was disbelief.  Then I read the part where he's already got potential clients!  *THAT* was depressing.  I mean, ask yourself: if you quit your day job and announced you were starting your own consulting company, would you have clients already waiting?  I thought past experience was everything in this business.  Anyway, I couldn't find the website but a quick WHOIS reveals that someone promptly started domain squatting MICHAELDBROWNLLC.COM the day this story broke.  Good!  I hope he's asking for a million bucks to give up the domain.

Do you have to lie to sell SOA?

I've stopped believing software vendors that promise dramatic productivity gains by making things easier. They just make the easy things EASIER and the hard things even HARDER.

Today, my morning news scan led me to an article on developerworks touting an SOA product with grandiose statements about programming ease. What struck me as disingenuous was the very first statement (Emphasis mine):

The IBM® programming model for Service-Oriented Architecture (SOA) enables non-programmers to create and reuse IT assets without mastering IT skills.

I really want to believe the pitch.  Let's look at history for a second. EJBs came out 5 years ago. People overused them and got burned by complexity.  Now here we are in 2005.  The buzz seems to be that SOA and ESB will be the next big thing.  And it seems like we're starting off on the wrong foot again.  Basically, by lying to people and telling them that SOA can be so easy to develop that you don't need programming ability.  Bad idea!

This development ease pitch, "buy product X because it enables anyone to create software," has been used so many times (MDA, Rules Engines, Component marketplaces, etc.) and fallen far short of the promise that you'd wonder who falls for it anymore. Fact: non-programmers don't want to create IT assets.  They hate IT!  They ran away from programming courses when they were in college.  They hate computers for making them feel stupid.  They have no interest in creating IT assets.  That's why they create IT departments and hire programmers!

Easier is a loaded word

Maybe I'm taking this too seriously, but I have to because the result is a product that makes the easy things easier and the hard things harder.  The easy stuff is what you see in the Powerpoint "demos".  Like, just drag this widget and click that and there's your CRUD application. The hard stuff is when you have the basic stuff done (long after the product has been purchased) and you decide you want to do a 2-phase commit on certain UPDATE operations.  Or the search results need to be in a table that's sortable by multiple columns and only shows 50 rows on a page.  Woops!  Those aren't supported features out-of-the-box!

See, the non-programmers didn't care about 2-phase commit (TPC) or complex table sorting/pagination because they didn't know when these features are necessary. So they' were not brought up as required features.  But now that they're needed, the non-programmer exits the picture and the programmer is asked to come back in.  This is also the point in time that the savings gained from this products' initial ease of use start to unravel.  Each change request that cannot be implemented with an out-of-the-box feature becomes a quest for finding a clever hack.

Now lucky you (you != non-programmer) have to tell your boss to hire the vendor's consulting arm and pay $10,000/week to figure out how to implement TPC and sortinig/pagination with this product.  What's that you say?  You're a badass programmer and think you can code it yourself? Okay.  What if, their APIs are completely undocumented, so anything you figure out is subject to re-write with the next release of the product.  Have fun, rewriting the same hacks again and again!  I've seen this happen.  Basically, what was originally supposed to be an easy software application has morphed into a frankenstein that's actually harder to maintain.

Caveat Emptor still applies

Don't get me wrong, development products aimed at non-programmers certainly have their place (like MS-Access).  A non-programmer can create an app, roll it out, and make quick feature enhancements.  It also helps users figure out what the heck they want the app to really do by having a simple, working prototype to work with.  But the idea only works if you can make an accurate prediction of the shelflife of that app. 

So in short, I hope IT managers read product pitches aimed at making development easier with a grain of salt.  Maybe we should create a word to describe this kind of writing in our field.  In advertising, they call it puffery. Puffery means salestalk that consumers are not expected to take literally.  For examples, just watch The Apprentice.  The donald can't go an entire show without calling something he's selling "the greatest in the world".  That's his catchphrase.  In print ads for software products, I've seen "premier database solution", "leading ETL product" and my favorite "the fastest app server".  All the programmers snicker when they see these.  I just wish IT managers would as well.

Co-workers: Lovable fools or Competent Jerks?

"How do we deal with all the losers we have to work with?"  That was a topic for the panel discussion at the recent NoFluffJustStuff conference in Reston. Everyone had a fun time venting and I didn't think about it again until now.

What reminded me? The June 2005 issue of HBR has a great article titled "Competent Jerks, Lovable Fools, and the Formation of Social Networks" that tries to answer this question in management terms.  The authors conducted a study where people were asked to rate their co-workers along the criteria: competence and likeability.  These were then used to create 4 archetypes:

• Incompetent Jerk
• Competent Jerk
• Lovable Fool
• Lovable Star

The findings?  First, the authors concluded that "no matter what kind of organization [they] studied, everybody wanted to work with the lovable star, and nobody wanted to work with the incompetent jerk."  Okay, we all knew that.  Now, the much more interesting part:

We found that if someone is strongly disliked, it’s almost irrelevant whether or not she is competent; people won’t want to work with her anyway. By contrast, if someone is liked, his colleagues will seek out every little bit of competence he has to offer.

So, according to research likeability trumps ability.  Ah!  I call this the nice guy theory.  If you just show up, put in some effort and go along to get along, most people will label you a "nice guy" and will seek out every little bit of competence in you—even if it's completely lacking.  The bigger the team, the more pronounced the effect.  Ever worked on a huge project with like 50+ people?  There's always someone who does absolutely no work but still doesn't get fired.  That's the "nice guy"!

And now, a disclaimer: by now you may think I'm some sort of prima donna for blogging this.  Well I'm not!  In fact, I'm lucky to have worked in 3 different office environments over the last 2 years where I was fortunate enough to work with cohesive teams with good people throughout.  But if I think back farther, I can come up with a few good examples.  If you've been around or worked in consulting (changing projects means lots of different faces), then you have your own stories I'm sure.

Back to the panel disscussion at the NoFluff conference.  At one point, Dave Thomas mused that we should separate the people who care from the people who don't care.  Which means we should also consider the criteria of motivation or apathy.  Personally, I think apathy is a pretty common problem in software development circles.  When I've seen the symptoms in people, the usual causes are:

• only in it for the money (never really cared to begin with)
• burned out, usually after a couple of death march projects
• corporate re-organizations moved the person into an ill-suited position
• personal problems spilling into work life

I used to care about this issue a lot more on a personal level but after a while I realized that it wasn't an entirely fixable problem, so I shouldn't worry that much about it.  Some people are of the opinion "just quit and find another job".  But I say that's a pretty extreme solution.  After all, your workplace is just a small representation of the real world.

I'm probably going to regret saying this, but I've gotten used to working with different types of people and I don't really get bothered by the 3 negative archetypes anymore—"competent jerk" (work with them, but minimize contact), "lovable fool" (build your workplan to not rely on the person) and probably not even the "incompetent jerk" (try to avoid the person and never take anything they say personally).

Infact, in a way I'm glad for them because they make the "lovable star" stand out even more.   Now, I just can't figure out why everyone isn't a lovable star.  All you have to do is: show deference to those you report to, go out of your way to acknowledge and help those around you, and become really really good at what you do.  What's so hard about that?  ;-)

Update: Read one of the panelists blog post about this topic: Honeypot Projects

What makes a Team Leader?

Have you ever been appointed the Team Lead of a project, without the benefits like a raise, or the authority to hire/fire and make financial decisions?  Yeah, me too.  If you get the other stuff as well, I guess the title would be Project Manager, not Team Lead.  Oddly, on The Apprentice, the title is used interchangebly.  Some places use the title Architect, or Technical Lead or if it's a shrinkwrap products company, Product Manager.

My experiences are based on consulting type projects or Internal Software.  Even though the traits of a Team Leader role differ from one place to the next, these 4 things remain common:

• You get to go to more meetings.
• You have to make decisions that will affect all the developers, and usually the testers and business analysts as well.
• You have to update the project plan or help the financial manager (the one with the real authority, remember?) update it.
• You have to survey the technical landscape (blogs, magazines, books, product specs, etc.) constantly and incorporate useful ideas into your shop's way of doing things.

Ofcourse, there are shops where everyone does these 4 things.  The organizational structure is pretty flat, and everyone's "been there, done that".  People are smart, and get things done.   So if these places have a Team Lead, it's for the sake of ceremony, and the title has less importance. 

Most notably, it doesn't take that much more ability to be able perform those 4 responsibilities.  They just happen naturally to a programmer who's passionate about software development, is reasonably non-introverted, and likes to take a disciplined approach.  You don't need an MBA.  You don't have to be  rainmaker.  You don't have to like bean-counting.   Remember that if your team has a recently annointed Team Leader who won't shutup about his newfound authority.

Which brings me to this funny conversation between Gareth and Tim, from the BBC comedy The Office.  If you haven't seen this, get the DVD [Netflix] or set your Tivo to record it.  Gareth is the Team Leader here.

Tim: "Team Leader don't mean anything mate"
Gareth: "Excuse me, it means I'm leader of a team"
Tim: "No it doesn't. It's a title someone's given you to get you to do something they don't want to do for free - it's like making the div kid at school milk monitor. No one respects it"
Gareth: "Er I think they do"
Tim: "No they don't Gareth"
Gareth: "Er yes they do, cos if people were rude to me then I used to give them their milk last... so it was warm."

I laughed out loud when I first saw that — you have to know the characters and the setting to find it really funny.  But I was also laughing at myself having been both Gareth and Tim in the past.  (Even though The Office is not set in an IT shop like Office Space is, you can still relate to the situations).  You see, being a consultant one just has to be a chameleon and take on the role definitions of the IT shop you're working at.  And remember to not take yourself too seriously, even if you are The Team Leader.   Which means: don't be a Gareth!