Hiring Solution Architects!

Like many platform companies, PayPal has many strategic partners. Important partners come with their own requirements, often expressed as desired tweaks to core logic in multiple domains.

Needless to say, directly, programmatically implementing such tweaks across multiple domains would result in brittle, poorly maintainable code. The challenge is to ensure that there's enough flexibility in the key domains to support plurality of partner requirements without creating cruft/adding technical debt to the overall system.

This is best accomplished by technical solution architects on one hand working with partners to help shape their requirements against the fundamental rules and assumptions of the platform, and on the other hand, working with core domains comprising this platform to ensure enough flexibility is built in to support these requirements.

I'm currently looking for highly qualified individuals to fill the role of solution architects. Since all comments on this blog are moderated, you can apply by commenting on this post (I will not make submissions public).

People, Process & Org structures

Perhaps I'm biased by my start-up experience, but I strongly believe that having the right talent in the critical roles is the most important enabler of consistent, successful execution.

To put it another way, having the very best process and well-thought-out org structure in place will help, but will not guarantee success if you don't have the right people in critical roles. Conversely, if you do have the right people in those roles, they will find a way to work around the deficiencies in or change the process and the org structures.

In a start-up, you live and die by the quality of your team. In my experience, even large organizations still depend on a contingent of critical talent. So the most dangerous thing a technology company can do is to start treating its technical talent as a fungible resource - a pure cost to be managed down on a per-unit basis.

Paul Graham's analysis of Yahoo is a great illustration of this.

Errors & exceptions - client vs service

Let's say you're designing a service that exposes a getByQuery() interface. The client is responsible for composing a query and interpreting the result set returned.

Interesting question to consider: if a query results in an empty record set, is it because the query is valid but no matching records are found, or that the query is invalid in that particular context?

The designer of the service can choose to be helpful and indicate error conditions to distinguish the two cases, but at a cost of having to be more aware of the calling application's context.

Alternatively, the service could be context-agnostic and just return an empty record set. It then would be up to the client to have a complete enough suite of unit tests to have an assertion fail and indicate  an error in such a case.

I personally lean towards the services being more agnostic of client context and not getting encumbered by context-specific helper methods too early in their lifecycle. YMMV.