Impedance Matching

leave a comment »

As I’ve moved further into software development consulting, I’m becoming more aware of the role that empathy plays in all client relationships. When a client calls because disaster has struck their software, it is imperative that I match their level of concern. If my level of concern doesn’t match their level then I’ve failed as a consultant. I can deliver software on time. I can estimate projects accurately. I can have technical mastery. If I can’t be in their shoes and convey that state to them then I’m not developing a long-term relationship. Genuinely share in their work by staying on the same page.

Impedance matching isn’t solely about the words that you say or write. Your overall attitude and tone of voice matter too. Additionally, it’s important to recognize the form of communication used has implicit levels of concern and care. Impedance matching is the act of meeting your clients social attitude, orientation and behavior to maximize communication transfer and minimize problems with the client.

In my realm of work receiving messages often occur via instant message. Unfortunately, instant messages are easy to overlook and relay little context. Receiving a message that says “the server is down” can mean hundreds of different things. Most of them require a simple reply, “I’ll take a look.” Receiving a message that says “SERVER!! DOWN!!” means that the instant messaging needs to stop. While the client is choosing to use instant message the amplitude of the conversation is far beyond any instant message can convey appropriately. Pick up a phone, their impedance demands it.

How I communicate over instant message changes drastically with each client. Most of the time, I think it is best to adopt whatever format the client uses. If they write in complete sentences with capitalization and punctuation then I meet that formality. I let them set the stage for professional communication.

As consultants we want our clients to have positive feelings about us. We want the work to be collaborative instead of adversarial. We need to bend our thoughts and actions to meet theirs. As consultants it is our job to be in their shoes and earn their trust.


Written by syntatic

April 28, 2008 at 8:32 pm

Tools in the Studio

with one comment


Obtiva’s Studio is busy churning out projects and I thought it would be good to let the rest of the world what we are up to. Most of our rails projects are now using CruiseControl.rb, Zentest, restful_authentication, gems, query_trace, attachment_fu, Rcov, redgreen, exception_notification and mocha. While the list may seem long we are always looking for new tools. If you have any suggestions please comment.

As a team we’ve setup growl integrations for cruise, autotest and redgreen which is strongly suggested. Make TDD easier for yourself. As a team we really need to put out a tutorial on how to set all of this up properly. In my opinion you are doing yourself a disservice without them.

A quick side note, grep -r is mostly dead around here due to ack. Try ack, you’ll love it.


We’ve also pushed a lot of our interest into JRuby and Erlang. We are all extremely excited for the opportunities those two tools will provide. JRuby’s memory usage have our mouths drooling. If you are not paying attention to Charles Nutter’s blog you are missing out! The pace of everything surrounding JRuby is astounding. Merb and Sinatra are on our radar.


Joseph Leddy is deep in the bowels of ActiveWarehouse and FasterCSV where he is making millions of SQL rows consumable for our clients. Joseph is also exploring ETL Tool. He’s been aggressively implementing state machines alongside access control also. Tools unique to Joseph are query_analyzer and tail_logs which I’m eager to take a look at. Joseph recently implemented some multi-server file uploading using BackgrounDRB with tests!

Nate Jackson’s work involves sphinx via acts_as_sphinx mashed into will_paginate and aspell. He’s created an intelligent word suggestor for misspelled words and phrases using raspell. Nate spent a day or two scraping the web with hpricot, WWW:Mechanize , csspool and sass. Nate’s also pushing the studio into NetBeans for Ruby, RSpec, Dvorak and Leopard. Nate likes to include svn_tools and dot.rake in his projects.

Dave Hoover‘s working on innovative interfaces with Ajax and BackgroundDRB. Dave has picked up AR::Extensions as a hammer for memory and speed intensive ActiveRecord imports. He’s also weaving together fleximage and attachment_fu in a few projects. I don’t know much about it yet, but Dave seemed please with ZIYA and Flash chart delivery. Dave’s spent some of his time plunging into Sinatra too. Dave’s editor of choice is Textmate. Other things in his camp include: liquid, RedCloth, and chronic.

Dave also released a gem called TamTam using hpricot that will inline css. You can find the gem here. Dave and Nate paired up to create Obtiva’s first OS X widget here. I paired up with Dave to create a rails plugin for TamTam too which is named inline_css.

Ryan Platte has put together some sweet mashups with GWT, AIM Presence API, BackgrounDRb and ActiveScaffold. While Ryan wasn’t a huge fan of ActiveScaffold I was impressed. His editor of choice is rails.vim. For testing he is using UnitRecord to speed up his test suite among its other benefits. Ryan is now promoting the use of factories over fixtures. Ryan and Gareth demoed Ruby Prof to the rest of the studio. Ryan introduced me to the wonderful world of GNU Screen. The little exposure I’ve had to his projects has me very impressed.

Gareth Reeves is doing work in Event Driven Architecture and Event Driven Programming. He introduced me to testing Java with jMock.

I’ve been working with Amazon ECS, Streamlined and a session bridge between rails and Perl’s CGI Session. I strapped subdomain/SEO love onto a project using request_routing, url_for_domain, and acts_as_sluggable. Nate and I pulled ActiveMerchant into a project which was much less painful than expected. If you’re doing complex condition building my tool of choice is condition_builder. I also extended restful_authentication so that it can support authentication for multiple types of users.

Written by syntatic

November 30, 2007 at 9:42 am

ruby on rails: merge! ‘params’ with a hash indifferently

with 3 comments

When using a merge! with the params method key value pairs are not clobbered if the calling hash is using symbols as keys.

If params[:colors] contains:

params[:colors] = { "blue" => false, "green" => true }

and sym_hsh contains:

sym_hsh = { :blue => true, :red => false }

a merge! of the two will result in this:

=> { "blue"=> false, :blue => true, :red => false, "green" => true }

Notice the duplicate blue key and mixed key types. Some are symbols and some are strings.

Using rails you probably haven’t run into this problem much. Behind the scenes in most of rails hashes are made indifferent to key type. Indifference protects developers from running into problems with strings and symbols as hash keys.

The rails code base uses the class HashWithIndifferentAccess allowing hashes to use strings and hashes interchangeably.

When creating new hashes in a rails project it is best to avoid the problem alongside rails. You can do this by creating hashes two different ways:

hsh = :blue => true, :red => false)

or this which does the above for you:

{ :blue => true, :red => false }.with_indifferent_access

Now the merge! will clobber :blue instead of appending another :blue key.

Written by syntatic

November 28, 2007 at 10:01 pm

Posted in programming, rails

Education Level

leave a comment »

June of 2007, I spent a week in Alabama with Jenna and 25+ high school students from student body. The town we served – Boligee, Alabama – is radically different than my hometown of Wheaton, Illinois. In the last ten years, the educated and the “wealthy” have abandoned it. A dying town in a dying county, many are left without hope or any vision for the future. In Boligee the median income for a family is $16,146 where it is $104,475 in Wheaton. Boligee doesn’t provide opportunity like the suburbs here do and it certainly doesn’t educate like our system does.

This experience reminded me of how much I’ve been given. I’ve been blessed with more opportunity than I can imagine. My high school education rivaled many college programs and I was able to attend an excellent college to top it off. I’ve come away from it all with little debt and a host of options for my future.

One night, it hit me: God doesn’t care how educated you are. He doesn’t require you to be educated to follow him. You can be the most educated person in your country and it doesn’t make one bit of difference when it comes to godliness.

During my stay in Alabama, I took a long hard look at the fruits of the spirit – asking myself what impact education has on them. Does it take a college education to love? Or a high school degree to have joy? Do you need a Ph. D. in peace to attain it? Does patience require a high SAT score or kindness demand an above average GPA? Do goodness and faithfulness require literacy? What impact do grades have on gentleness and self-control? The truth behind these questions humbles me. I hope that everyone has a chance to be humbled by them.

Written by syntatic

November 28, 2007 at 8:30 pm

Posted in christ, family

Get In Over Your Head

leave a comment »

Today was spent weaving a sabotaged rails project back together. Usually, I would tell you all the gory details but I’m a little concerned. I enjoyed the experience. Actually, I did more than enjoy the experience. I was in ecstasy all day. Today was the most enjoyable work day I’ve had in a month or two, but why?

Being unchallenged or on the same project everyday causes me to lose hope. I would venture to guess that your job is the same way. If you are a developer then I know your job is that way. Any self-respecting developer hates to be bored. We hate any work day that we do not grow by learning something new. As a developer few things are worse than being stagnant.

Everything that I did today was fresh. I advanced my abilities as a developer and rescued a poor abused rails app from being replaced by static html. The horror! I was in an environment I’d never been in before and was probably in over my head. I loved it. It felt like I kicked the crap out of whoever left rails and the server in that state of affairs.

From now on, I’ll be fighting for another opportunity to jump into some totally screwed up project where I get to throw a few punches again.

Written by syntatic

August 23, 2007 at 6:01 pm

Posted in programming, rails

Basecamp to Google Spreadsheets

with one comment

After a few months with Obtiva, I’m still happy and I’m bursting at the seams to write about all of the developments happening internally. One development that I can’t keep in is our switch to Google Spreadsheets with a few of our clients.

Traditionally, we’ve used Basecamp for client facing project management. For some projects Basecamp is a wonderful tool. If your client is technically savvy then Basecamp is fabulous, but many of our clients aren’t Web 2.0 compatible. As beautiful as Basecamp’s interface is some of the finer parts are not intuitive to someone who thinks in terms of Web 1.0. The technological rift that Basecamp created was a problem because it required our clients to think and live in our webish world. For some of our clients, who are baby steps beyond e-mail, a draggable editable list is inconceivable. They were intimidated by the complexity and I began to notice the number of days since last login rise past days and weeks until the last login was about a month ago.

Meanwhile, I was using the Stylish Firefox plugin to change some of the terminology that Basecamp uses. I like to think in terms of iterations instead of milstones and the word ‘To-Do’ doesn’t give enough context for an act of work that needs to be done. Our client also had some domain specific language that was causing problems. I was hoping to ease the mental translation that happened every time I logged into Basecamp and keep the language of our projects ubiquitous

As Basecamp usage died, conversations that could be posted in the messages section of Basecamp were being sent directly via e-mail and a client shared an excel spreadsheet that contained all a punchlist of work that should be in Basecamp. Dave uploaded the spreadsheet so that we could all edit the document and suddenly we were working on the same page as our client. I think it’s important to meet clients at their technical level. Thankfully, this client displayed their level of technical expertise perfectly. Spreadsheets.

In the corporate world, the interface overhead with spreadsheets is extremely low since everyone expects the spreadsheets to define themselves in the same way through names columns, rows, and some data. Sales representatives, financial advisors, CIOs, and secretaries can all read and edit spreadsheets with ease. Since our clients are comfortable with spreadsheets they are far more willing to share them. We found out our project spreadsheets were being opened up at many desks around their office. Internally our client used the spreadsheets for project planning meetings and progress meetings. With the documents available to everyone, our work became visible throughout their entire company.

Collaboration is the place where Spreadsheets shine the most. Once the right people have access to the document all at the same time the feedback loop becomes short. Briefly, I’d like to share some of the techniques I’ve used to increase productivity and communication. Take a look at this quickly made demonstration template since we’ll be running through the columns.

Story Spreadsheet

I use On to indicate which part of a project I’m currently working on. When I start a story, I make the On cell green so that our clients quickly spot what I’m working on. Using color instead of words makes glancing much easier for them.

Description and location set the context of the story.

Rank is used by our client to indicate what should be done next. Usually the first story on the list is most important, but our clients have multiple people deciding on the order of importance. Rank gives me the ‘official’ next story while they move stories around.

Difficulty is a quick estimation of how hard the story is when technical difficulty and time to completion are considered. When a new story is on the list I give it difficult so the client can rank with that information.

Completed is filled in the moment the story is done and then I turn the story light orange once that story is deployed to production or staging.

Questions and Answers are a quick way for either party to get details straight. When a new question is entered we highlight it until the other party answers and removes the highlighting.

Iterations are inserted between stories and take up an entire row, which we color light blue to match the Google theme. Matching the color makes it easier to focus on the current iteration.

So far, these few columns with a little color thrown in have a few of our customers feeling like they know exactly what is happening and they are much happier due to that knowledge. The difference between our simple spreadsheet and Basecamp is night and day and I thought you might benefit from that knowledge

Written by syntatic

July 24, 2007 at 10:28 pm

Posted in obtiva, process

Craftsmanship as a Bridge

with 8 comments

As a third grade teacher, my wife has an instant connection with anyone she meets. She can captivate anyone for endless hours with the thousands of stories her classroom provides. People want to know what we are teaching our children, they want to know if there is still a smelly kid, and if the schools still teach children how to play The Oregon Trail, which they do. For most, talking with my wife is a nostalgic experience.

As a software developer, I generally get blank stares and questions about how to fix some problem caused by a website that was accidentally visited. Few people feel nostalgic when I explain what I do everyday in front of a computer. A year ago, conversations about my job never developed or bloomed since I couldn’t bridge the gap from what I do into their lives.

Thinking and speaking about software development in terms of craftsmanship has bridged that gap for me. It gives non-technical people a door into understanding what I do everyday. It even has me excited to talk about software development with friends and family. Treating my job as a craft or a group of skills that are artistic practices draws needed parallels to other disciplines.

Usually, I explain how blacksmithing and programming correlate. Both crafts start with very basic materials iron ore and data. Blacksmiths smelt the ore and combine it with an alloy which determines the properties of the metal. Programmers data cleanse and apply a data type which determines the properties of the data. The two disciplines are heavily dependent on strong tool sets also. Wikipedia has an interesting tidbit concerning a blacksmith’s tool set:

Over the centuries blacksmiths have taken no little pride in the fact that theirs is one of the few crafts that allows them to make the tools that are used for their craft.

The same can be said for software developers since the frameworks, scripts and commands used to build software are made up of software. However, the greatest parallels between the two crafts do not come from similar processes.

I find that the biggest eureka moments when talking with non-technical people come from the connotations of blacksmithing. Software is forged. Applications are bent, punched and hammered into shape. Different programs are welded together seamlessly. Before delivery everything must be hardened and tempered. The process is dirty and it is hot. The final product is sculpted to be both aesthetic and functional. The emotional associations the previous sentences draw upon are foreign to most when thinking about software development.

One context non-technical people discover is that blacksmiths are rare now and the craft is archaic. Shouldn’t it be more related to the assembly line or some other post industrial revolution set of practices? No, software development began in 1940 or later. Relatively speaking, the discipline is not that old. Today’s view of blacksmithing describes the current state of software development. A quote from a well known programming book applies here:

One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today’s civil engineers, while our craftsmanship will still be honored. —The Pragmatic Programmer, Dave Thomas and Andy Hunt

There is so much untapped potential that lay ahead.

Another context that I usually bring up is that of apprenticeship or more specifically craftsmanship. At the studio we follow a system of apprenticeship that is similar to craft guilds which were common when blacksmiths could be found in every town. We regularly share new practices, techniques and tools as we refine our craft together. Our job descriptions and roles mimic those of apprentice, journeyman and master also. If you’re more interested in software development as craftsmanship here are some good places to start: the next big thing, software craftsmanship.

One final side note, I’m beginning to read more about software development as an artistic medium. Few non-programmers realize how much computer languages mimic human language. Computer languages have verbs, nouns, grammar, and hundreds of other syntactic structures that parallel human languages. Programming can be a poetic experience when a few lines of code are succinct and powerful. If you’re more interested in programming as poetry join me and take a look: The Poetry of Programming, Diving for Perls – the poetry of programming, Programmers as Poets.

Written by syntatic

July 13, 2007 at 12:15 am