The Farr Side

Working with Recruiters

Eric Farr — Thu, 04 Nov 2010 11:51:38 +0000

Where I work, we needed to add some capacity to our product development team. It was a short term need that could have turned into a long-term need if things go well. We were looking for a contract developer for a three to six month contract. Sounds easy enough, but there were some complicating factors:

In order to help with the short term need, we had to get the person in pretty quickly.
We’re didn’t have a lot of time to devote to recruit someone.
Our current team is very effective.

The first two items are typical of any team needing to increase capacity. Item number three is where it gets interesting.

When I say that the current team is effective, I mean that we get a lot done, we enjoy the work, and we enjoy working together. We believe that the product and the codebase is getting better with each sprint.

I attribute this to core values we have as software developers:

agile: We believe in deferring decisions to the last responsible moment to keep our options open and to be able to adapt.

object oriented/domain driven: We start with the domain concepts and the object model and not the database. We’ve leveraged NHibernate on the server and object serialization on the device to eliminate buggy hand-coded SQL.

software craftsmanship: We view software as a craft to be mastered, not by learning a new technology like WCF or WPF, but by developing sound judgment and applying the basics like those expressed in the SOLID principles.

XP/Scrum: We embrace the engineering practices expressed in eXtreme Programming: collective code ownership, continuous integration, pair programming, and automated testing.

The developer we add to the team must already value these things or must adopt these values to work effectively. A developer arguing to implement a stored procedure on the next feature because it would be more efficient (whether right or wrong) would be counterproductive. Someone opposed to pairing on tasks would reduce the team’s energy and be a distraction.

The first problem is that it is difficult to communicate the values that make our team effective to a recruiter that doesn’t have the context.

Recruiters tend to fall back on what they know… more experience and greater sense of leadership is better. This leads to a paradoxical problem: the more experience a developer has and the more leadership he has shown, the more important it is that he (or she) be a fit for the team. Less experienced developers are 1) more moldable and 2) less responsible for their experience.

The Advantage of Inexperience

Less experienced developers tend to be more open to learning new skills and adopting new values. The good ones recognize that they have a lot to learn—both in techniques and what fundamental values lead to better software.

Less experienced developers also tend to have less control over the the technology and methods they use on the job. They often don’t know what to look for in accepting their first job or two and don’t have the influence to change the direction once they get there. So, I hold less experienced developers less responsible for their lack of experience with object oriented, domain driven technologies and insistence on agile methods.

The Burden of Experience

Developers with many years of experience tend to be the leaders within their teams and organizations. They are the ones who drive the technical decisions and shape the values of their organizations. Because of this, we have a higher expectation that these developers are experienced in the techniques we use and hold the values that we hold. If they don’t, it is mostly likely that their convictions are more settled and they are much less likely to change.

Communicating to Recruiters

Evidently, I was ineffective in communicating this idea to the recruiters who were helping us. Recruiters continued to send people to us touting ten years of SQL Server stored procedure experience or any combination of Microsoft technology TLAs. I don’t think they understood what I meant when I would said that a particular person had too much experience (of the wrong kind).

So, I brainstormed with the team and tried to spell it out with a diagram that looked like this:

I thought maybe the picture would do what the thousand words hadn’t. No such luck… I had to explain the chart to guys on the team; so, there was no way this would help the recruiters. Undaunted, I made one more attempt, this time with a simpler drawing:

I thought maybe this “magic quadrant” style graphic would work better, but consensus was that it still didn’t make it simple enough.

So, I gave up on the conceptual approach, and boiled it down to some questions, based on the years of programming experience the person has.

For developers with 1 to 4 years of experience, only one question:

Would you like to work on a agile team?

I went on to explain that we think a less experienced developer will adapt to our style of working if he/she is interested in learning the way we do things. We also think it will be very valuable and marketable experience.

For developers with 5+ years of experience:

What are the SOLID principles and why are they important?

What are three principles of Domain-Driven Design?

What does CQRS stand for?

What is your favorite ORM and why?

What CI tools have you used?

The candidate should be able to answer at least 3 of the 5 questions without hesitation. Someone without the experience we are looking for will probably not recognize the terms and won’t be able to answer them.

The idea was that an experienced developer who does not embrace the agile/DDD approach would not be familiar enough these terms that are peculiar to that world to answer the questions. The answers themselves are not that important (anyone does not use them won’t be able to interpret those answers, anyway), but familiarity with the terms indicates that we should talk to the person.

Because of some short-term issues, we put off the hire. I am hopeful to give this approach a try soon, though.

Developing for Android on 64 bit Windows 7

Eric Farr — Fri, 23 Jul 2010 18:01:27 +0000

The instructions on the Google site for setting up for Android development within Eclipse on Windows is pretty good. However, there are a few things to watch out for (as of today, July 23, 2010):

Stay away from Eclipse 3.6. The Android Plug-in does not fully support it.
Choose the 64 bit Windows version of Eclipse 3.5 (SR2) classic.
Choose the 64 bit version of the JDK 1.6 update 20. There are reported problems with update 21 and Eclipse.

Raising The Bar: Manifesto for Software Craftsmanship

Eric Farr — Tue, 20 Jul 2010 15:51:01 +0000

I’ve long been a fan of agile software development as crystallized in the Agile Manifesto. However, I’ve also felt like the core tenants laid out there are too vague to help software organizations actually be successful. I’ve recently learned of (and signed) the Manifesto for Software Craftsmanship. It is still short on details of how to do it (as I guess any document of this nature must be), but I think it is a nice raising of the bar of the original manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Bob Martin does a great job expanding on it in this Software Engineering Radio interview.

Shout Out to Doxygen

Eric Farr — Wed, 07 Jul 2010 00:45:52 +0000

Software Architecture is largely a matter of communication. One big area of communications is documenting a library, whether for internal or external consumption. It is well-known that written documentation goes out of date the minute you publish it.

The only hope of keeping the documentation up-to-date is to have the it embedded within source code it is illuminating. This allows you to update the doc as you update the code. The Javadoc and C# XML comments are good for this, but don’t give you a good way to provide anything beyond documentation of classes and methods, which often falls short in properly documenting a library or code base.

Doxygen is a capable, open source library that combines the comment-based documentation with a full mark-up language that allows you to add text, diagrams, pages, sections, lists, etc. that allows for robust documentation.

Some of my favorite features include:

Auto-generated class and collaboration diagrams
The ability to include hyperlinked source
Compiled Help format
PDF format

Update Route Tables on Windows Mobile

Eric Farr — Wed, 03 Feb 2010 15:58:53 +0000

Our dev team needed to do something that, evidently, very few people need to do… update the routing tables on a Windows Mobile device that is simultaneously connected to both WiFi and the wireless carrier. Internet searching was very little help, but we eventually stumbled across a nifty little shareware app called PocketLAN by z2 Software. If you are doing any advanced networking on a Windows Mobile device, PocketLAN is well worth the $14.99.

A Nifty Extension Method for Mapping Property Values by Name

Eric Farr — Mon, 08 Jun 2009 22:30:19 +0000

Here is a nice little C# extension method that allows you to copy all of the properties from one object to another where the names match.

SetPropertiesByName(this object target, object source)
{
PropertyInfo[] sourceProperties = source.GetType().GetProperties();
PropertyInfo[] targetProperties = target.GetType().GetProperties();
foreach (PropertyInfo targetField in targetProperties)
{
PropertyInfo sourceProperty =
(sourceProperties.Where(f => f.Name == targetField.Name)).FirstOrDefault();

if (sourceProperty.IsNotNull())
{
targetField.SetValue(target, sourceProperty.GetValue(source, null), null);
}
}
}

The usage looks this…

foo.SetPropertiesByName(bar);

I was using AutoMapper for this, but it was overkill for what I needed.

Desktop Developer’s Introduction to Compact Framework Development: Part 4-LINQ on the Compact Framework

Eric Farr — Mon, 08 Jun 2009 22:30:05 +0000

LINQ (Language-Integrated Query) is supported on the Compact Framework. However, like with every other technology on CF, there is stuff you might that isn’t there. In my case, it’s LINQ to SQL. System.Data.Linq is not provided on the Compact Framework.

Also, contrary to some reports, the Entity Framework 3.5 is not provided on the Compact Framework, either.

Referencing a File by Relative Path with T4

Eric Farr — Fri, 05 Jun 2009 17:43:22 +0000

This was way harder to figure out than it should have been, so for the next person that needs to reference an input file in a T4 template by its relative path, here is what you need to do…

1. Include T4Toolbox.tt…

<#@ include file=”T4Toolbox.tt” #>

2. Add hostspecific=”True” to your template setting…

<#@ template language=”C#” hostspecific=”True” #>

3. Import EnvDTE…

<#@ import namespace=”EnvDTE” #>

4. Now TransformationContext.Host.ResolvePath(“SomeFile.sdf”) will return the absolute path of “SomeFile.sdf”.

Domain-Driven Design Friendly Persistence on the Compact Framework

Eric Farr — Mon, 13 Apr 2009 11:27:48 +0000

I’ve been searching for a persistence tool that will eliminate the hand coding of our basic CRUD operations. I’m looking for something that allows us to develop our domain model in plain, unencumbered C# classes, and later persist them to a data store. Ideally, I’d like to use the same tool on both the Windows Mobile devices and on the server (just so we don’t have to learn two different tools or frameworks). This is the story of my pain…

NHibernate – The first and obvious choice for DDD-friendly persistence in .NET is NHibernate. It is a true object-first ORM and seems to have a lot of interesting tooling growing up around it. Alas, NHibernate is not supported on the Compact Framework because of some unsupported reflection it uses.

LLBLGen Pro – Developers who use LLBLGen Pro seem to love it. It is supported on the Compact Framework, but LLBLGen will not support an object-first approach until version 3.0 which won’t even beta until the end of Summer 2009, which is way too late for me.

Entity Spaces – Entity Spaces is yet another commercial database-first ORM that runs on the Compact Framework. I don’t see anything that it offers that LLBLGen doesn’t offer.

Entity Framework – Entity Framework is supported on the Compact Framework and is free but does not support any kind of POCO, object-first approach.

db4objects – db4objects was an extremely intriguing option. I had never considered using an object database before. I found db4o extremely easy to use and intuitive—perfect for the lightweight storage needs we have on handheld devices. However, db4o is offered under a GPL or commercial license. The GPL license won’t work for us and the commercial license is orders of magnitude more expensive than a tool like LLBLGen or Entity Spaces.

Given that having our developers write all of the database access code by hand is (in my opinion) too time-consuming and error prone, I’m left facing some sort of compromise approach.

One option is to create my domain model as I need to, ignoring persistence. Then, within my repository implementation use a data-first tool, treating the “entities” generated by the persistence tool as DTOs and manually translate them into my true domain objects.

The second option is to again model the domain, but attempt to back into the code we need for those objects using a tool like EF or LLBLGen. The Patterns and Practices guys seem to think this approach is true to the DDD concept (see this article). I’m not sure I agree.

I think I’ll give a go at the second approach and fall back to the first if I see that the database schema, and not my domain, is driving the conceptual creation of my object model. I’ll also have to figure out whether to use LLBLGen or Entity Framework. EF is free, but LLBLGen is more mature and may offer a better option in the next version.

Desktop Developer’s Introduction to Compact Framework Development: Part 3-C++/CLI on Compact Framework

Eric Farr — Thu, 29 Jan 2009 22:07:59 +0000

It may seem like a waste to have a whole post dedicated to a feature that isn’t there, but knowing this fact would have saved me some wasted mental effort and disappointment.

The Compact Framework is necessarily small. Microsoft only puts functionality into it that developers will be likely to actually need. This means that a lot of stuff you’d like to be there isn’t. This also means that you might need to interoperate with native code to do some of what you want to do.

If you are like me, this means you would like to use C++/CLI (the old-school .NET technology formerly known as Managed C++) to do that interop. You, like me, would be sorely disappointed. C++/CLI is not supported on the Compact Framework, and as far as I know there are no plans to add it. Prepare to P/Invoke.