Serious Work

When some people hear (or say) the word intern, they imagine someone who makes copies and fetches lunch. Perhaps in some work cultures that is helpful, but here we have in mind serious work. Our interns will work on serious work:

• Projects that are helpful to our company operations
• Exploratory programming, to try out ideas that don’t yet warrant commercial attention
• Open Source programming, such as improvements to tools we use
• Perhaps even a few bits of our real customer projects

The kinds of work could include…

• writing software
• testing software
• reading and writing about software
• marketing work around the software

Twofold Purpose

The purpose and goal of our internships will be:

1. Educate and enlighten the intern
2. Hopefully also create something useful to Oasis Digital and its customers

Paid vs Unpaid Internships

Many companies are eager to get free help from interns. But it’s clear from a few minutes research that a for-profit company with an intern working on potentially valuable project, must pay. Therefore, we will only offer paid internships.

Location

The internship work will be conducted at our at Oasis Digital office; interns must live in the St. Louis metro area.

Can I Apply?

Sorry – No. We’ve already selected an intern for our trial-run 2011 program. If we decide to continue and expand it for 2012, it will be announces in the spring (of 2012).

Whenever you hire out work, either to a person, to a team, or to a company, there are risks. These risks can easily prevent the work from being completed, and even more easily prevent it from being completed on time. (I’m thinking mostly of software development work as I write this, but most of this applies to other domains as well.)

What could go wrong with the person/team/company you hire?

• They get distracted by family or personal issues.
• They turn out to not be as qualified or capable as they appeared.
• They leave for better work. Sure, you might have a contract requiring them to finish, but your lawsuit won’t get the work done on time.
• They turn out to not be as interested in your work as they first appeared.
• They start with an approach which, while initially appearing wise, turns out to be poorly suited.
• Illness or injury.

Of course you should carefully interview and check reputations to avert some of these risks, but you cannot make them all go away. You don’t always truly know who is good, who will produce. You can only estimate, with varying levels of accuracy. The future is unavoidably unknown and uncertain.

But you still want the work done, sufficiently well and sufficently soon. Or at least I do.

Redundancy Reduces Risk

A few years ago I stumbled across a way to attack many of these risks with the same, simple approach: hire N people or teams in parallel to separately attack the same work. I sometimes call this a RAIT, a Redundant Array of Independent Teams. Both the team size (one person or many), and the number of teams (N) can vary. Think of the normal practice of hiring a single person or single team as a degenerate case of RAIT with N=1.

To make RAIT practical, you need a hiring and management approach that uses your time (as the hirer) very efficiently. The key to efficiency here is to avoid doing things N times (once per team); rather, do them once, and broadcast to all N teams. For example, minimize cases where you answer developer questions in a one-off way. If you get asked a question by phone, IM, or email, answer it by adding information to a document or wiki; publish the document or wiki to all N teams. If you don’t have a publishing system or wiki technology in hand, in many cases simply using a shared Google Document is sufficient.

There are plenty of variations on the RAIT theme. For example, you might keep the teams completely isolated in terms of their interim work; this would minimize the risk that one teams’ bad ideas will contaminate the others. Or you might pass their work back and forth from time to time, since this would reduce duplicated effort (and thus cost) and speed up completion.

Another variation is to start with N teams, then incrementally trim back to a single team. For example, consider a project that will take 10 weeks to complete. You could start with three concurrent efforts. After one week, drop one of the efforts – whichever has made the least progress. After three weeks, again drop whichever team has made the least progress, leaving a single team to work all 10 weeks. As you can see in the illustration below, the total cost of this approach is 14 team-weeks of work.

How might you think about that 14 team-weeks of effort/cost?

1. It is a 40% increase in cost over picking the right team the first time. If you can see the future, you don’t need RAIT.
2. It is a 50% decrease compared to paying one team for 10 weeks, realizing they won’t produce, then paying another team for 10 more weeks.
3. If you hired only one team, which doesn’t deliver on time, you might miss a market opportunity.

Still, isn’t this an obvious waste of money?

To understand the motivation here, you must first understand (and accept) that no matter how amazing your management, purchasing, and contracting skills, there remains a significant random element in the results of any non-trivial project. There is a range of possibilities, a probability function describing the likelihood with which the project will be done as a function of time.

RAIT is not about minimizing best-case cost. It is about maximizing the probability of timely, successful delivery:

• To reduce the risk of whether your project will be delivered.
• To reduce the risk of whether your project will be delivered on time.
• To increase your aggregate experience (as you learn from multple teams) faster.
• To enable bolder exploration of alternative approaches to the work.

What projects are best suited for RAIT?

Smaller projects have a lower absolute cost of duplicate efforts, so for these it is easier to consider some cost duplication. RAIT is especially well suited when hiring out work to be done “out there” by people scattered around the internet and around the world, because the risk of some of the teams/people not engaging effectively in the work is typically higher.

Very important projects justify the higher expense of RAIT. You could think of high-profile, big-dollar government technologies development programs as an example of RAIT: a government will sometimes pay two firms to developing different designs of working prototype aircraft, then choose only one of them for volume production. For a smaller-scale example, consider the notion of producing an iPhone app or Flash game for an upcoming event, where missing the date means getting no value at all for your efforts.

Thanks to David McNeil for reviewing a draft of this.

I used to have a software product business myself, a vertical market SaaS firm. Now that I’ve been out of that for over a year, the thing I miss most is the feeling of being “in the arena”, of having a speculative product out there for people to buy. To be out there is both terrifying and exhilarating. I have heard it said that there are “product people” and “consulting people”, and looking back it is clear to me that I am mostly in the Product category.

Unlike some product people (like Amy Hoy, whom I admire greatly!) I don’t think it’s necessary to swear off one thing to do the other. Consulting (building software for clients) is very satisfying, especially when working with a team of great people (and a group of very competent customers) like we have at Oasis Digital.

So while I’m going to keep building software for other people, I’m also going to go back to the marketplace with speculative products. This time it will be products in the plural, some subset of:

• Web/SaaS software
• iPad software
• iPhone / iPod Touch software
• Android software (by year-end the stores will be piled high with Android tablets)
• Or possibly HTML5/etc software to address all of the above
• Backend / data / system management software
• Or even, possibly, locally installed desktop software

I apologize for the vagueness of this list; but I agree with Derek Sivers about keeping one’s specific goals to oneself so my voluminous and tedious notes on exactly what products to offer, will remain offline.

iTunes-Ping Social Network

It doesn’t integrate with other social networks, and the initial content on there (from what I’ve heard, I didn’t even bother to look) is weak, consisting mostly of some well-known musicians who (shockingly!) think you should buy their music. None of this matters. If Ping v1 gets Apple some incremental sales in the iTunes store, it’s a win. Apple has an enormous audience, so inevitably Ping will get some level of community, and with that in place Apple can bring out a v2 in which they add integration, support in all of their devices, etc.

Apple TV

The 720 resolution is a disappointment, and I find the lack of a digital audio output rather surprising. No apps. It doesn’t compare well on technical features, with some similar products already out there.

But it’s a whizbang, very friendly Apple device $99! It will probably sell in big numbers, to many millions of consumers who haven’t (and won’t ever) hear of the similar products from lesser-known firms. Once there is a big user base out there, Apple can announce Apps and other features for Apple TV, with enormous fanfare and day-1 sales volume.

iPod Nano with multi-touch

This doesn’t have apps yet either; and similarly, the foundation is clearly there. Apple can add some form of Nano Apps in the future, again with an installed base already in place ready to start buying apps (in volume) on day 1.

iPad Multitasking

As a power user and developer, I find it a bit annoying that the iPad, a powerful computer launched in 2010, didn’t ship with multitasking. Yet I’m very happy with the device anyway, and it didn’t stop Apple from selling a billion dollars’ worth of them in a few months. Adding multitasking for free in November is a nice (small) step forward, plenty good enough for a mid-cycle update.

Winning Big

Apple isn’t merely trying to win today. They are trying to win big.

Sorry, Not a Fanboy

But am I a fan of all this?

• As a user, yes. I enjoy Apple’s products. I am typing this on a MacBook Pro, with an iPad sitting nearby.
• As a developer, I am not a fan of the increasingly closed ecosystem they are building. It reminds me ominously of the first generation of home computers, and current gaming systems, where the manufacturer interposes themselves in every financial transaction forever. That approach lost to an open market back in the 1980, I hope it does not take over the PC world ever again.
• In addition, the closed ecosystem excludes many possible applications that would be very useful to our customers.
• As a business aficionado, I nod approvingly at their strategy and execution prowess.

Update: I’m not the only one who thinks Ping will make Apple a lot of money, regardless of its merit.

In the meantime, though, I noticed something very interesting: the firms that appeal to me most, in terms of web site content, community involvement, portfolios, marketing approach, etc., are disproportionately Ruby or Ruby-Rails shops. I admire the “vibe” of the Ruby community:

• Strong focus on design, to the extent that some Ruby-centric development firms have web sites which could pass for visual-design firms instead.
• Ruby developers seem unusually aware of the extent to which syntax and conciseness matter.
• There is much discussion of craftsmanship, though I’d need to survey a broader swath of production code to determine whether this discussion has a basis in reality.
• Seemingly contrary to the above factors, Rubyists also appear to be unusually pragmatic.
• This pragmatism translates to real-world financial impact: many developers make a good living with Ruby, and many firms are very happy with their Ruby projects.
• Ruby events are numerous, nationwide.

There are numerous Ruby- or Ruby-Rails-centric development firms, and Oasis Digital is not one of them (we are perhaps a 5%-or-so Ruby shop, with Ruby expertise to effectively attack automated sysadmin, integration projects, and so on). We aren’t going to become a Ruby-centric-firm, either; and there are some technical aspects of Ruby that don’t impress me.

Rather, we want to bring some of the cultural qualities seen in the Ruby community, to other languages and tools. We care about design much more than most firms, and it shows in our GUIs. We care about user experience, and we are obsessed with quality, working results.

Between 1997 and 2000, I spent countless hours on the BDE Alternatives Guide, a section of this web site devoted to listing and analyzing the dozens of third-party database access libraries available for Delphi in that era. Delphi shipped with the BDE a not-great mechanism for database access. BDE was Borland’s answer to Microsoft’s ODBC, but unlike the latter, BDE didn’t get industry-wide support.

Working on the BDE Alternatives Guide had many positive payoffs:

• It created a much-needed resource, greatly appreciated by thousands of developers.
• I learned enormously in the process.
• It put me in touch with dozens of library vendors, and many hundreds of developers.
• It generated many incoming links and much traffic, around a million page views over a 5-year period.
• Banner advertisements brought in a few hundred dollars, before I scrapped them to avoid the appearance of bias.
• It made me reasonably well-known in the Delphi world, which was growing rapidly at that time. (Our team at Oasis Digital still does some Delphi work, by the way.)

You might think, though, that establishing expertise as a Delphi database integration expert, would result in lots of consulting leads, new business, and job offers. Let’s look at the stats:

• Total number of leads generated: 0
• Total consulting work generated: $0
• Total job inquiries and offers: 0

Yes, that’s right. Not a single firm ever contacted me to inquire about consulting, development, etc., as a result of the BAG. I’m still glad I did the work, for all the reasons above. But it is a counter-example to the notion of showing expertise and building a following, as a way to generate business interest. Sometimes the work pays off in new business, and sometimes it doesn’t.

Oasis Digital (my firm) is a custom software development shop. It is not a staffing or recruiting firm; there are many good firms in those businesses, and I have no desire to join them in that market. Oasis Digital doesn’t offer contract-to-hire, it doesn’t charge a percentage of a hire’s pay, and does not recruit in for customer placement.

Nonetheless, we do occasionally help our customers hire.

Really?

I’ve heard customers and our own team members express surprise at this. Isn’t it against our own interest to help a customer with a direct hire, who might end up doing some work instead of Oasis Digital doing it?

In a short-term, trivial sense it is perhaps against our interest. If we wanted every project to go on forever, using 100% only Oasis Digital staff, then we would make sure to never help any customer with any hire at all. But that is completely unrealistic. There are millions of software developers (and sometimes it seems almost as many software development firms). We are in a competitive market. Our customers have a choice, they can do business with us or have someone else write their software instead, regardless of whether we help them with hiring.

Therefore, the real question is whether to be greedy for the short term, or visionary for the long term. We choose the latter. Our policy is that we are happy to help our customers hire direct staff. We believe that this will, in the long term, lead to success for our customers and for Oasis Digital.

We assist with hiring in 3 ways.

Direct Assistance with Hiring and Onboarding

At Oasis Digital we have a somewhat unusual hiring process: in addition to the usual interviews by phone, in person, and otherwise, we ask (and pay) prospective developers to write some code for us based on a short specification. The resulting code, and conversation about it, provides a great opportunity to get to know someone (and to assess the results they will create) very quickly before hiring them. We assess technical skills as well as teamwork / cultural fit. We have a high bar to hiring and a defined process to reach that bar. At the same time, our process respects potential employees, by not asking for sample work to be done for free.

A good hire, though, is not the finish line. It is the starting line! During the first months of a new developer’s work we have an onboarding process in which the new developer sets up a work environment (mostly by referring to project documentation), then implements tiny changes, then small changes, then medium changes, then finally can begin work on large, important tasks. Throughout these initial months, the new developer works with more frequent collaboration and code/change review than will be needed in the long run. We have found that with our hiring and onboarding processes (described above at a very high level), we have a high success rate.

The first and most direct way we can assist our customers, therefore, is to simply execute these processes for them: assist with interviews, sample projects, and lead the onboarding effort.

Same Standards

When working with a mixed team consisting of Oasis Digital staff as well as customer staff, we hold everyone to the same high standards.

I’ve seen teams that work the other way: accepting a lower standard of work from a customer’s internal staff. It ends badly. We would rather lose a customer, than ship bad software. Our reputation matters more than the next dollar.

Pass It On

Lastly, our processes aren’t a deep secret; the key is not the ideas, it is the execution. We are happy to teach our way of working to customers (and everyone else, in blog posts and talks). Even at the price (free to read, normal billing for customer work) it is a hard sell, though: hiring is often deeply embedded in how companies work.

Stay Tuned

I’ve summarized here at a high level; expect future posts and talks with many more details.

Warning: Sausage-making Discussion Below

The following has nothing to do with the content of the video.

This is an x.264 video, shown here initially with a Flash-only player (FV WordPress Flowplayer). The video file is served by Amazon’s CloudFront CDN, which is trivial to sign up for without any sales process or minimum service cost. Later I’ll replace this Flash-only widget with one that offers HTML5 video (for iPad use, in particular), when I find one that works sufficiently well.

That’s the easy part, though. Getting this video to you here was an adventure, and not in a good way. Three recordings were made of the talk:

1. We hired a professional videographer to record the talk. When I say professional, I mean it only in the most literal way, i.e. the videographer charged money. They showed up with a nice camera and a wireless lapel mic… but somehow produced a broken video recording (the first 10-15 minutes were intermittant video noise). In addition, the mic gain was turned up way too high and thus the audio is awful.
2. Dave Blankenship recorded the talk on his consumer camcoder; he was not paid for this, and he did a much better job. This video is usable all the way through, but arrived in an oddball format produced mostly by some models of JVC camcorders. The audio was not so hot, because he used the mic built in to the camcorder from the back of the room.
3. I recorded the audio using a $5 microphone plugged in to an iPod Nano, sitting on a table at the front of the room. It’s a bit noisy, but with a few minutes of work with Audacity (Noise Removal and Normalization), the results are much better than either video attempt.

Armed with this, I set about to somehow combine the video from #2 with the audio from #3. I send emails describing this mess to several videographers I found on Craigslist. Most of them didn’t reply at all. I finally got a cost estimate from one, of many hundreds of dollars or more, and not much assurance of results.

Now I’m willing to spend some money to get good results, but spending it without confidence of results is less appealing; so I set about trying myself instead.

First, I cleaned the audio in Audacity as mentioned above.

Second, I watched the video and listened to the audio a few times, to get the approximate starting timestamp in each one of the moment the talk actually started; each recording had a different amount of lead-in time

Third, I grabbed ffmpeg, the swiss army knife of command line video and audio processing. After reading a dozen web pages of ffmpeg advice, and a number of experiments (with short -t settings, to quickly see how well it works without waiting to transcode the whole thing), I ended up with this command to produce the encoded video:

ffmpeg -y -ss 40.0 -i Recording-3-audio-only-clean.wav -ss 95 -i Recording-2-video-ok-audio-bad.mod -shortest -t 18000 -vcodec libx264 -vpre normal -b 700k -threads 2 Cordes-2010-SaaS.m4v


I then noticed that the MacPorts installation of ffmpeg omits the important qt-faststart tool, and found this helpful version of qt-faststart and used it instead, on my Mac; later I switched to a Linux machine with an ffmpeg install including qt-faststart. Without the faststart step, the metadata in the m4v file is arranged in a way that prevent progressive/streaming play-while-downloading.

The results are good but not great:

• The video has some motion/interlace artifacts; these were present in the original recording, and I’m not aware offhand of what to do about them
• The video camera used rectangular pixels; the pixel aspect ratio is 3:2 while it is intended for display at 16:9. I wasn’t able (at least in 20 minutes of learning and experimentation) to get the 16:9 output working correctly, so if you grab the underlying m4v file you can see the aspect ratio a bit off in the shape of the clock on the wall, for example.
• The audio-video sync is adequate (and plenty good enough to follow along) but not perfect. Clearly using the audio track on a video recording is much better than putting them together in post-processing.
• The audio is not as good as if I used a lav or headset mic, though I think it’s quite remarkably good for a $5 mic plugged in to iPod.
• I’ve no idea if ffmpeg complies with any of the relevant copyrights/patents/whatever in video production, though it seems hopefully safe to use for a one-off non-commercial video like this. (Normally I use Apple’s iMovie for my videos, and I assume Apple has taken care of such things.)

A few morals of this story:

• Get some powerful tools, and learn how to use them.
• Be willing to pay for professional work, but be skeptical. Just because you pay, doesn’t mean it will be quality work.
• Have a plan B. If I had assumed that at least one of the two videos would get decent audio, and skipped my own audio recording, I’d not have been able to deliver the acceptable audio here. If Dave had assumed that my professional videographer would produce results, and turned off his camera, we’d have no video here at all.

As usual, the vimeo page offers it for HTML5, non-Flash platforms like the iPad.

Back in 2004 I co-founded Mobile Workforce Management, a vertical market SaaS firm. For the first 6+ months, I was the entire development team, while my co-founder was the entire analysis, support, and customer happiness department. Over the course of a few years, we hired developers, a very-senior developer / leader / general manager, support staff, and more. In spite of these hires, as of 2007 I was still in the loop for numerous critical processes that had to happen every day or week to keep the doors open – not a great situation.

Around that time I was inspired to take a month-long family vacation, far longer than any past vacation. My family made arrangements to spend 3 weeks in a house by the beach, 1000 miles away, in the summer of 2008; these arrangements must be made far in advance, as such houses tend to fill up. I’d be away for approximately an entire month, allowing for travel time and stops along the way.

With that hard date in hand, my notions of ironing out the business processes “someday” were swept aside, and I set about tracking, automating, documenting, and delegating any of the work that involved me and had to happen at least monthly.

• accounting / bookkeeping / payroll
• production sysadmin
• development sysadmin
• system monitoring
• management processes
• customer relationship processes
• vendor relationships
• design and code reviews
• much more

It took months of hard work (by myself and others) to build up our company ability to handle all of these things well in my absence. As of the vacation date, all of this was set up to run smoothly either entirely without me, or with a tiny bit of remote input from me.

This worked, in fact it worked so well that our customers didn’t even notice my absence.

Though I didn’t know it at the time, the work I did then to increase our organizational process maturity was a turning point in the life if the business, enabling its eventual sale. Before that work, I’d have been a bit embarrassed to say “organizational process maturity” in public. Afterward, I have lived (rather than just learned about and talked about) the notions of working on-rather-than-in a business, of building a business with a life separate from that of its owners.

In retrospect I’m calling that trip a Strategic Vacation – a vacation taken both for its own value, and to drive the accomplishment other critical goals. If your business needs you every single day, that’s a problem. Create some pressure on yourself to solve it, by scheduling a strategic vacation, then go make it happen.

This is a Vimeo video, embedded as Flash. You can go over to Vimeo to watch it with HTML5-video devices like an iPad. I expect to offer better quality and more options as I learn more.

estimate ≠ promise

Background: Unpredictability

Around half of my software development and leadership experience has been in enterprise/internal software development, and that is the world I am thinking of as I write this.

Software development, like other endeavors with a significant creative component, is inherently unpredictable. With a good, deep understanding of the development process, you can build a model of the probability distribution of the cost, effort, and elapsed time for software development work. In the large, on average this can be made to work: small and large projects can succeed, within some broad range of predictability.

But notice also how common it is for large complex projects (in software and elsewhere) to be farcically over budget and late. This is not (usually) due to incompetence or fraud. It is because of the inherent unpredictability of the work.

If someone claims that they (or you) can exactly predict software development work, they are:

• mistaken, or
• lying, or
• padding their estimates very substantially, stating a date or cost much later/higher than a neutral median estimate would suggest

As a customer of software development services, and as a provider of such services, I don’t want any of those things.

Blame the Service Trades

I place some of the blame for the confusion of these two wildly different things, on the service trades: it is common for auto repair shops, roof installers, landscapers, and the like to offer something they call an estimate, but which is actually a fixed price quote (a promise).

Sadly, while there are plenty of common good synonyms for promise, there aren’t many for estimate. We’re stuck with using the word estimate, and explaining that we really mean it as defined. Perhaps in a few more decades we will lose the word entirely, much like the word “literally” has come to mean its antonym, “figuratively”, which renders it mostly useless.

Estimates

An estimate is an approximation of an unknown quantity. Typically in the world of software development, it is a prediction of the cost, working hours, or delivery date of a project or milestone. It is not in any sense a commitment, any more than estimating the temperature outside this afternoon is a commitment.

As the word implies, a customer reasonably expects the actual value to vary somewhat, in either direction, from the estimate. In fact, if an estimate turns out exactly match the actual result, there is a good chance the books have been cooked. Moreover, if the work is completed at-or-before the estimate most of the time, this means the estimates (on average) are too high.

An estimate “costs” nothing, other than the time/effort required to create it, which consists of analyzing the work at hand, decomposing it in to parts, and comparing those parts to past work.

Promises

A promise, also called a commitment, deadline, quote, fixed price, etc. is a different beast entirely.

With a promise in hand, a customer should expect with high confidence that the actual value (for cost, hours of work, delivery date) will be less than (before), or equal to, the promised value/date.

Be wary of a promise easily made and freely given: it probably doesn’t mean anything at all. A wise customer (and I aim to count myself in this category) should expect that a casually made commitment will probably be broken; not because the maker is morally defective, but simply because meeting a commitment for complex work requires considerable effort and thought. Without evidence that happens, it would be mere wishful thinking to expect the results delivered as promised.

Likewise, keeping promises often has a cost. If the work underway gets behind the schedule needed to meet the promise, something will have to give:

• Other work may fall behind, as time and effort are diverted to meet the promise.
• Weekends, evenings, and overtime work may be needed. These might appear free, but are not.
• Staff may need to be reassigned, or added
• Additional hardware and software may be needed.

These risks cost real money; thus a wise promise-maker will find that, on average, it costs more to promise feature X by date D, than to delivery feature X by date D without such a promise.

Estimates are Cheaper, so Prefer Estimates

At Oasis Digital, we provide many estimates, but few promises. Most of the time, an estimate is what our customers need; and we can provide at estimate with very little cost. Typically we estimate reasonably well:

• small features usually arrive with a day or two (plus or minus) of the estimated delivery date (and likewise for cost)
• medium items within a week or two of the estimate, likewise
• large items (major new features or subsystems with complex interdependencoes) within a month or so, likewise

The key here is is that with good estimate, commitments (promises) aren’t needed very often, and therefore the cost of promises can be avoided.

But Learn How to Promise Well, Also

Yet occasionally, a customer needs a commitment, most often because a software version needs to be available to match an important business event with a fixed date, such as a presentation, a legal filing, etc. I’ll follow up later (no promise or estimate, as to when) with thoughts on:

• how to credibly make promises (as a service provider)
• how to evaluate promises (as a customer)

I had an intuitive feel for many of his conclusions already, and had numbers to back that up on a small scale (as a customer of cloud services, and provider of SaaS services, and employer of people who operate systems). But I am very pleased whenever an opportunity comes along to replace intuition with data.

I won’t attempt to repeat his ideas here. I will simply recommend that you watch this (and other similar analyses) and get a decent understanding, before purchasing or deploying any in-house, self-hosted, or self-managed servers. The latter still makes sense in some situations, but in 2010 the cloud is the default right answer.

A number of the ideas he presents are iconoclastic; some popular trends, especially in enterprise data centers, turn out to be misguided.

Part of the challenge of running a software development consulting firm, is the tension between:

1) Focus on Customers You Have Now

Some firms are so service-delivery centric (#1 above), that they don’t bother to address the rest of the world, i.e. all of the not-customers-yet. Small consulting firms are especially vulnerable to this, and as a result they stay small.

Historically, Oasis Digital started in this category, with long-term projects, satisfied customers, and slow/organic growth. The shape of our organization reflects this: everyone, including me, works mostly on creating software for customers.

2) Focus on Customers You Want to Have Later

Some other software firms are highly marketing-driven, to the extent that their service delivery value proposition (in terms of design, features, and quality per customer dollar spent) suffers. Large technical service firms are especially vulnerable to this. Anyone who has been around the block a few times, has experienced the unique joy of a very large sum spent with a very large vendor to deliver sufficient, but disproportionately expensive, results.

Turning Up the Heat

Our goal and challenge now, is add a bit of focus on future customers (which is to say, marketing, community participation, etc.), without losing our service delivery mojo. To move things in that direction, we need at least one person who is not occupied by service delivery… hence our upcoming hire.

We will also quite likely start another software product or SaaS business along the way. (I’ve been there before, of course, and did plenty of hiring and business development work along the way.)

Some Things Won’t Change

Since inception, our sales process has been decidedly non-traditonal:

• We encourage potential customers to meet their needs with off-the-shelf software, not custom software, if possible.
• We don’t have commissioned salespeople. Nor commissioned pretend-they-aren’t-salespeople.
• Most of our team is, and will always be, all about delivering great results for our customers.

I’d love to receive feedback on this, from those of you with experience in this particular transition. You know how to reach me.

Update: We’ve filled the need for that job post, with a combination of a few people, rather than a single jack-of-all-trades as I had planned.

Still, there are useful ideas in here, so I’ve reposted it here.

Why Choose Custom Software?

To meet the software needs of your business, there are two main paths:

1. Buy software “off the shelf”
2. Build custom software (in-house, or with a development firm)

In most cases, off-the-shelf makes the most sense, and it should be your default choice:

• Acquiring and deploying off-the-shelf software is usually faster than getting custom software developed. Even complex installation and configuration it typically faster than developing new software.
• Off-the-shelf software is generally cheaper than developing your own. The development cost of an off-the-shelf package is distributed among multiple firms, possibly many firms worldwide. These many customers more than offset the extra cost of mass production and distribution. Comparatively, with custom software your business alone bears most of the costs.
• Off-the-shelf software typically has years of testing and years of production use, as well as feedback and improvement, giving confidence that it actually works.
• Off-the-shelf software may include a money-back guarantee in case it does not meet your needs.

For all these reasons, the option of designing custom software bears the burden of proof in your decision-making process.

There are good reasons, though, to consider custom development, especially in mid-sized or large companies. Under the right circumstances, these advantages can make the decision to develop software the best choice.

Exactly the Software You Want

With off-the-shelf software you start with the features the vendor chose, and then perhaps try to persuade the vendor to add additional features. You may or may not convince the vendor that the features you want are worthwhile and in their interest. Moreover, the features may turn out to be a mirage:

• The features might not actually work.
• The features might work but still not meet your needs.
• The features might interact with each other badly, even though they work in isolation.

Custom software, though, is almost infinitely adaptable to your needs. A custom development firm will develop the features you request, and will make them interact properly for your specific needs.

Top Notch Support

An off-the-shelf package typically offers some level of support. Virtually every vendor will claim to provide excellent support, but you will not know about the quality of the support until you need it. At that point, it is usually too late to undo your purchase decision, leaving you stuck with a frustrating shortage of real service. Your support contacts might lack knowledge of your problem domain, of your specific usage of the software, or might even lack good English skills. An off-the-shelf vendor’s highest tier of support may prove insufficient for software that you use to run your business.

With custom software, you can generally get in-depth support from the team who creates and maintains the software. Such a team can offer in-depth expertise, and the ability to not merely work-around problems, but also enhance the custom software on-demand to solve them.

Change Happens

The needs of your business are likely to change and expand. An off-the-shelf software package might leave you stuck with features that no longer work well, and require a “forklift upgrade” to move forward.

Custom software, though, can be continually enhanced to meet you growing needs, incrementally, so that users are never forced to violently switch to an entire new system.

Custom Software can be Cheaper!

Off-the-shelf software is cheaper most of the time, but not always! Occasionally, custom can be less expensive. How can this happen?

• The best off-the-shelf package still requires a great deal of customization.
• The best off-the-shelf package requires a great deal of changes to your business.
• The off-the-shelf package with the features you need, is prohibitively priced for a higher market tier.

More than once, Oasis Digital has created custom software for our clients which solved their specific problem at a lower cost than their off-the-shelf options. In one such case, our client needed a highly flexible rules-based system for calculating their sales quotations and product configurations. This sort of function is typically available in large Enterprise Resource Planning (ERP) systems. The ERP systems they found with the required flexibility, were high-end packages aimed at large enterprises, with a price to match. But they did not need such a system, they needed only the specific features for sales quotations and product configurations. Oasis Digital’s custom solution met their needs at an attractive price.

To Get Different Results, Use Different Software

If you are running a for-profit business in a competitive industry, you have an added incentive to consider custom software. With off-the-shelf software, you will end up using the same software that your competitors are using. Why play on a level playing field when you can develop advantages that are unique to your way of doing business? If you have proprietary ideas or processes in your business, custom software can capture those processes, amplifying your ability to operate more effectively or efficiently than your competitors.

Create a Corporate Asset

Custom software becomes a corporate asset. This can benefit you in several ways.

In the event of a company sale, your custom software adds to your unique operating capabilities, potentially giving you leverage to ask for a higher price.

Alternatively, your custom software might become an asset you can re-sell to others in your industry.

Choose Wisely

Two pages later, the point at the start is still correct: prefer off-the-shelf software. But once you consider all the factors, custom software might be the right decision for you.

(This article is also available as a PDF download: Custom Software: Foolish or Brilliant? )

Since then, my own focus has expanded, and is as much on the business of software and related technology as on the technology itself, along with occasional posts about neither of those things. So today, I’ve changed the tagline to “Software, Business, and Life”.

If you have a suggestion for a catchier tagline, I’m all ears.

In 2004, I co-founded a vertical market Software as a Service firm, Mobile Workforce Management (MWM). MWM serves the underground utility locating industry with a Software-as-a-Service offering, TicketRx. Most people interact with this industry only with an occasional “call before you dig”, and think of it as just a phone number. However, there is a lot more to that industry than a phone number; there are numerous companies involved, each interacting with the others to complete the work. It is a vertical market niche with specific software needs, which our product met.

I personally wrote and administrated the first version of the TicketRx software and the first few servers, and my cofounder personally performed analysis, support, documentation, operations, and mountains of other work. We then incrementally hired a team to expand our capacity (and make ourselves replaceable), building an organization to serve its customers. Our software startup became an operating business with a life of its own.

Fast forward… five years of incremental and accelerating growth…

In 2009, the opportunity presented itself to sell MWM, and we did so. MWM is still there, operating fine without me. The press release about the sale is online and is also reproduced below. It is amusing to see how PR-speak invaded, labeling TicketRx as “custom” even though its whole essence was to not be custom, but rather off-the-shelf and highly configurable. Perhaps it is custom in the very broad sense of being industry-specific.

As is common in deals like this, the “terms of the transactions were not disclosed”, along with many other interesting bits. Still, I have a great number of lessons-learned to share in future posts and talks; and as of early 2010, there is extensive information about the product itself on the company’s web site, http://mwmsolutions.com/

Where does that leave me?

For some reason, the notion of having two companies then selling one, has been surprisingly hard to communicate. I still own Oasis Digital Solutions Inc., a consulting / custom software development firm, and work more intensely than ever with its customers and developers. Oasis Digital is growing up rapidly, with marketing efforts and ever-increasing process and organizational maturity.

Growing a product/SaaS business was a great experience, and one I hope to repeat. I’m actively on the lookout for another non-consulting software business to launch, when the time and opportunity are right.

St. Louis-based MWM sold to Consolidated Utility Services Inc.

Custom software product TicketRx, provides cost effective job tracking for utility locating company

Jan. 19, 2010: ST. LOUIS, Mo. – St. Louis-based Mobile Workforce Management has announced the successful sale of its company assets, including its commercial software as a service product, TicketRx, to Consolidated Utility Services Inc., an underground utilities locator company based in Omaha, Nebraska.

“With TicketRx, we created a customizable system to provide field service staff remote access and management tools for receiving, routing and tracking tickets and job assignments in real time,” said Kyle Cordes, a principal of Mobile Workforce Management (MWM) and owner of local consulting firm Oasis Digital. “We started TicketRx in 2004, and experienced great success with over 1,000 users and a growth rate of 25% per year.”

The sale of TicketRx to Consolidated will allow the company to integrate the system into their full spectrum of services that serve to protect utility companies’ underground infrastructure. In addition to ticket tracking, Consolidated offers clients systems for locating utilities, performing field audits and managing claims.

“Creating a comprehensive software solution such as TicketRx that fulfills a complex set of needs and watching it operate successfully is a very rewarding experience,” said Cordes. “I am confident the custom software solution we developed will make Consolidated’s business stronger.”

TicketRx processes one-call tickets from ‘call before you dig’ call centers or utility companies and then routes the work to the appropriate field worker. Technicians have immediate access to the information they need, which improves on-time performance. And managers have easy-to-use tools for scheduling, balancing work loads and providing emergency notifications. The system tracks all activity on the ticket, which can be used to create invoices and reports.

TicketRx is a Software as a Service (SaaS) model, a growing trend in which companies are adopting easy-to-use services that can be integrated efficiently, with minimal risk and at a cost advantage. With SaaS companies can have the service they need without the responsibility for their own internal servers, data centers or related IT staff, saving them time and money. According to industry analyst firm Gartner by 2010, 30 percent of all new software will be delivered as a service

Since the sale of MWM, Cordes will focus his energies on Oasis Digital. “The sale of MWM and TicketRx allows us to concentrate our efforts first on our consulting clients here in St. Louis and elsewhere, then later on our next SaaS opportunity,” Cordes said.

About Oasis Digital Solutions Inc.

St. Louis-based Oasis Digital develops custom software for workflow management, application integration, business process automation, and handheld devices for companies nationwide. Oasis Digital can produce a whole project or subsystem depending on the needs of the client, using a variety of computer languages and technologies. Fore more information, visit www.oasisdigital.com.

About TicketRx

TicketRx is a product of Mobile Workforce Management, LLC, and is a software-as-a-service program for the underground utility locating industry that can manage locating tickets from one-call centers or directly from the utility companies. TicketRx offers a unique combination of a broad feature set, fast setup and quick learning time. For more information, visit www.mwmsolutions.com/ticketrx.