Tuesday, November 25, 2014

One Prototype Is Worth A Dozen Meetings

When I founded my company in 1995, things were different. The legal and tax classification of limited liability company was brand new, and there was so little legal precedent concerning LLCs that the best legal and tax advice I could get was to stick with a subchapter-S corporation or S-corp. The World Wide Web existed, but barely, so none of the incorporation process was online. I had to register actual physical paperwork, my articles of incorporation, with the state of Colorado. It was the same when I applied to the Internal Revenue Service for an Employer Identification Number, which is like a Social Security Number except for companies instead of people. The process was complicated enough that I used a firm that specialized in dealing with all that bureaucracy to guide me through it.

And, most shockingly, Google didn't exist. And wouldn't exist for years. I outsourced my email handling to a local service provider to which I connected (and still do today) via arcane protocols like SMTP,  POP and IMAP. My desktop was an Apple Macintosh Classic II, and the Linux distro I ran on my Dell server was Yggdrasil.

The entire process, both the business side and the technical side, took weeks to get set up and running, culminating in the creation of the Digital Aggregates Corporation nineteen years ago this month.

Just the other day I had suggested to one of my long-time clients that it might be a good idea to create a different company under which to productize and market some of the awesome intellectual property they had created as collateral from one of their projects. The more I thought about it, the more I realized that I really had no idea the magnitude of what I was suggesting. But I was pretty sure that it would be a whole lot easier today than it was in 1995.

There was only one way to find out.

Here's the thing: I'm a very hands-on learner. For me to understand something, I have to actually do it, touch it, play with it. For sure, I want to understand the theory behind it, and build my own abstract mental model of it, but I'm not going to be able to internalize those things and make them a part of me until I have my hands on it.

And that includes code. Until I suck the code base into Eclipse, peruse it, build it, install it, run it, until I look at your schematics, and then lay my hands the actual hardware and apply power to it and see some LEDs blink, it's all too theoretical for me. By which I mean, I can't claim to have any expertise in it or knowledge about it.

I have thirteen projects hosted on GitHub -- and a few more that are not -- all of which are the result of me deciding something like "Well, I guess I'd better learn Python." Thousands of lines of working code later, I feel that I can claim with a straight face to know a little Python. For me, just reading a book is not going to cut it.

It is the same for me in business. That's why I created Digital Aggregates all those years ago. I had some vague notion that maybe it would be a way to earn a living someday, but mostly I did it just to see how it was done.

So I decided to create another company.

Disclaimer: I'm not a lawyer, nor a tax accountant.  But I know people who are, from whom I get good advice. Before setting off on a new business venture, do what I did when I first incorporated in 1995, and talk to some experts.

First, I got out a few of my favorite coffee table reference books, ones with beautiful color pictures of largely historical artifacts, and started picking out potential domain names. All the good ones are already taken, of course. I didn't want some high falutin' name like "Framistat Systems" or "Extremely Awesome Products". I wanted something short, one word. It would be nice if it were pronounceable, but it wasn't a deal breaker. And in order to have some business credibility, it had to be in the .com top level domain. I made a list.

Next, I went to my domain name registrar, Network Solutions, and starting searching. To no one's surprise, the very first one I tried, gladius.com (gladius being the Latin name for the short sword used to such good effect by the Roman soldiers of ancient times), was taken. By LucasFilm. Bet there's a story there. I only went through a handful before I found one on my list that was available. I immediately registered cranequin.com, plus some additional services, for an annual cost of around US$45.00.

Crossbow winder (cranequin) by Ulrich Wildisen, Switzerland, c. 1550 - Higgins Armory Museum
(credit: Wikimedia)
Cranequin, if you mangle French like I do, is pronounced something like "krwa-ne-ke(n)" where that final nasal "n" is not even really said aloud. A cranequin is a mechanical winding apparatus used to draw back the bow on the kinds of crossbows you might use to take down large game. Or a man in armor.

Cranequin (Rack & Pinion)
(credit: Wikipedia)
The limited liability company now has a long history of success as the preferred organization for small businesses. And for a long time now, the State of Colorado allows you to file pretty much all your business paperwork online, something I have to do once a year or so, so I knew exactly where to go. It has become obvious to me over the years that both the State of Colorado and the U.S. government really want you to start a business, and they make it remarkably easy to do so. I established that Cranequin LLC was available as a business name in Colorado, so I submitted the electronic form to create it. After just a few minutes and US$50.00, I had my Colorado business identification number. In the eyes of the law,  Cranequin LLC is a wholly owned subsidiary of Digital Aggregates.

Then I went to the Internal Revenue Service web site and with some judicious searching figured out that I probably didn't really need a separate EIN, but it would probably make my tax accountant happy. So with the information from the State of Colorado web site in hand, I registered Cranequin LLC with the IRS and had a federal tax identification number for it. No charge.

Next stop was to Google to set up all the technical infrastructure like electronic mail in their cloud, for the cost of US$5.00 per user per month. There's an annual plan too, which saves you US$10.00 per user per year, but I decided to stick with the pay as you go plan. I was already familiar with the Google's Apps for Work from using the service at one of my clients. It seemed like the obvious choice for a tiny startup (and maybe now for large organizations as well). By far the hardest part of this step was having to laboriously edit the MX DNS records via the Network Solutions website to point electronic mail addressed to cranequin.com to Google, and then learning patience because it takes a while for everything to propagate across the interwebs.

I had already purchased web forwarding from Network Solutions. I hacked at the Digital Aggregates web site to create a really basic home page, nothing more really than a place holder. Then it was back to the Network Solutions website to set up the web forwarding, and www.cranequin.com was born.

Cranequin

All told it took about six hours total, spread across three days. I registered the domain name on Sunday, did the stuff with the State of Colorado, the Internal Revenue Service, and Google on Monday, and the home page and web forwarding on Tuesday. Everything was done online over a web interface. No paper, no signatures.

The up front costs were US$50.00, and the annual costs look to be about US$160.00 for domain services and (so far) two email users. If you do your own tax returns, that's probably it. I piggy backed Cranequin LLC on the same mailbox I rent for a mailing and shipping address for Digital Aggregates Corporation.

Will I keep my little prototype limited liability company? For a while at least. After all, when I created Digital Aggregates Corporation as an experiment, I really had no idea that years later it would become the principle mechanism though which I made a very good living. Maybe I'll have similar success with Cranequin LLC.

Saturday, November 08, 2014

Unintended Consequences of the Information Economy

William Lynn, former Deputy Secretary of Defense in the Obama administration, writes in the journal Foreign Affairs on how the transition from a manufacturing economy to an information economy has affected the U.S. Department of Defense in "The End of the Military-Industrial Complex".
For more than a decade, U.S. defense companies have been lagging further and further behind large commercial companies in technology investment. Although the Pentagon historically exported many technologies to the commercial sector, it is now a net importer. Indeed, next-generation commercial technology has leapt far ahead of what the defense industry can produce in areas spanning 3-D printing, cloud computing, cybersecurity, nanotechnology, robotics, and more. In addition, commercial information technology dominates national security today as much as it does the private sector. Soldiers now use smartphones to gather real-time surveillance from drones and send messages to fellow soldiers. 
Keeping up with commercial innovations will be difficult, if not impossible. The combined R & D budgets of five of the largest U.S. defense contractors (about $4 billion, according to the research firm Capital Alpha Partners) amount to less than half of what companies such as Microsoft or Toyota spend on R & D in a single year. Taken together, these five U.S. defense titans do not even rank among the top 20 individual industrial investors worldwide. Instead of funding R & D, defense companies have been returning the overwhelming majority of their available cash to shareholders in the form of dividends and stock buybacks. As a result, from 2000 to 2012, company-funded R & D spending at the top U.S. defense firms dropped from 3.5 percent to roughly two percent of sales, according to Capital Alpha Partners. The leading commercial companies, by contrast, invest an average of eight percent of their revenue in R & D.
Lynn opens with the example of Google's purchase of Boston Dynamics, the robotics firm that designed, among other devices, the BigDog, the four-legged load carrying robot. BigDog was originally funded by the U. S. DoD. Google announced that while they would honor Boston Dynamics existing military commitments, they would not be seeking further work from the DoD. Google basically reached into their deep pockets and pulled the advanced robotic technology rug right out from under the Defense Department.

Lynn identifies several trends that may be ending the Military-Industrial Complex as we have come to know it. High tech companies are reticent to reveal what may be valuable intellectual property to the U. S. government. They don't see a reason to have to deal with the vast government procurement and contracting bureaucracy when more money can be made more easily in the commercial space. Commercial companies increasingly exploit globalization, manufacturing goods or building research facilities overseas where it makes economic sense, something the U.S. military is understandably reluctant to do for both national security and political reasons. Lynn talks about how the Defense Department is going to have to come to terms with these trends unless it wants to lose its technological advantage.

What Lynn doesn’t talk about (but probably knows): in the 21st century information economy, the key component to growth isn’t enormous capital investment in manufacturing capacity, something the military establishment used to good effect during World War II, but instead enormous people investment in innovation capacity.

Just yesterday National Public Radio ran a story on this very topic: "Future U. S. Manufacturing Jobs Will Require More Brain Than Brawn". Planet Money's Adam Davidson remarks on how this is affecting the world of work.
If you want to succeed for the coming decades, you don't just need to be trained and then a few years later retrained. You need a continuous improvement in your education. The main skill you need is the skill to learn more skills. The one certainty we have is manufacturing is going to look more and more like computer programming and engineering. It's going to involve a lot more brain work and a lot less brawn work. And that means probably a smaller number of people can benefit, but those who can benefit will probably benefit quite a bit.
The DoD can’t just dial up more innovation capacity by throwing money at the problem, like they did in WWII. Nor, in a free country, can the U. S. government just mandate for whom companies choose to work. Innovation capacity requires not only brilliant engineers, who are hard enough to come by, and who cannot be easily identified in the job market, but also a willingness to accept a lot of risk: to try and perhaps to fail, over and over. To old school 20th century managers, this looks a lot like waste, but in fact it’s a necessary part of the innovation process. The economics of conflict is changing just like the economics of everything else is changing. It’s as if one smart guy with a laptop, some open source software stacks, and a 3-D printer, can now manufacture hydrogen bombs.

The DoD has to start thinking more about leveraging not just globalization (like, as Lynn suggests, by buying German-made artillery), but also consumer technologies where there are enormous economies of scale (so they’re relatively cheap compared to specialized albeit low volume goods), not to mention more profitable than the DoD could make it for the contractor. The days of the DoD calling the shots in high-tech are over. Global market forces are going to make the decisions about who makes what and for whom.

My career, so far spanning four decades, has been distributed among academia and big science, defense contracting, and commercial high-tech product development. While the transition to the information economy has been very very good to me, I've been thinking about Lynn's article a lot lately, and what it means for my life, my colleagues, my clients, and my country.

Monday, September 29, 2014

What You Don't Know Can Hurt You

Below is a little snippet of C code from [Krebbers 2014]. Peruse it and see if you can predict what two values it will print. It's only a handful of lines long. Go ahead, take your time. I'll wait.

#include <stdio.h>
void main() {
    int x;
    int y;
    y = (x = 3) + (x = 4); 
    printf("%d %d\n", x, y); 
}

So let's compile it on my build server that's sitting a few feet away from me. It's a Dell x86_64 system with four 2.4GHz Intel cores running Ubuntu 14.04 with the 3.13 Linux kernel and the GNU 4.8.2 C compiler. It's old but still mighty.

coverclock@ubuntu:~/src/misc$ gcc -o foo foo.c
coverclock@ubuntu:~/src/misc$ 

Good; no warnings, no errors.

coverclock@ubuntu:~/src/misc$ ./foo
4 8
coverclock@ubuntu:~/src/misc$ 

Huh.

This code isn't multi-threaded. It's barely single threaded. In fact, the code snippet is so simple, it hardly qualifies as anything beyond the classic "Hello World!" program.

Here's the thing: you may have gotten completely different results, if you used a different compiler. Or a different version of the same compiler. Or maybe even different compiler options for optimization or debugging levels. As Mister Krebbers points out in [Krebbers 2014]:
By considering all possible execution orders, one would naively expect this program to print 4 7 or 3 7, depending on whether the assignment x = 3 or x = 4 is executed first. However, the sequence point restriction does not allow an object to be modified more than once (or being read after being modified) between two sequence points [ISO C, 6.5 p. 2]. A sequence point occurs for example at the end ; of a full expression, before a function call, and after the first operand of the conditional ? : operator [ISO C, Annex C]. Hence, both execution orders lead to a sequence point violation, and are thus illegal. As a result, the execution of this program exhibits undefined behavior, meaning it may do literally anything.
Okay, so maybe not a huge surprise to folks who have memorized the ISO C standard. Or who are tasked with debugging problematic code by occasionally resorting to looking at the assembler code. Using a symbolic JTAG debugger that monitors the program at the hardware level, I've seen the program counter single step backwards in a sequential piece of C code, as the debugger traced the execution path the processor took through the optimized machine code and then tried to correlate it to the original source.

This is why you don't write tricky C code, playing games like trying to smash as much stuff into a single statement as you can. Because it can belie any kind of rational analysis. Because it becomes a debugging nightmare for the developer tasked with current engineering who comes after you. Because its behavior may change with your next compiler update. Or when it's ported to a project using a different compiler suite altogether.

Because it can bite you in the ass.

References

R. Krebbers, "An Operational and Axiomatic Semantics for Non-determinism and Sequence Points in C", 41st ACM SIGPLAN -SIGACT Symposium on Programming Languages, January 2014

International Organization for Standardization, ISO/IEC 9899-2011: Programming Languages - C, ISO Working Group 14, 2012

Lambda The Ultimate, "An Operational and Axiomatic Semantics for Non-determinism and Sequence Points in C", September 2014