The number two developer qualification: Does NOT build from scratch

Posted by Andy Singleton on Nov 11, 2007 6:53:00 PM

I got corrected by people commenting on my last post titled "The number one developer qualification: Can build from scratch".  They pointed out that if you are working with someone who likes to build from scratch, rather than using existing libraries and frameworks, you are wasting time.  That's correct.  I don't want to work with someone who wastes time like that.  A great developer will do research, will select the right tools, libraries, and frameworks, and will find the fastest way to get the new parts of the application done.  In fact, with the increasing availability of open source code, doing this research and selection is possibly the most important modern development skill  Furthermore, this developer will work with others to get other parts of the application done.  So, let's clarify what I meant, and then look at the opportunities and challenges in finding and deploying developers with the critical modern skills of research and selection.

I was making a point about a statistical INDICATOR of future success.  If you are interviewing a good developer, you will almost always find some project that they designed and built alone, without much outside prodding or assistance.  If they can't talk about such a project, there is a high probability that they will not do well in a trial project that requires independent initiative.  You can scan resumes looking for these solo projects and make a pretty accurate first cut about whom you want to put on trial.

So we want to know that you can do it, and furthermore, that you sometimes want to do it.  We do not expect that you will do it next time.  It's usually not a good recommendation for the next project.

When I say "build from scratch", I meant that you are building a new application.  Nobody thought of it for you.  You had to think of what it would do, design the solution, and execute it, mostly by yourself.  Part of this design and execution is selecting the right tools and frameworks. 

In this definition of "build from scratch", it is a very good idea to use as much existing library and framework code as you can find, and only build the parts that you must build to get your idea implemented.  If you were successful, you probably used a lot of existing stuff.  In fact, a solo project has limited scope, so it forces this sort of discipline.

Research and re-use is very important.  According to my well-worn copy of Software Assessments and Best Practices, the most important factor influencing software productivity is "reuse of high-quality deliverables", with a contribution of 350%.  Amazing.  The next nearest factor is "management experience", at 65%.  So even if your manager is an incompetent soul-crushing jerk, you can still get around him with the right tools.  These statistics were gathered in the 90's.  Since then, we have seen a huge increase in the amount and quality of open source code.  You can do search-driven development.  We have more to work with now, and re-use is even more important.  I used to call this "research rather than development."  In the modern world, a little bit of research can substitute for a lot of development.

If this type of research is so important, why isn't it the number one developer qualification?  Why is it number two?  Because it's hard to find.  It's just not a very common trait in the population of developers, even good ones.  If you see it, you should grab it.  But, I wouldn't pass on someone just because they lack this trait.

I got some insight into this situation after I read a paper by an MIT business school professor named Thomas J. Allen titled "Distinguishing Science from Technology" (reprinted here).  Allen divides people into "scientists" and "engineers" by personality, and notes that "many managers of R&D fail to recognize the true differences."   Scientists, by this definition, communicate with a global network of other scientists.  They read papers from outside their own organizational sphere.  They do the type of research into alternatives that we are interested in.  Engineers on the other hand communicate primarily inside their own organizations.  They develop a very specialized knowledge of the software / hardware / etc. that they are working on, and they can only discuss it in detail with colleagues.  This must happen if you are making something complicated.  A complicated device or application has its own language, its own API, that isn't relevant even to people working on a comparable device or application that does the same thing.  The flip side of this level of specialization is that engineers don't do much outside research.  It's not relevant to the thing they are working on.

To do world-class software research and re-use, you need to be an engineer-scientist.  The scientist in you looks at a broad range of technology alternatives, and if necessary, emails the author.  The engineer in you gives you the ability and the inclination to install the software and do a hands-on evaluation.  Hand-on evaluation is very important.  A survey of the literature won't do the job.  And, the pre-requisite of being able to build from scratch is important, because you want to compare what you see with what you would do yourself in the same situation.

So what are you?  Are you an engineer, or a scientist?  My guys sometimes say that I'm not a "real engineer", and by this definition, it's true.  I'm mostly a scientist.

Engineers are getting more adept at research because every engineer has a google search toolbar and learns how to use it.  But I still don't see an engineer-scientist combination very frequently .  And when you are staffing a complicated development project, you need real engineers, heads-down and hands-on, in most positions.  You only need a few of the elusive engineer / scientist research-loving folks to keep everyone else well supplied.  So, keep an eye out for this skill, and grab it when you can.

Topics: development process, staffing

Written by Andy Singleton

Working on Continuous Agile and Accelerating Innovation, Assembla CEO and startup founder

Follow Assembla

Get Started

blog-CTA-button

Subscribe to Email Updates