Peter Williams

Nucleic Teams

A nucleic team is one with small core group of permanent employees, usually just 1 to 3 people, that is supplemented as needed by contractors. The core in a nucleic team is too small to do the anticipated work, even during slow periods of development. The core teams job is two fold, first it implements stories that are particularly complicated, risky or architecturally important. The second role of the core team is to manage a group of contractors by creating statements of work, doing code reviews, etc.

The nucleic structure should provide a lot of advantages from a business stand point. You get many of the benefits of having an in-house development team. Advantages like developers that have the time and incentives to become domain experts. A consistent group of people with which all the stakeholders can build a rapport. A group of people that work together long enough to build the shared vision it takes to create systems with conceptual integrity.¹

Those advantages are combined with the advantages of pure contracting team, at least in principle. The primary advantages of a pure contracting are that you can scale the development organization, both up and down, rapidly and cost effectively. Many organizations with in-house development teams end up having to maintain a sub-optimally sized development team. Work loads and cash flow tend to vary a bit over time. It takes a long time to find and hire skilled developers. Once you do, it really sucks to have to lay people off, either because of the lack of work or lack of money. Resizing development teams is so costly and disruptive that most organizations tend to pick a team size that is larger than optimal for the slow/lean times but less than optimal for the plentiful times.

Risks

This structure is not without it risks, though. Finding talent contractors is not easy. Contractors, by their very nature, cannot be relied on when planning beyond their current contract. Most importantly, though, contracting usually has an incentive structure that favors short term productivity. All of these can threaten the long term success of project if not managed correctly.

To counteract the risks inherent in contract workers the core team must be committed to the business, highly talented and fully empowered by the executive team to aggressively manage the contractors. The core team members must be highly skilled software developers, of course, but this role requires expertise in areas that are significantly different from traditional software development. The ability to read and understand other peoples code rapidly it of huge importance. As is the ability to communicate with both the business and the contractors what functionality is needed. The core team also needs to be able to communicate much more subtle, squishy, things like the architectural vision and development standards.

The core team will not be as productive at cutting code as they might be use to. The core team role is not primarily one of coding. A significant risk is that the members of the core team might find that they do not like the facilitation and maintainership role nearly as much as cutting code. It is necessary to set the expectations of candidates for the core team appropriately. One other risk is that the core team will get so bogged down in facilitation and maintainership tasks that they actually stop cutting code. The “non-coding architect” is a recipe for disaster, and should be avoided at all costs.

While this team structure has much going for it, it will be challenging to make work in practice.

Origins

I think this team structure is developing in the Rails community out of necessity, rather than preference. Rails is a highly productive environment. That can make it a competitive advantage for organizations that use it. However, the talent pool for Ruby and Rails is rather small. Additionally, many of the people who are highly skilled at Rails prefer to work as contractors. The percentage of the Rails talent pool that prefers to be independent seems quite high by comparison to any other community i know of.

This raises a problem for organizations that would like to create an in-house development team using Rails. Most of the talent would rather not work for you, or anyone for that matter. However, if you can build a small core team to manage the development and hold the institutional knowledge for the project you can utilize the huge talent that exists in the Rails contractor community to drive the project to completion.

I am not sure if this structure and the reason behind it are good, or bad, for the Rails community as a whole. The nucleic team model might turn out to be a competitive advantage in itself because it embodies the benefits of both internal and external development teams. On the other hand, it is bound to be a bit off putting for organizations that are not use to it.

Mobile back-end consulting?

During a recent discussion with a friend (hi Brian) i had an epiphany. Well, actually it was just a series of realizations that should have been obvious long ago. The series was this:

1. most mobile applications have a server component
2. web services are the most obvious way of exposing server components to mobile applications
3. therefore, mobile applications are just another flavor of semi-autonomous web service clients
4. mobile applications are a growth space
5. mobile application development skills are very different than good server-side development skills
6. i know a lot about designing, and implementing, REST/HTTP web services to support semi-autonomous clients
7. profit?

That last bullet really does come with a question mark instead of an exclamation. I really like designing web service APIs, and i am really good at it. I am just not sure there is enough of demand to make it worth focusing my career on that space. On the other hand, it feels like it might be a highly underserved niche.

I think that if i am to make a go of this it would have to be as an independent. It seems unlikely that a shop focused on mobile application development would be willing to add the fixed cost of a back-end developer in this economy. That would be a hard sell even to a shop that fully believed that an expertly designed API would pay of in reduced maintenance and lower costs of change over the long run.

So my questions to my readers (all three of you) are: a) Is this an idea worth pursuing? b) Do you know of anyone developing a mobile app that could use a skilled mobile app back-end developer? c) Do i want to go out on my own right now?

Pipes Dreams

As you know, i am on a job hunt. Like everyone else i use a variety of sources to find potential opportunities. I also have a wide breadth of skills so i search on a lot of keywords. Going to 10 different websites and doing 2 to 20 searches each gets old really fast. Worse yet some of these sites don’t have particularly sophisticated search capabilities so you end up having to look at a bunch of information that is not relevant.

So, over the weekend i decided to play with Yahoo Pipes to aggregate and filter all the job posting feeds. Pipes is quite impressive. The UI is very slick. The drag and drop visual connect-the-boxes presentation really puts the user at ease. Creating a basic version of the pipe i wanted was surprising easy. There was definitely some learning to be done but i had a working prototype up in very short order.

Almost immediately i was disappointed in the lack of a textual representation of the data extraction and transformation rules that comprise a “pipe”. Being a programmer by trade i always feel happier when i can use my favorite text editor, not to mention source control, for tasks like these. (You mean you don’t edited text fields in you browser with Emacs? Why not?) However, my wife, an ETL expert, assured me that visual editing is the norm for tools such as Pipes.

Once i started expanding from the initial prototype the dream really started collapsing around me. My pipe had a fairly complex set of filtering rules that i wanted to apply to each of a set of feeds. My initial thought was to extract those rules so that i could reuse them in multiple pipes, each handling data from difference sources. At it turns out, Pipes does not allow that. You can use other pipes as the input to a pipe, which is nice, but you cannot embed one pipes in the middle of another pipe. The inability to create custom reusable transformations is a real missed opportunity.

With that option off the table i decide to create one ginormous pipe that aggregated all the feeds before running their contents through the filters. That works, in principle, though it raised some factoring challenges in my case. (Some feeds required specified processing that other did not.) Once i had constructed my very large pipe i tried to save it, and this is what i got

Which is a little weird because it actually does seem to save when this happens. If i close the editor and reopen the pipe it has the changes. Unfortunately, it cannot seem to run the very-large-pipe reliably. Or at all, most of the time. Most of the time that pipe fails altogether. Sometimes it returns only a subset of the data that it should, but most of the time i get a “Pipes engine request failed (malformed engine data) (2)” error message. Regardless of the outcome, it always takes an unacceptable amount of time to run.

So now i am back at square one. I am faced with creating an expansive set of pipes which are largely duplicates on one another, but without even cut-and-paste reusability. (Did i forget to mention that the pipe editor does not support cut-and-paste?) So if i change my mind about the filtering criteria i would have to go change each of them by hand. I don’t think it would be worth the effort.

So, i guess i will go run my 40 searches manually every day and take the first job that comes along just to make the pain stop. Which really sucks because Pipes has real promise. After creating a small pipe i thought it was pretty much the coolest thing since sliced bread.

Will code for food

I am on the job market again.

If you needs some help exposing your applications functionality via REST web APIs, we should talk. If you need some assistance developing, deploying and managing a Ruby application, I have the skills you need. If you need someone that can learn your code base and your business processes, I can do that. If you need someone to drive improvements to you software development process, I won’t disappoint you.

My resume has more details on my skills and accomplishments. Feel free to pass it around to anyone you think might be interested.

Anathem