mult.ifario.us

I should preface this entry by noting that I am neither a lawyer nor an accountant. Rather, I've spent plenty of money on the services of both, and I'm willing to share my recollection of some of the things I've learned along the way.

Failure, i.e., non-success, is one of the things to plan for in any entrepreneurial activity, and when raising an angel round, i.e., investment from accredited individual investors, it is possible to engineer the round so that the investors get some generous downside protection from the tax code. Specifically, Section 1244 allows investors who sell their stock at a loss to deduct the loss. Under certain assumptions about the financial circumstances of the individuals, that means that they will lose no more than 65% of their original investment, providing that investment is less than $50,000 if they're filing singly or $100,000 if they're filing jointly.

If you're planning an angel round, ensuring that the investors are eligible for Section 1244 treatment would be a good idea. The burden of proof for Section 1244 rests on the company, but those records (Board minutes, financials, tax forms, annual reports, state and federal filings) are things that you should be keeping anyway.

With FiveSight's users almost entirely switched to non-Microsoft operating systems (namely, Mac OS X and debian Linux), it's an opportunity to ditch Microsfot Word entirely. (As little as I like Word, I like even less the use of .doc as the standard interchange format for business.) Using L_AT_EX for documentation makes good sense, since the output via PDFL_AT_EX is beautiful and portable. Moreover, both L_AT_EX and tools to edit it (i.e., Emacs with AUCT_EX) are generally available. Product documentation, Board minutes, and corporate letterhead were the first to go, and now contracts and other legal documents are following.

One of the challenges was signature blocks for contracts, but L_AT_EX's tabular* environment makes it easy:

\begin{tabular*}{\textwidth}% =396pt in this case
{@{} \p{180pt} @{} \p{36pt} @{} \p{180pt} @{}}
& & \
\includegraphics[scale=0.10]{../images/fmugwump_signature.pdf}&
& \ \cline{1-1}\cline{3-3}
{\small By} & & {\small By}\
& & \
Farquar T. Mugwump, Esq. & & \ \cline{1-1}\cline{3-3}
{\small (printed)} & & {\small (printed)}\
& & \
Chief Foobar Officer & & \ \cline{1-1}\cline{3-3}
{\small Title} & & {\small Title}\
& & \
Newcular, LLC & &  \ \cline{1-1}\cline{3-3}
{\small Company} & & {\small Company} \
\end{tabular*}

At least in my book, that beats mousing around for 15 minutes...

While it was a trickle at first, comment spam ramped up to 100+ per day in the past couple of weeks, so I bit the bullet and learned how to install WordPress plugins. That may not sound like such a big deal, but I don't know PHP and have absolutely no desire to learn. In fact, I have so little desire to learn PHP that I thought briefly about switching to NewsBruiser (which is written in Python, a language I know, and offers a bayesian filter for comments) or even Movable Type (which is written in Perl, a language I used to know), but in the end, suffering a little PHP was more palatable than the thought of migrating content, proxying permalinks, and learning yet another weblog server.

All in all, it turns out to be trivial — there is a WordPress "CAPTCHA" plugin called "authimage" that does the job. Even though I had to make some simple changes, installing it took all of 20 minutes, including installing a couple of necessary debian packages -- and I still don't know PHP.

Some deep thoughts from Eric Newcomer:

The most significant innovations are over. Some would call this the "death of software." But only as we know it. Software will continue. But we are not likely to have any new languages, or see any significant new inventions. Twenty years ago no one knew what a database was, or middleware, or Java. But now I think innovation like that has stopped because IT doesn't need it any more.

Maybe Eric's right. There comes a point in any given field of inquiry where all of the questions with good ratios between effort and effect are answered, and the remaining questions are sharply partitioned into trivial or imponderable. Knowing when a field is empty is more art than science, and the only heuristic that I can think of is when the same unsolved problems (e.g., P vs. NP) keep coming up over and over.

Or, maybe Eric's wrong. Databases, message queues, and application servers are everywhere, but enterprise software and the practices that surround it as a discipline are at the level of stone knives and bearskins -- things are different but not necessarily any better than when the The Mythical Man Month was written.

For example, there is a huge, open green field waiting for innovation in constructive approaches to model checking for distributed systems. See BLAST or BOOP to see what's being done for straight C programs, and there are similar efforts underway for OO systems and orchestration languages like BPEL.

I do think Eric's right in the sense that incremental advances, like the database evolving out of a progression of data management libraries, are more or less at an end. From here on out, incremental advances will provide incremental benefit. To take a leap forward, there is a real need for software engineering, by which I mean a sort of applied computer science that fuses the discipline, depth, and rigor required to attack hard problems with the practical concerns of software at large and the savvy to spot the real problems hiding in the woodwork.

Microsoft has the vision and resources needed, as do, to a lesser extent, other majors like IBM and HP, but the first open problem to solve may be to find a way to marry entrepreneurship with the economic and intellectual climate to create the next kind of innovation.

As the saying goes, "Live by the MSWord, die by the MSWord." FiveSight has accululated, between corporate infrastructure (articles and bylaws, filings, Board minutes, options plans, investments, employment agreements) and business relationships (licenses, support agreements, services agreements, distribution agreements) an entire filing cabinet full of legal documents, and all of it was written in Microsoft Word.

I'm no fan of Microsoft Word to begin with, and I share the sentiments of those people who think that the use of .doc as an exchange format is ridiculous.

I was swimming through a 45-page contract a couple of weeks back, and hours of time spent unraveling track changes, fixing romanette references, and other low-grade psychological torture over the years came flashing back. Contracts are just the tip of the iceberg, since more complex filings and briefs require tables of contents, references, and other things that are an absolute mess in Word. There must be some way to convince lawyers to start using TeX, although it looks like some already have. We could call it... L_AWT_EX...

According to the greeting card companies, October 16 was Boss's Day. I don't have a boss the rest of the time, but I decided to get one for the occasion.

In an earlier entry, I commented on an IllegalStateException that can occur when the SAX NamespaceSupport helper class is used incorrectly. (A common scenario for this exception to occur is a newer set of SAX APIs and an older parser, e.g., Crimson, but any code that used NamespaceSupport to track namespaces is susceptible.) I also offered some suggestions about proper usage of NamespaceSupport for writing SAX handlers, but those suggestions were incorrect for the current version of NamespaceSupport.

As the Javadocs for the current version of the class state, it is intended for use by parsers as a convenience between when the start of an element is detected while scanning the input and when the startElement event is generated. Put another way, the lifecycle of a stack frame in NamespaceSupport is the lifetime of a startElement event in the parser, while the desired lifecycle of a set of namespace declarations for the purposes of a handler spans from the start element that declares the namespaces (and inherits their predecessors) to the end element that moves them out of scope.

Thus, the better practice is:

Do not use NamespaceSupport to track namespace bindings in a SAX handler implementation.

Instead, you'll have to use something like this.