No More Ninjas

Movie ninjas are awesome with the kicking, punching, jumping, etc. Code ninjas are unwelcome on my team.

Let's take a brief look at the characteristics of the ninja:
  • Ninjas have great skill
  • Ninjas work alone
  • Ninjas are stealthy
  • Ninjas use unorthodox tactics
  • Ninjas are specialists in espionage, sabotage and assassination

Great Skill - That sounds like what I want in members of my team, provided of course that it doesn't come with Great Arrogance.
Working Alone - Uh oh. No thanks. I want people who collaborate and act as a team. Paired programming for a large portion of the day is a must.
Stealthy - I really don't want anyone sneaking around in my code. I want clear names and explicit abstractions. Make your movements obvious. Create work that you are proud to sign (and then sign it on check in, not in comments.)
Unorthodox Tactics - I liken this to creating your own ORM or web framework. Sure, there may be advantages sometimes, but these are most often outweighed by the constant maintenance work required on the framework, not to mention the requirement that you train new developers not just in the domain, but also your nonstandard tools.
Espionage, Sabotage and Assassination - When I get into a code base that has been written by ninjas, I often feel like they must have been spies from a competitor come to sabotage the code. The code written by these ninjas is full of traps and tricks and kills productivity.

What I want on my team are Samurai. A Samurai follow a code of conduct that emphasizes the following:
  • Martial Arts Mastery
  • Loyalty
  • Frugality
  • Honor

Martial Arts Mastery - Skill mastery is definitely something desirable for team members. Like the Ninja, the Samurai focuses on constantly improving his already formidable skills.
Loyalty - Who doesn't want loyal team members? These are the guys who treat each other with respect and who will work together to complete the tasks at hand.
Frugality - With regard to code, I like to think of frugality in the terms of good architecture. This means minimizing the number of classes, methods and abstractions while still expressing all of the necessary concepts of the domain.
Honor - This means always doing your best. Do what is right for your team and your code even when it is hard. Write your tests first even when you're under a deadline. Remove duplication even when it's hard. Complete the highest priority tasks first, even if others seem more fun.

Anyway, please try to be less of a ninja and more of a samurai.
As for Rock Stars, if the perks of your job don't include an unlimited supply of illicit drugs and slutty groupies, you are not a rock star! KTHXBAI!

Comments

  1. UnknownAugust 31, 2011 at 10:24 PM

    I may link directly to this post when getting such job listings sent my way. :)

    ReplyDelete
  2. Dave AdsitSeptember 1, 2011 at 10:12 PM

    LOL! I hope it helps, Mike. Ninja is the new cowboy in my experience and I hate it.

    ReplyDelete

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more