Outsourceability as a Measure of your Software Development Process

Accelerate Your Projects

In addition to our own suite of mobile and web applications, my business provides technology consulting and software development work for other organizations.

Sometimes our consulting work entails developing full, stand-alone solutions or adaptations of industry solutions. Other times creating specialized components/modules for in-development systems (e.g. extremely high performance calculation systems), to be integrated with the work of an internal team.

Our clients don’t engage us to cut jobs or to underbid their current employees, our services instead enlisted to ensure and accelerate project success.

We help ensure that the technology employees of our clients keep their jobs, if not earning fat raises in the process, by keeping their projects on time and technologically compelling, their organizations efficient and innovative, besting their competitors.

This isn’t a sales pitch, but instead lays the groundwork for some observations about software processes, and how objections to outsourcing of this nature can often be red flags of critical process faults.

These are instructive because they often highlight immature or dangerous processes and (lack of) controls. I am only speaking to technical arguments against bringing in so-called “outsiders”, ignoring the even more common insecurity and turf defensiveness that makes teams suspicious of outside help.

Even if you never plan on outsourcing or bringing in consultants, ensuring that you could at any time, and that your team is confident enough to do so without concern, guarantees better processes and controls.

Bad Software Processes aka “Why We Can’t Outsource”

Data Security

Concern about data security is a common refrain, founded on the notion that if someone wears a company badge, they’re bound to be loyal guardians of security and confidentiality. Even were that true, it makes the often costly mistake of conflating best intentions with best practices and outcomes.

That someone intends the best doesn’t stop the momentary lapse of judgment, software compromise or laptop thief from walking away with everything you hold dear. The threat surface area grows absolutely enormous and uncontrolled, and while it might have been tenable to secure the production database cluster and its encrypted backups, all of that good work is undone when the data is copied elsewhere.

This critical business knowledge and vulnerable client data is often copied to developer realms where it is usually beyond any and all controls.

It is backed up on various external drives. Copied to developer workstations and virtual machines. Pushed onto USB sticks to do some work at home (only instead it fell to the floor of the subway). Copied onto machines that lack the rudiments of basic physical or electronic security. Pushed to Dropbox accounts. Emailed to the secondary account.

It is playing with matches in a warehouse full of dynamite. It is the sort of risk that seems like nothing until the day your database of client accounts ends up in a torrent somewhere on the dark net.

You should develop against scrubbed or artificial scenario data. If you have tasks that you can’t outsource because the involved data is confidential, you are in perilous straights and likely have already had significant data compromises.

Of course there are cases where technology staff need to work against production data (to solve production data issues or triage the situation that might trigger a particular defect), but that should be done in a tightly controlled, audited, secure environment, not in the often necessarily loose practices surrounding software development.

Having said all of this, we implement every best practice when we use your data (fully encrypted storage and transfer at all times, the principal of least privilege, etc), guarding even fictional data with a very high degree of security. But given the choice we’d rather not develop against confidential data, because you shouldn’t be developing against confidential data, and where possible we will guide you in that direction.

If this is a reason you can’t outsource, engage someone like us to build a data scrubbing or generation solution for you. Time is not on your side.

Code Security

Similar arguments apply to code security, where proprietary code is in play and is seen to represent a tactical product advantage. If you don’t restrict source code access — but you want to defend it against “loss” (e.g. you aren’t open sourcing and engaging the global community) — again you have likely already lost any and all control.

Developers, which includes employees, consultants, senior staff, outsiders, etc should have access to only the specific code they need to perform their tasks.

When I say things like this, some unfortunately take it as showing a lack of trust in developers. That is not the case at all, and instead it is simply following the Principle of Least Privilege, which benefits everyone and should apply to all aspects of your technology implementation.

People make mistakes. Computers and software are compromised. Accounts are surreptitiously taken (for instance via social hacking). Least privilege restricts the scope of damage possible, automatically providing containment.

And ultimately, organizations need a robust, rational evaluation of the merits of their internal code library. Despite all of the above, it’s a simply truism in this industry that people really aren’t looking to steal your code. Either it is heavily specialized for a specific use, and is of little use to others (despite being highly valuable to the company), or it is generalized and is likely a very poor substitute for generalized industry solutions.

If you have frameworks and code libraries that do the same thing that everyone else is doing, you are very likely wasting your time and efforts, and that code can end up becoming an anchor rather than an engine.

Products and organizations die as code hoarding and forced reuse bleeds all inertia.

Mom’s Spaghetti

Everyone knows that decoupling is a good thing, but it’s something that few teams effectively achieve, and instead is used as an argument against bringing in consultants — that the tenuous and multi-faceted inter-relationships between all of the components is simply too confusing and perilous to be able to bring in external help because to do C you need to make simultaneous changes in B and rewrite A, etc.

Being able to separate the components of your system, and describe the interoperations in a clear, concise, provable fashion is critical to ensure that momentum continues unabated, and that the resulting software is secure and provable. The scope of technology where this applies varies: At one point it would have been at the C++ class level, but for modern software layers it is usually in relation to service oriented API, often utilized through web services.

Software that doesn’t decouple and compartmentalize in this fashion follows a predictable arc of early initiative and promise, followed by a gradually slope of decay until irrelevance.

One of the best reads on this is Steve Yegge’s post on how Amazon built their platform, and Jeff Bezo’s dictums on the SOA necessary for each team’s deliverables.

Such an architecture not only allows you to engage external help as appropriate, it dramatically improves the processes internally by naturally imposing base levels of documentation (not of the artificial “we have a wiki and some Word docs {that no one ever maintains much less looks at}” sort, but real, usable, current self-documentation via the API) and security: with a proper SOA, all interactions occur with the controlled and exposed API, allowing great agility and freedom in changing every other aspect of the implementation with ease.

Conclusion

Whether or not a team or organization can benefit from specialized help or short-term consulting/outsourcing engagements is often overshadowed by excuses and arguments founded on defending and perpetuating broken internal processes and controls.

Those gaps compromise internal security, and sabotage internal software development efforts.

Even if you never plan on outsourcing or engaging consultants, you should feel confident that at a moment’s notice you could with confidence.