No offense to software contractors, but given the choice I usually prefer to build software with hired employees.  By signing on as employees, engineers demonstrate belief in the mission and commitment to the long-term success of the company.  Often I can further align their interests with the company’s through equity as well as the opportunity to “grow with the company” in responsibility.

On the other hand, I’ve been building software for over 30 years and managing software developers for 25.

If you’re a non- (or not very) technical startup founder and need to build software, your needs may be better met by a software contractor.  Compared to a permanent hire, advantages of contracting out your software development include on-demand resources; minimal overhead costs (benefits, equity, etc.); and flexibility in matching the scope of your resources to your project, making it easier to adjust your “team” as your needs change.

These are advantages whether you’re managing your first software project or your tenth.

The truth is, I’ve delivered many software projects staffed partially or entirely by contractors.  I’ve sourced contractors through my professional network, Upwork, regular job boards, corporate recruiting departments, Slack channel conversations — you name it.  Previously I wrote about taking delivery of your V1 software from a contractor.  Here I lay out how I look at the entire software contracting process, starting from the beginning.  Taking delivery is the third step: first come selecting, then working with, an outsourced software contractor.

Finding the right contractor is not always easy for me and can be downright daunting if you’ve never done it before.  At a high level, here are my decision factors:

Individual vs Firm

This is decision one: hire an individual coder or work with a contracting firm.  Again, what works well for me may not be best for you.  With less overhead than a firm, individual contractors can often offer their services at lower cost, and you are dealing directly with the individual doing the work.  I’m comfortable managing software developers, so that works well for me.  But a contracting firm offers advantages over an individual that may make sense for a non-technical executive:

• Most software development projects require diverse skill-sets, such as design, front-end development, or back-end development, that are hard to find with equally high competence in one individual.  A firm’s team may include specialists in the skills most valuable for your project.
• If you lack experience in technical project management, or just don’t have the time, a firm can fill that gap for you.
• Many contracting firms combine offshore (read: cheaper) engineers with onshore, English-speaking management.

Experience with your kind of project

To evaluate a contractor’s experience with your kind of software project, you need a concept of what “kinds” of software there are, which may not be obvious if you’re relatively new to software development.  Here’s how I break it down, again keeping it high level:

Looks Good vs Works Good
These are not mutually exclusive.  But the skills needed to ace a corporate website are far different from those needed to build, say, a FinTech (financial technology) service.

If your software is more like a corporate website, with primarily static content that needs to look good (e.g. "professional", "eye-catching"), you should be looking for a contractor with design expertise.  Your project might benefit from a UI specialist up front.

On other end of this spectrum, when developing an app or website with complex functionality, the most important thing (and hardest to get right) is that the software works.  I’m not saying looks don’t matter, but if your FinTech platform is being built a contractor whose primary experience is building beautiful websites, be prepared to receive a beautiful application with bugs, scaling issues, or other functional problems.

Look for a contractor whose experience matches where your project falls on the looks-good/works-good spectrum.  If  both are equally important in your project, both are equally important in (choosing) your contractor.

Consumer vs Enterprise
Serving different audiences, consumer and enterprise software are generally built with similar technologies requiring similar technical skillsets.  Where they differ is in the product context that determines the requirements for the software.  Here are my notes on the product context I associate with these types of software, that I look for in a contractor’s experience base:​

• Consumer — Typically an emphasis on landing page, user on-boarding, ease-of-use, visual appeal.
• Enterprise — Often purchased by a small group of people who are not necessarily the end-users.  Needs to “check the boxes” of the features important to these decision makers.  UI less important.  Might need to satisfy industry regulations or operational Service Level Agreements (SLAs).

Once again, look for a contractor with matching experience.

Lifecycle Pricing

When I’m budgeting a software project I think about the entire software lifecycle, my version of which I list below.  Whether your software contract covers all of these steps or (most likely) just some of them, you should be thinking about how all of these steps get done, by whom, and how much they will ultimately cost:

1. Design.  Software design is a specialty (actually multiple specialties, including graphical design, UI, and User Experience (UX)).  Most software developers are not design specialists (even “front end” developers).  So you’re likely to need a design specialist early in the process, or to accept a look-and-feel that is whatever you and your contractor come up with (read: amateur).
2. Development.  This may be only thing you thought you needed from your software contractor.  I hope by the time you finish reading this article you no longer think that. :-)
3. QA.  Quality Assurance (testing) is another skillset at which many developers are not expert.  Ask your contractor how they test their software; a good answer should include a description of a multi-tier process.  What happens when you find a bug in the software after you’ve taken delivery?
4. You changed your mind.  Every day you learn more about your business, your audience, and your evolving product. It’s not only inevitable that over time you’ll want to refine your original product idea, it’s rational.  Can your contracting arrangement accommodate changes?  If not, when is your first opportunity to act on your better-informed product ideas, and what’s the process for making those changes?
5. Launch, Monitor, Maintain and 6. Version 1.1, 1.2…   While these two phases come after delivery of version 1 (which is why I’m lumping them together), you should be thinking from the start about how to resource follow-on work to manage and update your software.  You can use the possibility of follow-on work to motivate high performance in your contractor now.

​
Check References

When I hire a contractor for the first time, I take one of two tacks:

1. Start with an engagement small enough in scope/risk that failure, while disappointing, isn’t devastating.  In this scenario I become my own reference for a larger follow-on engagement.
2. Check references.  If “failure is not an option”, I consider this essential.

I have found that references for a contractor will often share more information than references for a full-time hire.  Maybe the stakes (or liability) seem lower.  I try to make reference checks cordial and conversational. I’ve certainly learned things in those conversations I never would have picked up just looking at the contractor’s online profile or portfolio.  A couple of tips for checking a contractor’s references:
​

• Talk to clients with similar kinds of software projects.  Similar “kinds” as in looks good vs works good, consumer vs. enterprise (remember? :-).
• Every non-trivial software project has problems.  (That’s worth repeating: Every non-trivial software project has problems.) During my conversation with a reference I pretty much say that and ask the reference to describe how the contractor handled the problems that did arise.

​Before I describe this chart, let me first describe what I left off the chart.  I omitted the easiest, least time-consuming, least intimidating mode of working with your software contractor: write a check, cross your fingers, and hope the final delivery’s good.  It’s the equivalent of a Hail Mary pass and about as likely to succeed.

WIP: Reviewed

At a bare minimum, for any software project lasting more than a week or two, you should review your work-in-progress (WIP) software regularly during development, wearing your product manager hat.  Have your contractor demo whatever they can. This kind of product review doesn’t require any technical knowledge on your part but does accomplish a couple of things:

• It serves as a forcing function to keep your contractor focused on your project.
• It gives you an opportunity to course-correct your contractor to keep both the schedule, and the direction your software is taking, on track.

WIP: Delivered

Better than regular product reviews are regular deliveries of work-in-progress, even if you don’t do anything with them.  Here’s what this accomplishes:

• Keeps your contractor honest, Part I: Your contractor doesn’t have to know that your team doesn’t include anybody who knows the difference between JavaScript and a Starbucks latte order.  They just know, to anybody who is technical, their progress or lack thereof will be clear from one code delivery to the next.
• Keeps your contractor honest, Part II: If your contractor loses interest, has a major life event, demands more money, or just simply “ghosts” you, would you rather have in your possession something or nothing?
• Taking the first delivery of your software happens once.  For the remaining lifetime of your company, software deliveries will be updates to the software you already have.  Your real software development process will be a software update process.  You want your team (which for now is you and your contractor) to adopt and work the kinks out of your “real” delivery process, the sooner the better.

See below for more about taking delivery of software.

WIP: Audited

Better still than regular deliveries of work-in-progress are audits of work-in-progress: a hands-on examination of the software by an expert. This can include reviewing the software’s organization and readability and examining the technical decisions implicit in it.  Findings from such an audit validate your contractor’s work in a more substantial way, giving you reassurance you’re receiving quality work (and an opportunity to provide constructive feedback if not). Another set of eyes on any technical work almost always improves the quality of the final result.

A technical audit of your software is the only step that requires a technical friend, advisor, or consultant (like me) who is not your contractor.  Assuming your in-house team is not technical, for this step you will need to find such a resource.

WIP: Piloted

The ideal way to treat your in-progress Version 1 is to launch early versions as a pilot, collect real customer feedback, and use that feedback to inform the product definition of the remaining development.

Practically speaking this may be aspirational (as in not do-able) for some startups.  Your product may require complete core functionality for customers to be able to use it.  Your contract may not allow for changes to definition without incurring significant expense.  But what’s the expense involved in launching a Version 1 that’s too far off the mark? Consider whether there’s a 70% version of your Version 1 that you could put in front of users.

In my opinion the best software contracts include the flexibility to build even Version 1 software in multiple phases, allowing you to pilot intermediate versions and refine product definition based on real user feedback.

The first time you hire somebody to develop software for you, delivery of the completed software feels like the finish line.  In actuality, there’s only one scenario in which that’s true: when your company goes out of business right after you launch.

Assuming that’s not your goal, Version 1 is the start of what will hopefully be long-term software ownership.  That includes adapting the software to your evolving understanding of what your customers want, and simply keeping the software running smoothly through operational glitches, variations in user load, and external changes to infrastructure like your cloud platform.  (For instance, Amazon AWS, the most popular cloud services platform, frequently updates their services and unofficially or officially deprecates old ones.)

I recommend you take physical delivery of your software like a long-term owner-operator, even if your initial plan is for your contractor to continue to run it for you.  These are the two things you should ensure are included in your contract software delivery:

1. Every software artifact necessary for anybody (not just your contractor) to maintain, build, and deploy your software from scratch.  This includes source code and other digital assets. such as images; it might also include third-party software libraries and licenses.
2. Documentation sufficient for any engineer familiar with your software stack (the languages, frameworks, and other technologies employed by your contractor) to build and deploy your specific software application.

I hear some version of “I’m about to take delivery of Version 1, what do I do now” as frequently as any other question I hear from non-technical founders.  So I previously posted more about this all-important phase in the software contracting lifecycle.

​Don’t wait for delivery of Version 1 to start observing the best practices of successful software companies.  Be diligent in your search and selection of a software contractor (even if you’re a small account).  Structure your delivery into intermediate steps that you can leverage.  Assume you and your software will be around for a long time, and act accordingly.

Also published on CTO Vision and CTO Craft

​As a consulting CTO I work with companies at all stages of software product development.  Startups with scarcely more than a PDF mock-up.  Multi-million dollar businesses refining their umpteenth software version.

But there is one stage in the evolution of a software company at which they disproportionately reach out to somebody like me — when they’re about to take delivery of new software from a software contractor.

Like expecting a baby, you might think the imminent delivery of outsourced software would be a time of excitement and high spirits, but it is just as often a time of panic and confusion.

I believe this consternation results from a couple of common misconceptions that non-technical executives become aware of as delivery day approaches.  After all of the effort to conceive the idea, define and (maybe) validate a minimal viable product, weigh in-house versus outsourced development, shop for and choose a contractor, fund and schedule the software development, a software product owner’s attention finally turns to crossing the finish line — taking delivery of the software.

Delivery of the software is actually the starting line.

As a client of an outsourced software contractor, chances are close to zero that you will be fully satisfied with the software you’re about to receive.  Chances are pretty good, in fact, that you won’t even want to launch what’s delivered until you make some changes.  That’s not because software contractors are incompetent (they’re no more or less competent than any other trade), or because outsourcing software is an inherently futile endeavor (famous outsourcing success stories include Skype, Slack, and Alibaba).

Software is complex (even simple interfaces hide great complexity underneath).  User behavior is notoriously difficult to predict.  And the creative process for most human beings is iterative and trial-and-error.  Mozart would have nailed his outsourced software on the first try.  You, my friend, will have to address the following:

• The difference between the software you receive and what you originally wanted.  It’s hard enough for an experienced product management professional to anticipate and define all of the nuances of user interaction that go into a software product.  For the newbie trying to intuit his or her way through the process, it’s downright impossible.  The more functionality you’re seeing for the first time in your “final” delivery, the more deviation you can expect from your original product vision.
• The difference between the software you originally wanted and what you NOW want. I’ve delivered new products and features to product owners dozens, if not hundreds, of times (including a few times wearing the product owner hat myself).  A product owner never fails to see something that needs to be changed after seeing fully functioning software for the first time. Even Mozart tinkered with his draft compositions.
• The difference between the software you now want and what your USERS want.  I don’t mean to discredit your skills as a product visionary, but until your software launches, your product vision has been merely a guess as to what your users want.  If you validated your assumptions with a minimal viable product, it’s an educated guess.  Only by launching production software can you observe, measure, and ultimately react to what your users actually want (or don’t).

Delivery of your outsourced software doesn’t represent the finish line.  It represents the start of multiple rounds of software changes to home in on a version of Version 1 that works with real users.  And that’s not even taking into account whatever technology roadmap you’ve been cooking up in the meantime.

OK.  Whatever software your contractor delivers, you will want to change it.  Let’s put that aside for a moment and imagine that you are in fact the Mozart of software.  You composed the perfect software definition, and it’s about to be delivered exactly as specified.  Surely, then, you can have your contractor launch your software and be done with it.  Right?

​If you’ve outsourced your software development, chances are good your knowledge of how to deploy and operate production software is the same now as when you started this process: negligible.  Maybe you’re optimistic that you can just let the software run, or that you can ask your contractor to run it for you at minimal cost.  Maybe your baby will change its own diaper.

• There’s no such thing as deploy-and-forget software.  Bugs, which are found in virtually all software, become apparent over time.  Not all bugs need to be fixed, but many do.  Even if your software were bug-free, its environment will change (e.g., mobile OS or browser updates) or occasionally fail.  Security patches will need to be applied.  Your software will need to be monitored and maintained.
• Perhaps your relationship with your contractor survived the contracting process (congratulations!) and you have decided to retain them to maintain your software.  I have managed hundreds of software engineers (and am one myself) and can tell you: Engineers build software because they like to.  They maintain software because they have to (if they do it at all).  From an engineer’s perspective, one of the advantages of contract work is that it tends to be focused on building software, not maintaining software.  Conscientious maintenance of software (like maintenance of your home or anything else) requires a sense of ownership that is rare in a contract relationship.
• Perhaps your contractor is unusually invested in your software and you trust them to maintain it as if it were their own.  You’re still at the mercy of contractor-based events you don’t control, such as:
  • They shift their attention to other clients, which can happen for a variety of reasons (business growth opportunity for the contractor; putting out another client’s fires; the distraction of more interesting work).
  • They lose the staff that worked on and knows your software.  The average job tenure of software engineers is notoriously short.  A contractor’s staff is likely to be even more itinerant.
  • Businesses sometimes go out of business.  Maybe your contractor…

OK.  After I take delivery of my software, I will need to monitor and maintain it, I’m going to want to change it, and I can’t just rely on my contractor to do all of this for me.  What am I supposed to do?

Your most empowered stance is to operate, maintain, and update your software in-house.  Whether or not that is practical or desirable, you still want to take delivery of your software in such a way that you could manage it in-house.  That keeps all of your options open (current contractor, different contractor, in-house, hybrid approach) while maximizing your leverage with your current contractor, should you continue to work with them.

These are the two things you should ensure are included in your contract software delivery:

1. Every software artifact necessary for anybody (not just your contractor) to maintain, build, and deploy your software from scratch.  This includes source code and other digital assets. such as images; it might also include third-party software libraries and licenses.
2. Documentation sufficient for any engineer familiar with your software stack (the languages, frameworks, and other technologies employed by your contractor) to build and deploy your specific software application.

Many outsourced-software clients lack sufficient technical knowledge to know what specifically to ask for, how to physically take possession of your software (such as creating a code repository), or how to evaluate your contract software delivery against the above requirements.  If that describes your situation, consider having an independent evaluation done by another, impartial contractor (such as a consulting CTO like me).

Whatever resources you bring to bear, the success of your software will depend on your capability to make changes based on user feedback and business requirements, and to operate and maintain the software. By properly taking delivery of your new software application and the documentation necessary to manage it, you preserve all of your options and set up your technical team — whether your current contractor, a different contractor, or in-house resources — for success.

Also published on CTO Craft and CTO Vision

​Can a database technology really kill an entire industry?
​
That’s what I was asking myself at one of two blockchain presentations I recently attended. The first was a panel discussion in which knowledgeable blockchain evangelists predicted blockchain will indeed lead to the demise of entire industries.  The second was a presentation by a blockchain expert for a Fortune 50 company.  Not surprisingly, he offered a different perspective on whether blockchain will cause traditional industries to crater.

So how could a database platform, in this case blockchain, put anybody out of business?

​A blockchain is sometimes defined as a shared, immutable ledger.  I would add to this, “transparent”.
​

• Shared: A blockchain is shared across multiple participating computers, or “nodes”, each of which replicates an exact copy of the blockchain.  The most famous blockchain network, bitcoin, currently uses nearly 12,000 nodes.
• Immutable: Thanks to an ingenious application of cryptography, once written, the transactions or “blocks” in a blockchain cannot be changed without breaking every node’s copy.
• Transparent: The details of each block, and the transaction that created it, are visible to each participant in the blockchain, and the rules for adding a valid block are shared by all, so not only do participating nodes own a copy of the blockchain, they can see and audit the blockchain.

​Put together, these characteristics make blockchain into something very valuable and potentially very disruptive:

The digital history recorded in a blockchain, whether of documents, transactions, or digitized records of assets or even people, can be trusted by all participants.

Who did the panel of blockchain evangelists predict blockchain would put out of business?  Trust brokers.  Businesses whose value proposition is to ensure the validity and integrity of documents and transactions.  Businesses selling trust that can be replaced by using a blockchain. Title insurance companies.  Stock clearing houses.  Gone.

Sounds revolutionary, and scary if you make your living in the trust-broker business.  But this panel was presenting to an audience of hundreds, and I didn’t get a chance to follow up with questions that were bothering me: What does it mean to “broker trust”?  Does that always mean the same thing?  Can blockchain replace all trust brokers or just some, and why?

I was still thinking about this when I attended a second blockchain presentation two days later, this one a lively talk by an IBM “Global Blockchain Industry Leader” (that’s what they call them at IBM).  The speaker didn’t mention disruption, and he didn’t even mention “trust”, but when he got to how IBM adds value to the blockchains it manages for clients, my antennae went up.  IBM is a “blockchain network administrator.”

Blockchain administrator?  Why does a blockchain need an administrator?  I thought the whole point of blockchains like Bitcoin was that they are decentralized networks that don’t need an “administrator.”  Was IBM just trying to invent a way to add value to a platform that doesn’t need it?  Was IBM just another trust broker trying to remain relevant?

​To answer these questions, you have to understand that there are two types of blockchains: public and private.

Public blockchains, which anybody can join, get all the (popular) press.  They include the cryptocurrency blockchains, the blockchains whose disruptive potential my panel of evangelists was very excited about.

Private blockchains, also known as permissioned blockchains, require an invitation to join.  They allow a business consortium to take advantage of all of the technical features of a blockchain platform while restricting access to, well, an invitation-only consortium.  In one interesting example of a private blockchain, an entire food supply chain was digitally recorded and tracked in a blockchain, reducing the time to track the origin of a mango on a retailer’s shelf from almost a week to two seconds.  You may have heard of the retailer: Walmart.  (The blockchain was implemented by IBM.)

Enterprise blockchains are private blockchains, and while private blockchains may not be as sexy to casual blockchain fans and soothsayers, they are seeing wide adoption in industry and are not going away.  (According to a late-2016 Deloitte survey of executives across a variety of industries, 25% expected to have production blockchain deployments by the end of 2017.) 

So who grants permission to join a private blockchain? 

​The answer is no different for blockchain than for any other private network.  Permission is granted by a gatekeeper, and that gatekeeper could be the blockchain administrator.  So on that basis alone, there’s a future in the (private) blockchain administrator business.

Who will blockchain put out of business?

While blockchain technology has the potential to be enabling and disruptive in exciting ways, clearly it won’t disintermediate all intermediaries or make all trust brokers go broke.  Here’s my take on the factors that will determine blockchain winners and losers:
​

• In some cases, an entire business process can be built into blockchain or added via general-purpose smart contracts.  If public, those blockchains could put traditional trust brokers within that business process out of business.  Cryptocurrency is the prime example of a business process built into blockchain, but there will be others.  The closer the business process approximates a simple ledger of transactions, the easier it will be to eliminate traditional trust brokers by implementing that process in blockchain.
• Whether you call them trust brokers or administrators, there is great opportunity for businesses that serve as gatekeepers for consortium-style enterprise blockchains.
• Specialized business rules, captured in smart contracts, will have to be created to fulfill specialized business cases, just as they always have.  Third party developers and integrators will continue to play an essential role in the development and administration of enterprise blockchains, especially private ones.
• The history recorded in a blockchain is only as trustworthy as the information that is inputted into the blocks.  Those inputs (assets, transactions) still have to be validated; in some cases, by a traditional trust broker. Land titles, for instance, still have to originate from government sources.

If an entire business process can be reduced to general-purpose blockchain transactions, blockchain can and will replace companies whose only business is ensuring trust in that process.  I think those companies will be the exception, not the rule.  Companies that serve as gatekeepers for enterprise consortia or, more generally, implement or integrate specialized business rules will not only survive but thrive.

Also published on CTO Craft