Ronin, a samurai with no master

Dispelling the rumor that Consultants are Mercenaries

I have been speaking with possible customers a lot lately and given my non-traditional sales technique I am noticing a very admirable trait in my possible customer-base. They seem to have a really bad perception of external vendors for some reason. I have heard plenty of references to “Hired Guns” or “Mercenaries”.

First, lets point out that a Mercenary is “(of a person or their behavior) primarily concerned with making money at the expense of ethics.”

Yikes, that sounds a lot worse than I thought. I always had the thought that Mercenaries were hired to work alongside another army to fight on behalf of their goals in exchange for money. That’s not to say that any team of mercenary fighters may not agree with the cause, and thus may choose not to fight. So the statement above about the expense of ethics is simply not true in all cases.

Neosavvy is not made up of mercenaries. We care deeply for software engineering practice and strive to choose projects that we believe in when participating. I do understand how this perception that vendors in general are just out to make a buck off your development budget, however I’d like to counter that fear with some of our goals.

When we take on a project here are our goals

  1. Establish some best practices, and strive to get the embedded development team to buy off on them or collaborate with us to establish them.
  2. Always strive to keep ourselves replaceable
  3. Leave the project in a better state than when we found it

Best Practices

Some common best practices we are always pushing on our customers (many of them have had them without us) are Unit Testing, Integration Testing, Automated Testing, Identifying and simplifying Design Patterns, and Consistency. These aren’t ground breaking, they hopefully are just good common sense for software engineering practitioners. We are however vicious about our implementation of these processes and many of them are rarely open for debate in our engagements, at least among ourselves.

Replaceability

We are always striving to make a key contribution, but in no way is our goal to introduce more complexity than can be understood by the team taking over the reigns. We always want to make sure that our team members are intertwined with our customer’s full time engineering staff. We consider it a measure of great project success when we can build a feature along with the engineering team of our customer and ensure that they take over the maintenance of that feature when we are done. If we can exit the project, and meet with the team in six months to find they are still using many of our patterns and processes we know we have done a good job. It is with these implementation projects that we have had the most success, and additionally been requested to return and contribute on future engagements.

Leave No Trace

When someone is backpacking through any of our country’s state or national parks, it is the goal of that backpacker to leave no trace, and leave the land better off than he or she found it. We are constantly trying to improve the code quality and leave no trace that there is a difference between any team member contributing to the code base. We believe that we should leave behind a code base that is indecipherable from one contributor to the next in terms of style, approach, and solution. We obviously want to leave an impact, and make a contribution that exceeds our cost in terms of value provided to the team, culture, and product we work on, but we want to make sure it appears as though all team members contribute in a similar consistent way.

Bottom Line

Neosavvyians are not out to maximize profits at the cost of ethics. We care deeply for our trade as software engineers, and want nothing more for our projects that we contribute to except to see them thrive. We are running a business, and in so doing we are selective about what we will work on, but ethics are a factor for us.