Over the last six or seven years, I've painstakingly perused the facts and details of what it is that makes the federal income tax applicable to the salaries of average Americans. For some time I was caught up in the "tax honesty movement" that was the following of Bob Schulz, Joe Banister (a former IRS criminal investigator who discovered that the income tax as it is being imposed was being unlawfully applied and that the IRS themselves were the criminals), among others. I quit my job and went independent for several years, in large part (but not entirely) so that I could sit down and just focus on learning and understanding what's really going on, without concerning myself with the repercussions of potentially perjering myself by signing a Form W-4.

A Form W-4 identifies a person as an "employee", and willfully signing one legally binds a natural person to the role of an "employee". An "employee" is a legal term. The term is defined in 26 USC § 3401 as "... an officer of a corporation".

That's not the entire definition, but it is the part that applies. What the "tax honesty movement" proponents incorrectly assumed, and what I eventually began questioning and demanding an answer to (and didn't receive), was that this "officer of a corporation" somehow meant a "public officer", as in, the President of the United States, or a military officer, or an elected representative. This assumption proved bogus; I found no tie-ins to this rather generic verbiage with that interpretation.

In fact, the failure of the "tax honesty movement" community to answer this question resulted in my decision to go back and look for a W-2 job again, since I wasn't cutting it on my own and practically every well-paying software development or consulting opportunity out there was a W-2 job.

Since then, I've been trying to make sense of the mess that the withholdings system is and how liability applies. As posted on the mailing list I moderate, and as I concluded and documented, for the most part, over the last few years, here are my repeated conclusions:

1. Federal currency is a federal government fiction. Money in its current form is not a barter exchange, it is created from nothing and set into motion by people who use it. Paper money, digital bank dollars, it is all government-created fiction. As is documented by The Creature from Jekyll Island, money is created from thin air. The principle of "Render undo Caesar what is Caesar" applies, because even on a basic dollar bill, the names "United States of America" and "Federal Reserve" are spelled out, just as the face of Caesar was printed on the coin in Jesus's day.
   • What the proponents of the "tax honesty movement" suggest is that "We The People are the caesars" because we are a democracy or somesuch. This is nonsense; that logic only applies to barter exchanges between natural persons who are careful not to associate themselves with federal taxing jurisdiction.
   • The question becomes, is it just for a people's government to impose an existence or receipts tax upon its own constituents directly? Of course it isn't. But then, the use of federally created currency is a privilege, not a right.
   • I only make this point to set aside the arguments about common law rights. This does not discuss what was taxed, but only that the federal government has the common law right to impose a tax on the income of federal currency, which is put into check by common law limits on federal scope and by the Constitution.
2. Taxing jurisdiction is limited to federal jurisdiction. The rights of the constituents are reserved by the Constitution. The Sixteenth Amendment does not expand the scope of taxing jurisdiction. In order for the federal government to impose a direct tax upon its constituents' incomes, the constituents must already throw themselves into federally taxing jurisdiction.
   • What the proponents of the "tax honesty movement" suggest in error is that federally taxing jurisdiction is limited to the political and peacekeeping activities of the government.
3. Corporations are extensions of both state and federal government. They are legal fictions. They have become so pervasive in modern society that people don't really know how to accomplish anything as a group anymore, be it a church or other non-profit organization, or a for-profit group of people, without filing incorporation papers and then going out and seeking an EIN from the IRS.
   • "Upon the other hand, the corporation is a creature of the state. It is presumed to be incorporated for the benefit of the public. It receives certain special privileges and franchises, and holds them subject to the laws of the state and the limitations of its charter. Its powers are limited by law. It can make no contract not authorized by its charter. Its rights to [201 U.S. 43, 75]   act as a corporation are only preserved to it so long as it obeys the laws of its creation."  HALE v. HENKEL, 201 U.S. 43 (1906)
     http://laws.findlaw.com/us/201/43.html 
   • While corporations are chartered by the state, they are federally recognized legal entities. Were this not so, federal circuit courts and the Supreme Court would be incapacitated from allowing state-chartered corporations to represent themselves in their courtrooms, since each state could have its own definition of a "corporation".
   • With state-chartered corporations being federally recognizeable, federal laws that generically reference "a corporation" are not limited to the corporation that the United States is. ("United States" is the proper noun of the legal entity of the federal government.)
4. An employee is an officer of a corporation. All you need to do to be an "officer of a corporation" is to be identified as a part of the corporation, to represent the corporation, or to sit in an office building and be told what to do by the corporation. The federal government has identified a list of qualifications of what makes someone an "employee" as opposed to an independent contractor, which covers things like whether the worker can dictate his own schedule, provides his own tools, etc. There is a fine line between a "casual employee" and an "independent contractor", but it's not entirely a question of paperwork but of whether the corporation is treating the natural person as one of its own "gears".
   • "But individuals, when acting as representatives of a collective group, cannot be said to be exercising their personal rights and duties nor to be entitled to their purely personal privileges. Rather they assume the rights, duties and privileges of the artificial entity or association of which they are agents or officers and they are bound by its obligations." UNITED STATES v. WHITE, 322 U.S. 694 (1944)
     http://laws.findlaw.com/us/322/694.html
5. Signing a Form W-4 legally and immediately causes all personal rights to be relinquished and all laws applying to an "employee" to be activated. You cannot validly sign a Form W-4 without signing in the correct signature blank, and said blank is clearly labeled, "Employee's Signature". This form falls under the jurisdiction of 26 USC § 3402, and "employee" of "Employee's Signature" falls under the jurisdiction of § 3401.
6. The employer is liable for the employee's income tax. This is the kicker, the reason why I'm posting this. The "tax honesty movement" proponents argue that workers who file Form W-4 should tell their bosses not to withhold anything because they're natural people and exempt from taxing jurisdiction. The reality is that they are employed, and the employer is obligated to withhold. 26 USC § 3403 reads, "The employer shall be liable for the payment of the tax required to be deducted and withheld under this chapter, and shall not be liable to any person for the amount of any such payment." This is a one-two punch: first it holds the corporation liable for the employee's income tax withholdings, then it forces the employee (and thereby the natural person who signed Form W-4 identifying himself as an "employee") to allow the withholdings to occur.
   • The income tax in a W-4 scenario is applied upon the corporation, which both the employer and the employee are party to. The employer is held liable because the corporation is liable, and the corporation is liable because it is a government-created fictional legal entity.
   • The employee becomes liable, in a sense, because the employee is a "component" (a gear) of the corporation.
   • The natural person is not liable, but the natural person cannot demand the non-taxed, agreed-upon salary amount because the natural person signed the Form W-4 identifying himself as an "employee", which causes §3403 to apply: "The employer shall be liable for the payment of the tax required to be deducted and withheld under this chapter, and shall not be liable to any person for the amount of any such payment."
7. The income tax is imposed before the natural person is paid. When I get my paycheck, I receive my paycheck with taxes already withheld. The question becomes, who paid the tax? The common assumption is that I did. The reality is that the employer did, because only the employer is identified by law (26 USC § 3403) as being liable for the tax.
   • Q: If the natural person is getting paid less than the agreed-upon salary, why can't he just sue the company?
     A: Because the employee filed a Form W-4, which forces the natural person into the jurisdiction of the tax withholding laws of 26 USC § 3401-3406, and as such the natural person, being an employee because he signed Form W-4 identifying himself as an "employee", has his hands tied from holding the employer liable for the withholdings. §3403: "... and [the employer] shall not be liable to any person for the amount of any such payment [of taxes withheld]."
   • Q: If the taxes are imposed upon the employer, rather than upon payment to the natural person, then when a natural person later files a Form 1040 to receive a partial refund, why does the IRS recognize liability for the withholdings less exemptions?
     A: When a natural person identifieds himself with the W-2 when sending Form 1040, he has already assumed association with the corporation which is under federal taxing jurisdiction. The employer is liable, but the employee is under the complete and total control of the employer; being one corporation, they are legally one and the same. By being an employee, the natural person is an agent of the corporation, and the government can do whatever it wants with its own legal fictions. The withholdings are technically just the pulling of money out from one pocket (the employee's wages) and into the other (the IRS).
   • Q: Can't a natural person disclaim being an "employee" when contacting the IRS to receive a refund?
     A: Sure, but then if the natural person signed a Form W-4 identifying himself as an employee then he already perjured himself.
8. It's not a "sin" to file a Form W-4 or for taxes to be withheld. For a few years, I believed it to be perjury, and a sworn lie and therefore a sin, to file a Form W-4 because I was only looking at the first part the definition of "employee", which reads, "For purposes of this chapter, the term 'employee' includes an officer, employee, or elected official of the United States, a State, or any political subdivision thereof, or the District of Columbia, or any agency or instrumentality of any one or more of the foregoing.". When I examined the other part of the definition, "The term 'employee' also includes an officer of a corporation," and that this qualified me, I realized that it was "safe" to file a Form W-4 and to go ahead and have taxes withheld. Since then, though, some religious kooks among tax protesters have accused me of being hell-bound and a proponent of Satan because I pay the income tax. While such rediculous silliness would not normally be worthy of being heard or for that matter spoken of, the fact that I have a Christian background and that I participated in the discussions with the "tax honesty movement" and agreed and still agree that the IRS engages in highly deceptive collection tactics, leads me to pronounce that I don't believe it to be a sin to select the easier of two victimizations. It is better to pay an income tax on a high salary than to not pay income tax on very scarce opportunities. The real question is whether it is a lie to admit tax liability, which would be a sin. It took me some time to consider it, but I have concluded that it is not a lie in the case of a W-2 employee, because I believe that I qualify as "an officer of a corporation" by playing an employee's role in a corporation.
9. Income taxes are only "patriotic" when they are applied to the priviledges of the taxing society. This is simply an issue of scope. What if mom gives her little boy Bobby a sandwich? The sandwich has cash value of $1. What federal government privilege applies in that transaction? None. What if some Japanese company gives a Japanese employee a paycheck, what taxing jurisdiction does the United States have in that transaction? None. Federal taxing jurisdiction only applies to federally taxable activities, and there is no shame in engaging in a life that is not federally taxable.
   • Income taxes do not pay for roads, and they do not build weapons for militaries. That stuff is paid for with other taxes. Rather, the wasteful expenditures that Congress invents is paid for with money that is created out of thin air. Said created money is established by way of bank loans issued by a private banking cartel. The income tax pays interest on these loans. But technically, there is no limit to the amount of cash Congress can spend on whatever they want because of the blank check they have with the bank.
10. It is still possible and reasonable to be tax-free. The income tax as it is imposed today is still ethically wrong and it is only applied legally by way of discriminating paper trails, not by broad federal taxing authority. This is not to say that income taxes in themselves are ethically wrong (see #1 above), but rather I'm saying that the imposition of the tax as it is usually applied today is ethically wrong. It's not the practice of taxing but the method and the reason--the method being coercion, willful confusion, brainwashing, and propogation of false premises, and the reason being to only pay interest on the virtual bank loans to the private banking cartel that the Federal Reserve is, said loans being the method by which federal currency is created. Ethics aside, the only ways to live free of federal income taxes are to:
    • 1099-based consulting does not work because it invokes a Tax ID (the sharing of your social security number), which the corporation or individual that pays out will use to report you as a receipt of income paid out. This is a technically incorrect situation since compensation for valued work is a fair equal exchange (not income), but it is reported nonetheless, and the reporting is voluntary by you by your giving out a tax ID (a social security number).
    • Perform barter exchanges, privately, with people who have no intention of reporting the exchanges with the IRS. Trading books for food, fixing someone's roof in exchange for them letting you live under it, these kinds of things are cashless activities and are not taxable.
    • Working for hire is a form of a barter exchange, unless you're engaging in the priviledge of being an employee of a corporation. However, see #1.
    • Never use a social security number in the context of anything that can result in the receipt of federal currency or can be recognized by government as having cash value.
    • Stock exchanges, IRAs, bank savings accounts, bonds, social security, these are activities that are directly associated with the federal government or Federal Reserve.
    • Real estate is hairy because there are some very significant local laws pertaining to licensing, loans, and all kinds of hairy paperwork, but theoretically with great care it may be possible to live independently by helping people buy and sell real property without involving federal taxing jurisdiction.
11. The real question is, Is it worth it? Most of society settles for adhering to the brainwashing that the tax system consists of. It is very difficult to make a living without settling for engaging in taxable activities. For some time, as a Christian I had my doubts that perhaps following through as such was submitting to the Beast, that using the social security number was the equivalent of having the mark of the beast in one's right hand (the card, the pen) or on one's forehead (remembering the number). Perhaps I'm going to hell for this, I don't know. But I do know that the only way out is to live like the other 80-90% of the world's population--to be without a bank account, to live in a world where this kind of paperwork and these issues are not in the scope of the simple act of trying to survive. Short of throwing everything out and leaving the country to live some kind of life of poverty, though, I see no realistic way of surviving in this society comfortably and with peace of mind without submitting to the income taxation system.

In or around the year 2001, the dot-com bubble collapsed, leaving a multitude of quality software professionals completely jobless. This in turn not only resulted in a drought of opportunities, it became a buyer's market. People who got a job doing software development after 2001 were surrounded by either a lot of non-American workers or else some really incredible geniuses the likes of which one would typically only meet a few times in a lifetime.

Unfortunately, it occurred to me that the post-bust drought may have "spoiled" the people who were hired post-2001 and have sinced moved up and now been promoted into management roles. Their expectations for new employees are steep, and for a while there I thought that expectations were too steep.

But perhaps it's not them. It appears to be a seller drought. It's been getting frustrating. Lately I've been finding myself scratching my head and wondering, where did all the experienced software folks go, anyway? The people who could "speak our language". On my first professional job back in 1998 where I wasn't trying to just do my own independent thing, I was surrounded by people who even today as I look back on them would probably give me a rise, so to speak, on their capacity to contribute to our current team's success, on the assumption that they have since evolved with technology and are proficient at C#, et al. These guys were really geniuses. They could program routers, manage bulk solicited e-mails with sendmail, maintain e-commerce systems with ASP classic and VB5 components, maintain data and sprocs in SQL Server, manage complete data import/export suites with complex user interfaces written in VB, and most of them were very interested in getting away from the Microsoft platform and into "real" development with Java. We're only talking about two or three people here, but there were few of us, mainly myself unfortunately, who were behind on all this and lacked the proficiency to stay productive on a daily basis.

Nowadays, while I still get to work with brilliant folks, I'm noticing that people who are really deeply wrapped up into software are really very scarce. Most people seem to come in two flavours: people who use technology to accomplish business objectives, and people who use technology to win a paycheck. Both are just using software. But the true software enthusiasts are really very uncommon. They are easy to detect online because they typically push out really cool software and share them with the public, stuff like Rhino Mocks and SubSonic. (One of these days I'd like to re-add myself to the mix.)

But I suppose what has happened is that with the workforce expanding by x% every year on a consistent basis, particularly with the dot-com bust now in our history books and no longer fresh in last year's memories, there also comes an influx of dilution of talent. I have no doubt that the software enthusiasts of old are still around doing great things and making great software. They are just rarer now because the need for more people in the industry has resulted in a lot more "kids" like the one I was back in 1998.

On the other hand, the old geniuses and respectable pros have made livelihoods for themselves, and sadly that does not bode well for geek culture. And what about all the free-time geeks? Call me old skool, but there was a time when "average developers" would task ourselves with weekly "network load tests", otherwise known as Quake LAN parties in the office. I haven't seen that in years. Now and then I still come across someone who spends every hour after work playing World of Warcraft or something. But it seems like everywhere I look, I am surrounded by either "normal people" or else geeks and gadgetheads who have essentially abandoned all aspects of geekishness in order to accomodate a wife's new baby, or else they keep their geekish behavior to themselves. From what I've been been able to find, the days of getting a co-worker to stick around after 5:30 and fire up a game to play over the LAN seem to have all but disappeared. And it's not really just about games; I bring up games because people at the office do play games, but they keep it at home, and it's as though they're ashamed to suggest gameplay at the office after hours even though it's completely allowed and tolerated. Typically the excuse, though, is family calls, almost like nature calls. But I did come across someone today who actually really plays first-person shooters, and I was glad to discover it. There just might be some hope for this world after all.

(The suggestion that there is some kind of correlation between LAN gaming and being some kind of experienced software development expert is really just my way of laughing at my own curiosities. There is no correlation. I just wish that there was.)

At work, in any workplace really, the leaders and supporters (including myself, in whatever role I play as a consultant or software engineer or otherwise) are notably hindered and evaluated for the value of the work on a one-to-one basis of how spread out they are. I tend to look upon myself with shame, for instance, when I see myself as a "jack of all trades, master of none", which is something I really don't want to be. I'd much rather be "knowledgeable of much, master of much", even if "much" does not come anywhere close to "all". I feel like I should be able to afford that since I am single, have no life except the life in front of my computer(s), and my sole hobby is software. Even so, I struggle to master my skills and to stay on top of current technologies.

When we take our talents and spread them too wide in the workplace, we find ourselves making excuses for not taking the time to produce quality work. Mediocre output starts getting thrown out there, and no one is expected to apologize because everyone was too busy to take the time to pursue excellence in the output.

I've started to notice that the rule of "spreading yourself thin makes you worthless" is a universal truth that doesn't just apply to people but also to software. I've been "nerding out" on alternative operating systems so that's where I'm applying this lately. The Haiku OS project is distinct from some other projects in this way. Tidbits of wisdom like this have been sticking in my head:

http://haiku-os.org/documents/dev/what_are_you_looking_at

While we developers are used to getting into "the zone" and flinging code that (mostly) works way it should, this is not the kind of focus to which I am referring. When developing an application, the main thing that must not remain as the sole focus is the technology. Technology is the means to the goal. Should we focus on the cool stuff we can build into software, we lose sight of what it is ultimately supposed to do — just like running a marathon while staring at your feet, one tends to not see problems until one quite literally runs into them. What is the goal? The ultimate goal is to write good, fast, stable software which does exactly what it is supposed to do — and nothing else — while making it accessible to the intended type of person, and only one person of that type. 

This goes along with so many different ideologies in software architecture discussions that had me scratching my head as I had a hard time swallowing them, like, "Don't add members to your classes that are not going to meet the needs of the documented requirements, no matter how useful they seem." It took me a few days to accept that rule, because I constantly have ideas popping up in my head about how useful some method might be but I couldn't show for the requirement for it yet. But I later learned why it was an important rule. Once it gets added, it becomes a potential bug. All code is a potential bug. The bugs get QA'd on behalf of the requirements, not on behalf of the presence of the class members. Of course, TDD (test-driven development) and agile / XP practices introduce the notion of "never write code until you write a failing test", so that your new experimental method becomes integrated with the whole test case suite. But now you've just doubled to quadrupled your workload. Is it worth it? Well, it might not matter for a few simple methods, but if that becomes a pattern then eventually you have a measurable percentage of experimental code versus actual, pratical requirements implementations.

There is one thing to keep in mind about the above quote, though, and that is the fact that the above philosphy applies to applications, not to operating systems. The above-quoted article is about building user interfaces, which is an applications-level subject. Whereas, the operating system should have, at one level, a reverse philosophy: technology over function. But let me qualify that: in an operating system, the technology IS the function. I say that because an operating system IS and MUST BE a software runtime platform. Therefore, the public-facing API (which is the technology) is key. But you're still focused on the requirements of the functions. You still have a pre-determined set of public-facing API interfaces that were determined ahead of time in order to meet the needs of some specific applications functionality. Those MUST be specific, and their implementations MUST be strict. There MUST be no unsupported public interfaces. And because the OS is the runtime environment for software, the underlying technology, whether assembly code vs. C runtime API vs. Common Language Runtime vs. Java Virtual Machine, etc, is all quite relevant in an operating system. I'd say that it's only relevant at the surface tier, but it's also relevant at lower tiers because each technology is an integration point. In the Singularity operating system, for instance, which is 99.9% C# code, it's relevant down the deepest tier.

The reason why I bring up Haiku OS vs. other open-source initiatives, as if they had contrasting interests, is because they very much do. Haiku does in fact have a very specific and absolute milestone to reach, and that is compatibility with BeOS 5. It is not yet trying to "innovate", and despite any blog posts indicating opinions otherwise, that may in fact be a very good thing indeed. What happened with the Linux community is that all players are sprawled out across the whole universe of software ideas and concepts, but the end result is a huge number of instances of software projects, all of them mediocre and far too many of them being buggy and error-prone (like Samba, for instance).

More than that, Haiku, as indicated in the above quote, seems to have a pretty strict philosphy: "focus on good, solid, bug-free output of limited features, rather than throwing in every mediocre thing but the kitchen sink". Indeed, that's what Linux seems to do (throw in every mediocre thing but the kitchen sink). There's not much going on in the Haiku world. But with what little it does have, it sure does make me smile. I don't suppose some of that .. or maybe a lot of it .. has to do with the aesthetic design talent involved on the project. Linux is *functional*, and aesthetics are slapped on as an afterthought. Haiku appears at first glance as rather clean, down to its code. And clean is beautiful.

Going around adding futuristic stubs to code is something I've been guilty of in the past but I've found it to be a truly awful, horrible practice, so much so it makes me moan with disgust and terror. It makes a mess of your public-facing APIs, where you have to keep turning to documentation (and breaking tests) to discover what's implemented and what is not. And it leaves key milestone code in a perpetual state of being unable to be RPM'd (released to manufacturers). The best way to write software is to take the most basic functional requirement, implement it, test it thoroughly until it works in all predictable scenarios, add the next piece of functionality, test that piece thoroughly (while testing the first piece of functionality all over again, in an automated fashion), and so on, until all of the requirements are met. In the case of an operating system, this is the only way to build a solid, stable, RTM-ready system.

Microsoft published some beta Managed DirectX 2.0 code a while back, and I posted on their newsgroups, "Why on earth are you calling this 'beta' when the definition of 'beta', as opposed to 'alpha', is that the functionality is SUPPOSED to be there but is buggy? Only 'alpha' releases should include empty, unimplemented stubs, yet you guys throw this stuff out there calling it 'beta'. How are we supposed to test this stuff if the stubs are there but we don't know if they're implemented until we try them?" Shortly after I posted that rant, they dropped the Managed DirectX 2.0 initiative and announced that the XNA initiative was going to completely replace it.  I obviously don't think that my post was the reason why they dropped the MDX2 initiative, but I do think it started a chain of discussions inside Microsoft that made them start rethinking all of their decision-making processes all the way around (not exclusively, but perhaps including, the beta / alpha issue I raised). Even if just one of their guys saw my rant and thought, "You know, I think this whole MDX2 thing was a mistake anyway, we should be focusing on XNA," I think my little rant triggered some doubts. 

The React OS project also had me scratching my head. Instead of littering the OS with placeholders of wanted Windows XP / Vista UI and API features while the kernel is still painfully unfinished, which indeed I have observed, what the React OS team should be doing is saying, okay, we're going to set these milestones, and we're not going to add a single stub or a single line of code for the next milestone until the current milestone has been reached. Our milestones are specifically and clearly defined:

1. Get a primitive kernel booting off a hard drive. Execute some code at startup. Master introspection of the basic hardware (BIOS, hard drives, memory, CPU, keyboard, display, PCI, PCIE, USB controllers).
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
2. Basic Execution OS. Implement a working but basic Windows NT-like kernel, HAL, FAT16/FAT32 filesystem, a basic user-mode runtime, a basic Ethernet + IPv4 network stack, and a DOS-style command line system for controlling and testing user-mode programs.
   • This implements a basic operating system that will execute C/C++ code and allows for future development of Win32 code and applications.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!! 
   • Making this milestone flawless will result in an RTM-ready operating system that can compete with classic, old-school UNIX and MS-DOS.
3. Basic Server OS. Implement Windows 98-level featureset of Win32 API functionality (except those that were deprecated) using Windows XP as the Win32 API design and stability standard, excluding Window handles and all GUI-related features.
   • This includes threading and protected memory if those were not already reached in Milestone 1.
   • Console only! No GUI yet.
   • Add registry, users, user profiles.
   • Add a basic COM registration subsystem.
   • Add NTFS support, including ACLs.
   • Add Windows Services support.
   • Complete the IPv4 network stack, make it solid.
   • This implements a second-generation command-line operating system that will execute multi-threaded Win32 console applications.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!! 
   • Making this milestone flawless will result in an RTM-ready, competing operating system to Windows Server 2000.
4. Basic Workstation OS. Focus on Win32 GUI API and Windows XP-compatible video hardware driver support. Prep the HAL and Win32 APIs for future DirectX compatibility. Add a very lightweight GUI shell (one that does NOT try to look like Windows Explorer but that provides mouse-driven functionality to accomplish tasks).
   • This implements a lightweight compatibility layer for some Windows apps. This is a key milestone because it brings the mouse and the GUI into the context, and allows the GUI-driven public to begin testing and developing for the system.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
   • This milestone brings the operating system to its current state (at 0.32), except that by having a stricter milestone and release schedule the operating system is now extremely stable.
5. CLR support, Level 1
   • Execute MSIL (.NET 2.0 compatible).
   • Write new Windows services, such as a Web server, using the CLR.
   • This is huge. It adds .NET support and gives Microsoft .NET and the Mono project a run for their money. And the CLR alone gives understanding to the question of why Microsoft was originally tempted to call Windows Server 2003 "Windows Server .NET".
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
   • This introduces another level of cross-platform compatibility, and makes the operating system an alternative to Windows Server 2003 with .NET.
6. CLR support, Level 2, and full DirectX 9 compatibility
   • Execute MSIL (.NET 3.0 compatible), including and primarily
     • "Avalon" / Windows Presentation Foundation (XAML-to-Direct3D, multimedia, etc)
     • "Indigo" / Windows Communication Foundation
     • WF (Workflow)
     • .. do we care about InfoCard?

These are some really difficult if not impossible hurdles to jump; there isn't even any real applications functionality in that list, except for APIs, a Web server, and a couple lightweight shells (console and GUI). But that's the whole point. From there, you can pretty much allow the OS to take on a life of its own (the Linux symptom). The end result, though, is a very clean and stable operating system core that has an RTM version from the get-go in some form, rather than a walking, bloated monster of a zillion features that are half- or non-implemented and that suffers a Blue Screen of Death at every turn.

PowerBlog proved to be an interesting learning opportunity for me in this regard. There are a number of things I did very wrong in that project, and a number of things I did quite right. Unfortunately, the number of things I did wrong outweighed the other, most notably:

• Starting out with too many features I wanted to implement all at once
• Starting implementation with a GUI rather than with the engine
• Having no knowledge of TDD (test-driven development)
• Implementing too many COM and Internet Explorer integration points (PowerBlog doesn't even compile on Windows Vista or on .NET v2.0)
• Not paying close enough attention to server integration, server features (like comments and trackbacks), and Atom
• Not getting around to implementing automatic photo insertion / upload support even though I basically understood how it needed to be done in the blog article editor side (it was nearly-implemented on the MetaWeblog API side)
• Not enough client/server tests, nor mastery of C# to implement them quickly, nor knowledge of how to go about them in a virtualized manner
• Too many moving parts for a single person to keep track of, including a script and template editor with code highlighting

What I did right:

• Built the GUI with a specific vision of functionality and user experience in mind, with moderate success
• Built the engine in a seperate, pluggable library, with an extensibility model
• The product did work very well, on a specific machine, under specific requirements (my personal blog), and to that end for my purposes it was a really killer app that was right on par with the current version of Windows Live Writer and FAR more functional (if a bit uglier)
• Fully functional proof of concept and opportunity to discover the full life-cycle of product development including requirements, design, implementation, marketing, and sales (to some extent, but not so much customer support), and gain experience with full-blown VB6, COM/ActiveX, C#, XML, SOAP, XML-RPC

I suppose the more I think about the intricacies of PowerBlog and how I went about them, I have more and more pride in what I accomplished but that no one will ever appreciate but me. In fact, I started out writing this blog post as, "I am SO ashamed of PowerBlog," but I deleted all that because when I think about all the really cool features I successfully implemented, from a geeky perspective, wow, PowerBlog was really a lot of fun.

That said, it did fail, and it failed because I did not focus on a few, basic, simple objectives and test them from the bottom up.

I can't stop thinking about how globally applicable these principles are at every level, both specifically in software and broadly in my career and the choices I make in my everyday life. It's no different than a flask of water. Our time, energy, can be spilled out all over the table, or carefully focused on meeting specific objectives. The latter offsets a world of refined gold from a world full of mediocrity and waste.

There is one good thing to say about spreading yourself out in the first place, though. Spreading out and doing mediocre things solely for the intent of learning the idiosyncracies of all that gets touched is key to knowing how best to develop the things that are being focused on. One can spend months testing out different patterns for a simple piece of functionality, but experiencing real-world failures and wastes of efforts on irrelevant but similar things causes a person to be more effective and productive at choosing a pattern for the specific instance and making it work. In other words, as the saying goes, a person who never fails is never going to succeed because he never tried. That applies in the broad and unfocused vs. specific and focused philosophy in the sense that just pondering the bigger scope of things, testing them out, seeing that they didn't work, and realizing that the biggest problem was one of philosophy (I didn't FOCUS!) not only makes focusing more driven, but the experience gained from "going broad" will help during the implementation of the focused output, if only in understanding the variations of scenarios of each implementation.