Translating “Right tool for the job”


When I hear somebody say “Right tool for the job” I cringe.  The acid in my stomach starts to churn.  My blood pressure goes up.  I just feel like lashing out or screaming.  Why do I get this reaction?  Its a simple, logical statement.  Sounds like great advice, right?  In my experience though, “right tool for the job” is often code for something else.  Its an often used, cliche excuse to hide hidden motives.  So, let me translate for you the true meaning of “Right tool for the job”.

  • There’s this cool fad new language that everybody is talking about.  I’m going to use this new language to implement a new feature even though nobody else on my team will be able to maintain it but me.  Even though the code will hard to maintain because I’ll be experimenting with every possible new feature of the new fad language I’m using. Thus: New language XXX is the RIGHT TOOL FOR THE JOB!.
  • Everybody is talking about this new cool No SQL stuff, but I’m stuck coding RDBMS with Hibernate.  Thus: No-SQL DB XXX is the RIGHT TOOL FOR THE JOB!
  • This job sucks and I need to train myself in a new technology so I can get a new job. Thus: Technology XXX is the RIGHT TOOL FOR THE JOB!
  • My product/project is missing a key fundamental feature that a competing, more mature technology has had for years.  I can’t say that this competing older, mature technology is better, I need an excuse so instead I say: You need to pick the RIGHT TOOL FOR THE RIGHT JOB!

Consultants are even more notorious for this.

  • I need to make myself invaluable to this company so I can keep billing high rates for myself and my underlings.  So, I will find a technology that nobody in this company has experience. Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
  • I need to train a bunch of my new consultants in a new technology.  Better to charge this training on somebody else’s dime.  Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
  • I need to drum up business, sales are lagging.  So, I’ll create a new methodology and pay some Thought Leader to bless the methodology.  Then I’ll get my best speaker to troll all the developer conferences touting this new methodology.  Thus, Methodology XXX is the RIGHT TOOL FOR THE JOB!

Admit it! You see this happening everywhere.  We’ve all done it at least once.  But no more for me!  Just like I want to purge swearing and cursing in front of my kids, I want Right Tool for the Job out of my vocabulary as well.  If you ever hear or see my say this phrase, call me a hypocrite.  Flame me.  Chastise me.  Remind me of this blog!



Worst fans in the league

Leave a comment

New England Patriots Fans Suck!

As a 20 year season ticket holder, in my experience, Pats fans are the worst fans in the league.  They leave early, they are not loud.  They boo the team with even the slightest mistake.  You even get yelled at sometimes for standing up and making noise for the Defense.  The drunken “pink hats” are often screaming Brady’s name when the Pats are on offense.  The worst culprits are the premium seat wusses who empty their seats even it is marginally cold or sprinkling a little.  Seems people are more interested in getting wasted, impressing their girlfriend, getting on the big screen, getting on TV, and/or beating the traffic instead of watching the game.  It sickens me.  The best part of going to the games is that I get to spend time with my father and sister.  Sometime in the far future when he is unable to attend games, I’ll seriously consider giving up my tickets and watch games on TV instead.

That being said, I am ashamed of myself as I am one of these shitty Pats fans.   At the end of the Saints game, we were guilty of leaving our seats after Brady threw his interception in the final 2 minutes.  As we were crossing the bridge, we saw that the Pats would get the ball back, so we ended up going to the standing-room only area in the endzone and watching the final drive on the big screen.  Was still a cool experience, but I wish we had never left our seats.  I WILL NEVER LEAVE MY SEATS AGAIN!  I PROMISE!

NSA’s anonymous spying


I just don’t get the uproar with NSA spying on internet traffic and websites. Most of what NSA is doing is data mining which is inherently anonymous, I can’t see how any of this has anything to do with privacy or freedom for that matter.  Sure, it creates possibilities for abuse, like blackmailing somebody that doesn’t want to come out of the closet or is having an affair.  But wouldn’t strict laws with strict penalties, and strict procedures prevent such abuse?

For example, police need a court order to wire tap a phone.  Couldn’t we just treat the results from data mining as we would a phone?  The program would provide a list of potential suspects.  FBI could check the suspects vs. public records and such, and then go to a judge for a court order to open up the details of the data mining done.  Furthermore, if we have strict laws that prevent the CIA from using this digital spying for blackmail or other shady dealings, other nations wouldn’t have much to bitch about.

Given that we’re in an age of social media where a lot of what we do on the Internet is public knowledge, what’s all the pew pew about?  Google et. al. are already doing this anonymous data mining to provide highly targeted ads.  Why is it more acceptable for Google to do this, than for the NSA to search for crazies that want to fly planes into buildings, bomb marathons or shoot up a school?  For myself, so much of what I do is in the public what do I care if some data mining program is parsing and analyzing my emails?     I also don’t think we’re giving up on freedoms to make ourselves safer.

We must trust in our institutions that they are either benevolent or that there are appropriate checks and balances in place to prevent abuses.  If these checks and balances are missing, its time to legislate them into existence.  I think there is a happy medium where we can make ourselves safer and put the adequate safeguards in place to prevent a total Orwellian society.

Mocks are a Mockery


There were some interesting side conversations going on in the comments of my Java EE wins over Spring blog.  In particular, a few people were arguing over the value of Mocks.  I always considered Mocks a bogus pattern.  Only time I ever use them is when I’m initially starting a project and I don’t have full implementations of a particular subsystem and I need to test that something works.  You see to me, your GIT master branch, or your SVN trunk is a sacred place.  I fully believe in the idea of continuous integration.  But to have a pure Trunk, you have to test your code, as close as possible, to the target environment it is supposed to run in.  Mocks go counter to this idea.  And give you false sense of security.

My colleague, Stan Silvert said it best:

When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.

What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.

The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.

I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.

Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.

Personally, I’m a very paranoid person when it comes to development.  Earlier in my career I did a lot of demos and live coding in front of an audience.  When you’re in this type of environment you live by the mantra that anything that can go wrong will.  So, when rehearsing, you always mimic as much as possible what your setup will be.  I carried this paranoia to Iona (an Irish company), when I worked on Orbix there.  We had a rule, that if even one test (integration or whatever) failed, you were awarded the Guiness Penalty.  If you broke the build, you had to buy every one on the team a pint of Guiness.  IN this environment, Mocks are a waste of time, both in build CPU and in coding time as you still had to run integration testing before you committed anything (unless of course you just wanted an excuse to have a few beers).

So unless a particular integration test is ungodly slow, don’t use mocks.  Stan again, said it best:

…the days of the 2 hour in-container smoke test are over.
Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.

But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.

With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore.

Typical example of why dynamic languages suck


Awhile back I ranted against using dynamic languages like Ruby, Python etc.  Recently, I’ve been using Python as a way to test Resteasy’s SMIME integration.  It was an extremely frustrating experience that would have been much better if Python was statically typed.  Why?  Well, take a look at this documentation for doing SMIME with Python and M2Crypto.  The problem was is that the examples are interacting with Python’s mail API. I needed to be able to send SMIME over HTTP.  So, I needed to understand the M2Crypto API a little bit better.  If you look at the example code, you have no idea which additional methods are available, and more frustratingly, when types of objects these methods return.  The auto-generated javadoc-like docs for M2Crypto were even less helpful.  What I had to end up doing was diving into the M2Crypto codebase to figure out exactly what was going on.

Moral of the story?  Programming in dynamic languages can be a lot of fun.  But when you run into APIs you’re not familiar you’re pretty much at the mercy of the documentor.  If the documentation sucks, you’re pretty much up shit creek and forced to dive into the code to understand what is going on.

Should REST be Organic?


Since our kids were born years ago, my wife has generally been pretty Organic crazy.  The Organic food movement was created so that we don’t “poison” our bodies with food grown and treated with harmful pesticides and chemicals, that don’t introduce dangerous genetically modified seeds or growth hormones, and finally, contribute generally to society as a whole by promoting sustainable farming that doesn’t deplete or damage the environment.

From Movement to Certification

Organic food and farming started out as a movement, but quickly turned into a branding and certification effort.  Many farmers and companies found that following strict organic principles was expensive and added to the cost of the goods they produced.  While many customers were willing to pay the extra cost involved to avoid “poisoning” their bodies, still many others are more interested in saving money now and worrying about the long term consequences to their bodies and environment later down the road.  So, some companies would avoid pesticides, but still use genetically modified seeds, and call their products organic.  Or milk companies wouldn’t use growth hormones, but still use non-organic feeds for their livestock, and still call their products organic.

To fight this pollution and misrepresentation of organic principles a branding and certification effort was introduced so that each product on the market could be officially approved as organic or not.  Organic food customers would know what to expect from a product by seeing this brand on their packaging.  If you wanted to sell organic products, you’d have to be officially certified and inspected by a third party.

Is REST following Organic’s path?

Roy Fielding, the father of REST, has the same expectations that organic food consumers have.  When something is deemed RESTful he has certain expectations that have to be 100% fulfilled.  Its very understandable as Roy deals with Web standards, they have to scale, their going to be used by millions.  The stability and usability of the Web are too important to propagate flawed protocols.  Roy says in his PhD:

While mismatches [to REST] cannot be avoided in general, it is possible to identify them before they become standardized.

So, maybe Roy should trademark REST, brand REST, and promote the creation of an official organization that can bless an application or API as RESTful much like we have an Organically Certified label.  Let’s do a tiny thought exercise on this…

One of the consequences of heading down this route is that REST evangelists will lose the Web as their prime example of REST in action.  While the HTML and HTTP standards and specifications will be a great example of REST in action, most of the applications on the Web don’t follow the strict criteria of REST (a static web page is not an application).  As Roy states, its hard to avoid mismatches in the RESTful style, even if you try.  This is especially true if you’re building a distributed interface for a legacy system.  The rest of us will lose a lot of language and vocabulary to describe our apps if REST is branded/certified.

Well…You may be laughing (or fuming) about the idea of branding and certifying REST.  The thing is though, often, when you interact with the REST community you get condescending comments like:

Then do not call it REST. It is that simple. And saying that some academic has not written a line of code detracts from what you are saying. REST has a clear enough definition. XXXX  (insert whatever here) is not RESTful, so don’t call it so!!

You get this sort of interaction when a thought, API, or interface breaks or bends a RESTful principle AND you want to still use REST to name and/or describe your thing.  Reactions like this is very akin to treating REST as a certified brand rather than a style.

Expectations are just not the same

The thing is though, the expectations of IANA, W3C, and people Roy Fielding are very different than the average application developer.  There’s really two main reasons why a developer initially is attracted to REST:

  • Simplicity.  You can use a RESTful interface without having to define a WSDL document, generate stubs, and download (or pay for) some complex middleware stack or library just to implement a “Hello World” example.
  • “Lightweight” interoperability.  Because HTTP is everywhere, if you write a RESTful interface, it should be usable in most languages and platforms without much effort (i.e. iphone, android, python, Ruby, Java, Perl, etc…)

Sure, there are a lot of other goodies you get when you learn more about REST architectural guidelines and start applying them, but these two reasons, IMO, are the reason app-developers initially look into REST.  W3C, IANA, etc. have different expectations, though, as they are defining standards that the Web will be built upon.  A screwup here can have a much more far reaching affects on things compared to messing up an application that can usually be refactored over time.  The domain REST is going to be applied to should have a direct correlation on how critical we should be of the interface.

Focus on benefits and consequences instead of definition

While strictly following REST works for Web standards, its just not always feasible to follow them religiously in everyday applications.  After all, REST is a style and set of guidelines, not a set of laws or, gasp, a branded certified trademark.  Instead, people should be allowed to use REST to name and describe themselves without harassment.  Instead, critics should focus on the consequences of a specific app or API not following a specific RESTful constraint and the benefits if they did modify the interface to follow the guideline.

I think we’ve all had negative experiences with trying to follow an architectural principle (REST, OOP, or whatever) religiously.  I think most of us realize that focusing on delivery to market through multiple iterations and user requirements and feedback is much more important than whether we religiously follow a specific guideline.  The easy answer is “Then don’t call it REST!”, but we’d have a very limited vocabulary in software engineering if this mantra was followed with every new architectural style that was created.

Freetards vs. Apple


Recently I’ve complained a bit about the righteousness of Apache and, at times,  its negative effect on open source and Java.  Well, recently the GNU Freetards got into the act against Apple.  It seems a piece of GPL licensed software, VLC, was published by iTunes, and one of the original developers of VLC sued Apple to remove it from iTunes stating that the GPL conflicted with the DRM licensing required by anything distributed by the App-store.  It seems that the DRM licensing forbids reverse engineering of downloaded apps, while GPL allows (and encourages) it.

Its the spirit, not the fine print, that matters

The spirit of the GPL, IMO, is that once something is open source, it stays open source, derivative works and all.  If you want to link it with your software, then your software must also become open source.  Denis-Courmont’s beef with Apple is just semantics.  You don’t need to be able to reverse engineer VLC binaries, because the source is available.  You can fork VLC into your own app and post it on the Apple App-Store with no problem.  I’ve also heard that the DRM forbids more than 5 copies of your downloaded binary to be distributed on various devices, which also breaks the GPL.  So what?  You can always download, for free, another duplicate binary.

There are consequences to fundamentalism

The first and obvious consequence to the actions is that iPhone users can’t get VLC anymore, unless of course they have the technical know-how to jailbreak their phones (which the vast majority don’t).  The second is that all the hard work of the developers who created the iPhone app is thrown out the door.  I don’t know about you, but I’d be pretty pissed.  Third, and most important is, does this screw the rest of us developers that want to distribute GPL/LGPL software for iPhone/iPad?  Which pisses me off, because, I prefer the LGPL, and more importantly the spirit of that license, not the fine-print.

I think a better approach would have been to be less confrontational and more cooperative.  For instance, I bet Red Hat and other large companies, if you asked, would be more than willing to officially ask Apple to change their policies to be more GPL friendly.  There are a lot of different ways to pressure Apple, while at the same time, not screwing the rest of us who want to distribute GPL/LGPL based software on iTunes.

This general approach to life that ideals and principle should always trump compromise gets us things like crappy health care bills, deadlocked legislatures, poor union contracts across various industries, and probably a lockout for the NFL season next year.  Hopefully this unwavering/uncompromising idealism that seems to permeate our society as of late is just a fad.  One can only dream…

Hopefully Apple does the right thing

Finally, hopefully Apple revises its terms of use to be GPL, LGPL, and open-source-license friendly.  But, IMO, iTunes and the App-Store is their baby.  Its a privilege, not a right to use it.  (Java falls into the same boat, unfortunately).  Sady, we can’t expect this change to happen.  In the meantime, we probably have to use a different license to distribute open source software on iTunes.  Thanks Denis-Courmont…

Older Entries

%d bloggers like this: