A Return to Blogging

So it's been a long time since I've blogged, and a lot has happened in that time. I've been on hiatus, reassessing many things in my life.

One of the foremost among those things was whether I should be blogging at all. My last post was berated by one reader as badly written. It hit me pretty hard, and is probably the primary reason I stopped blogging at all.

For me, writing is a passion, something I do because I enjoy it, and because it flows naturally out of me. The reader in this case went on to state that the intent of my article was to claim that all software should be open source. That was never the point of the article; rather, the point was that you should strive for the kind of quality and responsible behavior in your code that instilled the confidence that, should anyone actually have the opportunity to view it, you would fear nothing, knowing you weren't doing anything you shouldn't be.

But his criticism struck a resounding chord in me. All to frequently, I fail to get my point across. I am too wordy. I dance around the point, rather than just coming out and saying it. So, perhaps, "badly written" has the unsettling ring of truth to it.

This caused me to reevaluate what I write, and how I write it. If I'm going to write, I want to do it well, and I want to make sure that my point gets across clearly. I haven't always done that. What's difficult for me, however, is that many of the ideas in my mind aren't easily conveyed with step-by-step instructions, or clear cut language. I have a tendency to see things through metaphors, analogies, and the like. My writing has always tended to reflect that.

As an aspiring fiction writer, those are strengths. As a technology writer, I'm not convinced they are. I'm fairly certain people read tech blogs for clear guidance and opinion, not mystical, philosophical musings. That, perhaps, has been my biggest mistake. I need to be clearer. And I will strive in the future to do so.

But there is a caveat to all that. This isn't strictly a tech blog. It wasn't originally intended to be so. While software development is a great passion of mine, it is not my only passion. And so, I would ask that those who read here have patience with me when I choose to blog about nontechnical topics. My emotions will surely shine through when I discuss writing, politics, gaming, society, religion, or any of the other nontechnical aspects of our lives.

Overall, things are improving for the better. For those who knew me, or followed my blog before, I hope that this will mark a return to steady blogging that is enjoyable for both my readers and myself. I've given it some thought, and blogging is just good therapy.

NValidate: Newest Developments

And here, you all thought I had just dropped off the face of the earth or something.

The truth is that between my work, my family life, having to put an epileptic cat to sleep, turning 40, quitting smoking, and trying to get NValidate ready for its initial Alpha release, things have been pretty crazy. There hasn't been a lot of time for posting on my blog. I've been terribly remiss, and for all of that, I apologize.

Now, enough about me. On to the good stuff.

Alpha Status. NValidate will officially achieve Alpha status tonight. I'm building the source files as well. This will be version 0.0.0.10177. (The build number reflects today's date; it's a nifty convention I'm borrowing from Jeff Atwood over at Coding Horror.)

You can download the source code here and get the binaries here. Unfortunately, the source code is only available in a Visual Studio 2003 solution right now. I'm hoping to fix that by the next release. You should be able to upgrade the project to Visual Studio 2005 without any problems (I've done it myself with no problems on a test machine here). I have not tested it on Visual Studio 2008 yet.

The binaries consist of the DLL and the PDB file. This is a debug release; you won't want to be using it in production code. To use the framework, simply add a reference to it to your application and import the NValidate.Framework namespace. For more information, see the Quick Start, and peruse the API Reference. 

It is vitally important that you note that this is ALPHA CODE. Do not use it for production work.

Updated API Reference: Online & Downloadable. I'm uploading the updated API Reference to the web site tonight. If you want to peruse the API Reference, you can quickly get to it by clicking here. For those of you who like downloads, I've also created a downloadable Compiled HTML Help File that you can get here.

Community Forums. Over the last few days, I've managed to get the community forums up and running, so there are places for any interested parties to comment on the source code. I cannot begin to tell you how much I want to hear from you guys. Critique the code. Tell me all the ways that it sucks; tell me how to make it better. Suggest new tests, better techniques, ways to improve the documentation. Help me make it more extensible.

Unfortunately, I have no idea how to market this thing. I'm hoping that it will survive and prosper on word of mouth. Aside from that, who knows?

Have fun with it guys. I certainly have.

Stealth Updates and the Group Mentality

So we've all heard about Microsoft slipping updates onto machines through Windows Update without alerting folks. (If you haven't heard about it, read about it here. Microsoft discusses it here.)

The gist of the issue is that, on or around August 24th, a mysterious update appeared on XP and Vista machines without warning. The update was a patch to the Windows Update service and several other DLLs (the specific DLLs depended on your operating system).

Reading the comments on Digg, you'll find that people generally (but not absolutely) tend to fall into three camps. For brevity's sake, we'll dub them Microsoft Sympathizers, Linux and Apple Fanbois, and the Naive.

Microsoft Sympathizers

This group feels that Microsoft is absolutely entitled to do whatever it wants to the operating system since they own the OS and you're just licensing it.

There may be a great deal of legal truth to this statement; however, as many have pointed out, it is quite frustrating and is tantamount to Microsoft using its massive legal power to coerce its customers into giving it a free reign on its computer systems. This fact alone is problematic.

Consider the countless users in corporate environments who have no choice over which operating system they must use. Microsoft Windows is the de facto standard in the vast majority of corporate environments. In development environments, knowing what patches are installed on your system at any given time is a critical aspect of software testability. You can't very well reproduce an end-user's environment with certainty if you aren't running the same patches that they are. That's why it's critical that the end-user have control over what patches are installed and when.

But this move by Microsoft (which, admittedly, may have been happening all along and only recently come to light) removes that control from the end-user and introduces a degree of uncertainty into the mix. You don't know what you're running, and you don't know that it matches the end-user's environment, because it could change behind your back. There's no notification to alert you to the fact that it did.

At some point, Microsoft must admit that their software is playing in our sandbox, and managing our data, our bits. Sure, we are licensing the operating system from them, but we're also granting them permission to run their half-baked operating system on our machine. It's a cooperative agreement. Our acceptance of the license agreement is not an explicit agreement to grant them free reign to do whatever they want whenever they want. Our hardware is not Middle-earth, and Windows is not Sauron, despite the alarming similarities in behavior.

Linux and Apple Fanbois

Any time Microsoft does anything that smacks remotely of foul play the Apple and Linux Fanbois line up to shout at the top of their lungs. They tout their wares, proclaiming that everyone should just drop everything and switch to Apple or Linux. Linux fanbois are the most egregious fanbois; it is, after all, the Silver Bullet of Operating Systems. It's free, after all, and patched daily, and you can get the source code and patch it yourself.

My god, people, wake up.

First off, the average home user isn't going to have the technical skills to be able to use any of the xNix operating systems (excluding OS X). These operating systems tend to be complex, having been built up over 40 years and counting. Their vast feature set is daunting, even to advanced IT professionals. You cannot expect the average home user to turn in an operating system like Windows, which shields them from the complexities inherent in an operating system and expect them to switch gears without introducing a whole new set of problems. The frustration from learning a new operating system alone would likely drive them bonkers.

Second, you have to take application selection into consideration. Are your favorite applications even available in that operating system? Can you get Microsoft Office for it? PageMaker? Adobe Acrobat? Decent video or music editing software? And of the software that is available for it, can the average home user go to Best Buy, Circuit City, or CompUSA and purchase it in a nice shrink-wrapped box (complete with documentation, mind you), or does he or she have to go to some obscure website that he or she may or may not trust and download it (possibly with a complimentary virus)? And if they download it, will it work and can they get product support for it?

Third, how about device support? Can they plug all of their peripherals in it and have them just work? Or will they have to go on a mad search for device drivers again, like they had to back in the days before Windows XP? Sure, if they're IT professionals, that's a snap. But if they're the Average Home User (TM), that's more than they're usually able to deal with. It's probably going to tick them off royally, and they're going to wonder why in the heck they bothered with this operating system in the first place. They'll be wondering, "Where's my plug-n-play support?"

Fourth, how good is the font support? Does it support true WYSIWYG? Or does the type look completely different between the screen and the printer? The same could be asked of the colors. That's going to be really important for the average home user who's working with videos and photos, printing calendars, Christmas cards, and invitations, you know.

Fifth, if they need to do their office work on it, will they be able to do so? If so, how difficult will it be to do that? Will they have to be rocket scientists? And if it breaks, who do they call? I mean, if they were able to call their brother or their kid before, because he was a Windows guru at his company, will they still be able to do that? They've just switched operating systems, and now no one knows anything about it. They're now an island in the middle of a Windows ocean. They've effectively isolated themselves from everyone. How long do they have to wait before they can get meaningful support in an emergency?

Now. Ask yourself a really serious question and think hard before you spit out a really ludicrous answer. Are you really going to tell someone to risk losing all that support just because the browser isn't that cool, or because there are a few security loopholes? Or because you found out about these stealth updates from Microsoft?

Sure, we live in a Microsoft world. Are all their products perfect? Heck no. I work with Microsoft products every day, and I can testify to the fact that they aren't. I also own a Mac computer at home, and I happen to be a big fan of OS X. I've also had the occasion to use Linux. Each of them has their pros and cons. But I'm here to tell you that there is no silver bullet. Statements like those being made in these comments are asinine, short-sighted, and utterly ridiculous. Linux is not the solution to everyone's problems because it isn't the ideal operating system for the average home user.

Average home users need an operating system that's easy to use, has a large selection of over-the-counter applications, is secure but not intrusive, supports all of their peripherals, and has great product support. In my opinion, the one that comes closest to that is Mac OS X. However, it's pricey nature makes it cost-prohibitive for the average home user; and that's one of the reasons we live in a Microsoft-dominated world.

Sure, Linux is cheap. But the over-the-counter application support just isn't there, and the GUIs, in my opinion, still look like their in their infancy. And they're still targeted at tech-heads. When all the Linux variants start targeting the average home user, and the over-the-counter application support gets there, and they get really good device driver support, things might change. But there's no way on earth I'd ever recommend it to my family or any of my non-technical friends. They'd go out of their minds trying to figure it out.

So, in the end, I'll continue to read these kinds of posts from Linux advocates and shake my head. In my personal opinion, statements like these demonstrate a complete lack of comprehension when it comes to the average home user's computing needs.

The Naive

The last group believes that the patch from Microsoft is just a patch to the Windows Update service, and that, consequently, nothing could possibly go wrong. We're all blowing things way out of proportion, and everyone should just forget about it. I mean, really, what could POSSIBLY go wrong?

Well, let's think about that. Anyone with even a passing familiarity with DLL Hell knows from experience that any number of things could go wrong.

The notion that Windows Update isn't an integral part of Windows, and that patching it won't screw up something else is naive and shortsighted. Just ask anyone who was recently screwed over by the WGA flap when their perfectly valid Windows licenses were suddenly declared invalid due to programmer error.

If Windows Update can download software onto your machine without your knowledge, and if it can do so without notifying you, it can download buggy software onto your machine without notifying you. In a corporate environment where software must be vetted through the IT department before it's released to the masses, this is particularly worrisome. It's not the IT Staff that we're worried about here: it's some bloke at Microsoft accidentally releasing prerelease software through this stealth update mechanism.

Yes, it's a theory, and a hypothetical situation at best. But here's the scary part: it can happen, and it already has, at least once, and it affected a LOT of users. So those who casually dismiss it as "nothing to worry about" are viewing the situation with rose colored glasses.

So while I won't tell everyone that they should be panicking and seeing conspiracies everywhere, I would tell them that they shouldn't so easily dismiss a very real concern, and that they should definitely view the situation with its due gravity. Windows components are tightly integrated; patching one of them could easily break others, and assuming that a patch to Windows Update is a perfectly safe operation is misguided and a sure way to set yourself up for a nasty surprise down the road.

The Joy of Slowing Down

A couple of things happened when I decided to go public with NValidate. First, I decided to rewrite it from scratch. There were suggestions I'd received from others that I really wanted to incorporate, and I didn't want to do them piecemeal. I also wanted to review the design and architecture, and that gave me the opportunity to decide exactly what it was that I was trying to accomplish, who my users were going to be, and what I wanted them to be able to do with it once I released it.

I also decided to switch languages. I'm in the process of porting NValidate from VB.NET to C#, and I'm enjoying the experience thoroughly. While I'm doing that, I'm fully embracing test-driven development.

All of these things together have combined themselves to force me to slow down in my approach to the development of NValidate. It's startling to reflect back on my professional experience as a software developer and realize just how haphazard much of it has been. Part of that haphazardness has been my own doing, but a very large part of it has been due to the rushed nature of software development in general.

We always seem to be in such a big hurry to get things done that we cut corners in all the wrong places. A vague statement describing a problem somehow becomes the vision statement which in turn becomes the requirements specification. We slap together a prototype, and somehow the prototype becomes the product. We shortchange testing, shortchange defect resolution times, shortchange staffing ratios, and yet still want it out the door on time. We cut features, go cheap on the aesthetics and documentation, and rush a piece of crap out the door just to beat the competitor to the market. All because the first guy to home base usually captures the market share.

God, how I wish that would change.

It's obvious when you're forced to use a product that was rushed out the door or that was cheaply made. And that's any product; it's not just software. Typically, you know within a few moments of having to use it. It either lacks the features you thought it had, it lacks the power to do any real work, or it breaks too frequently to be of any real use. Some of them, while useful, are so gaudy that you would never leave them out where your friends or family could see them. It's embarrassing to have to use them.

It bothers me to think that some of the software that I've had to work on the past, and some of the software that I've designed in the past, is of that caliber: it's only fit to be shoved into a kitchen junk drawer.

That kind of software need not be a mandate. Rather, it can be a thing of the past if I take the time to slow down and make useful, powerful, well-designed software that people are actually excited to use. But that requires slowing down, and thinking my way through the design, the requirements, the architecture, what the consumers actually want and need, and how to give it to them in a way that compels them to use it.

And that's where my experience with NValidate comes in. (You knew I had to be going somewhere, right?) I've had to stop and think my way through the design and architecture all over again. It's not just me that's going to use it. What do other folks likely want from something like this? How will they use it? How should it perform for them? What languages will they use (programming and spoken)? What are the big design goals (performance, memory footprint, extensibility, maintainability, etc.)?

So in the process, I actually get to do it right. And it's refreshing. I have a vision. I have the design priorities. I have the platform selected, and I have the language selected (and a compelling reason for the language: it's an open standard). I have a rough idea of what I think the end users will expect from it. I have the base architecture sketched out and documented. When I code, I write the test cases first, and then code to satisfy the test cases. There's no fluff. It's lean. It's clean.  

Slowing down is a joy. There's no panic involved here. I'm enjoying the project, and I'm looking forward to its initial release. I'm not even really worried about whether or not it's widely accepted by the masses. The opportunity to develop a piece of software that's well documented, using a slow, steady approach to its development instead of a rushed, haphazard approach is rewarding and fulfilling in ways that I never imagined.

I've got twenty years and counting under my belt as a software developer. The vast majority of that time has been spent working at companies where "best practices" were either unknown, paid lip service to, or looked upon as something that were typically beyond the fiscal reach of the firm. But my experience with NValidate has taught me something surprising: my confidence in the product is leaps and bounds ahead of anything I've written before. Granted, it's not rocket science, but I am left wondering if that same degree of confidence isn't directly transferable to larger projects were we to adopt the mantra, "Slow and steady wins the race."

Slow and steady, careful and methodical. Take your time, think your way through the product, and stop rushing through everything. Invest the time you need to design, architect, plan, code, and test. Don't shortchange yourself or your customers in the name of "time to market." While there's always something to be said for getting something out the door, I'd like to think that most customers would rather have something that works and works well, rather than something that looks pretty and blows their foot off.

Heroes, Villains, and Software

I'm a big fan of comics, and I'm also a big fan of software development. Coincidentally, I see metaphors and analogies for software development just about everywhere I look.

Comic books have come a long way from the days when it was just about the guy wearing the mask or the brightly colored costume who rushed in to save the day. In the early days, the stories were pretty straightforward: the bad guys were always easily identified, and so were the good guys. But stories these days have become more complex, more adult, and they tackle tough issues. But one common element persists: the heroes and villains tend to wear costumes or masks that exemplify their heroic or villainous persona.

The attire of a hero or villain isn't simply done for theatrical reasons (although there is certainly a large and undeniable element of theatricaility to it). The mask grants the wearer anonymity; those who behold the wearer have no idea who the wearer is, and with that anonymity the wearer is emboldened to do things he or she might never do or have the courage to do if people knew who he or she was.

Anonymity grants the wielder power. What separates the heroes from the villains is a sense of responsibility and what they choose to do with it. A villain might have a sense of responsibility but choose to ignore it, and use his power for personal gain.

When a civilian in a comic book views a mask-clad individual for the first time, they don't really know whether that individual is a hero or a villain, or just some bloke in a costume. They might be able to infer some things from the costume, but they have to trust their instincts. A great failing of classic villains seemed to be that they went out of their way to look villainous; they were so easily identified that they were easy to avoid or locate and defeat.

But the greatest villains actually looked like one of the good guys, or just a regular Joe. They managed to garner the trust of those around them, and then used that trust against those who placed it in them. You see, sometimes, wearing no costume at all is a mask in and of itself.

So now we come to the part where we apply this to software.

All software wears a mask. It's called the user interface. It doesn't matter if it's a desktop application, a Web application, a framework, a Web service, a device driver, or anything else. The mask is the face that your software presents to the public, how the public perceives the software when they first look at it.

Most software presents itself as the next silver bullet to any given problem domain. After all, what software doesn't want to be perceived as a Hero? A user, looking at your software for the first time, is forced to place a certain amount of trust in it because all they can see is its mask. And the mask grants the software anonymity and power.

Unless you're giving the user the source code, and the user knows how to read it, and can build it themelves, they're at your mercy. They're trusting you to be heroic on their machine: to have a sense of responsibility, and to use the power you've been granted wisely.

Sadly, much precompiled software relies on its anonymity to conceal its true state: that it is miserable, ugly, unmaintainable, untestable, bloated, unreliable, and unsafe. Software of this nature is hardly heroic; rather, it's villainous. It might handle user data with reckless disregard for integrity, security, or consistency. It might crash frequently, and for no apparent reason. It might install spyware or adware. It might log keystrokes. It might be riddled with bugs, be poorly documented, and have no consistent coding model or standard. It might use an inconsistent user interface paradigm, or hog system resources. It might break other software. It might do all of these things.

The question we are compelled to ask is this: What is hiding behind the mask of the software that we're writing, right now, at this moment? Is it heroic? Or is it villainous? Despite claims by certain advertisers, it isn't really enough that "it just works." It has to work well, and responsibly.

Some of the greatest heroes in comic book lore were brave enough to take their masks off so that people could see them and know who they were. Would you be willing to open your code base up to let the world see what you're doing? Would you feel comfortable letting everyone see the code that you write and what it's doing? Would you be confident or proud of your work? Or would you feel shame? Embarrassment? Even guilt?

Not all software can be heroic. There are always mitigating circumstances. But we can all strive to be heroic. It's when we strive to be villainous that we need to be worried. Or when we're writing villainous software, and we know it, and we choose not to do anything about it. We all have a choice. We can choose to make great software that behaves responsibly, and does what it says its going to do, or we can abuse the trust placed in us and serve ourselves.

Take stock of the software you're writing. Find out what's behind its mask. If it's not software you'd be prepared to unmask in front of its users (aside from intellectual property issues), chances are, something somewhere has gone horribly awry. What are you going to do about it?

A Terser Visual Basic?

There’s a rather interesting post going on at Panopticon Central right now, dealing with the terseness of Visual Basic.NET. In a rather obtuse attempt at reducing the “terseness” of the language, Paul Vick hacks a VB.NET compiler to coerce all the keywords to lowercase. While it’s a nice look, it doesn’t solve the common complaint that Visual Basic is inherently verbose.

Visual Basic’s verbosity problem likely stems from the fact that we VB developers commonly have to tell the compiler lots of things that it already knows or should be able to tell from the syntax. To see what I’m talking about, let’s take a piece of the original NValidator code that was written in VB and see what it looks like:

Namespace Validation

  Public Class ConnectionValidator
    Inherits ParameterValidatorBase

    Friend Sub New(ByVal connection As IDbConnection, ByVal name As String)
      MyBase.New(connection, name)
    End Sub

    Public Function IsClosed() As ConnectionValidator
      If Not Connection Is Nothing Then
        If (Connection.State And ConnectionState.Closed) = 0 Then
          Throw New ArgumentException("Operation requires a closed connection.", Name)
        End If
      End If
      Return Me
    End Function

    Private ReadOnly Property Connection() As IDbConnection
      Get
        Return DirectCast(InnerValue, IDbConnection)
      End Get
    End Property

  End Class

End Namespace

Now, it bears noting that every blue word in there is a keyword. That's a lot of keywords. So yes. Visual Basic is verbose. I suspect that the Visual part of Visual Basic has ceased to be "visual" as in "visual design" and has somehow become "visual keywords." But I digress.

First, lets give Paul the benefit of a doubt. Let’s see what it looks like with everything converted to lower case.

namespace Validation

  public class ConnectionValidator
    inherits ParameterValidatorBase

    friend sub New(ByVal connection as IDbConnection, byval name as string)
      mybase.New(connection, name)
    end sub

    public function IsClosed() as ConnectionValidator
      if not Connection is nothing then
        if (Connection.State and ConnectionState.Closed) = 0 then
          throw new ArgumentException("Operation requires a closed connection.", Name)
        end if
      end if
      return me
    end function

    private readonly property Connection() as IDbConnection
      get
        return directcast(InnerValue, IDbConnection)
      end Get
    end property

  end class

end namespace

Well, it does look a lot more like C#. And yes, the lower case does help to reduce the visual WHAM! of the keyword volume. But it’s the same number of words, so we haven’t addressed the terseness. To address the terseness, you actually have to reduce the number of words. So how do we do that? You get rid of the words that aren’t actually doing you any good.

First and foremost, get rid of all the words that accompany the End keyword. They’re superfluous. With proper indentation, that’s pretty obvious. So in this case, that’s End Namespace, End Sub, End Property, End If, End Function, and End Get. Believe me, if the End doesn’t have a corresponding block statement, the compiler will let you know.

Next comes the As keyword. Let’s accept the fact that identifiers can’t have spaces in them. Therefore, anything that follows an identifier in a variable, property, or method declaration must, by definition, be a data type. The As keyword isn’t getting us anywhere. Drop it.

The Then keyword on If blocks is equally useless. It needs to go.

The Sub, Function, and Property keywords are completely useless. They’re used to tell the reader whether or not a method returns a type. They certainly don’t do anything for the compiler: the compiler gleans this information from the method’s signature (it’s arguments and return type). If the method has a getter and a setter, it’s a property. So these could be removed as well.

Finally, the ReadOnly keyword is useless on our property, since it doesn’t have a setter on it. So let’s get rid of that, too.

Okay, I think that’s enough for now. We’re off to a good start. What does the fruit of our labor look like?

namespace Validation 

  public class ConnectionValidator 
    inherits ParameterValidatorBase 

    friend new(byval connection IDbConnection, byVal name string) 
      mybase.New(connection, name) 
    end 

    public IsClosed() ConnectionValidator 
      if not Connection is nothing 
        if (Connection.State and ConnectionState.Closed) = 0 
          throw new ArgumentException("Operation requires a closed connection.", Name) 
        end 
      end 
      return me 
    end 

    private Connection() IDbConnection 
      get 
        return directcast(InnerValue, IDbConnection) 
      end 
    end 

  end 

end 

So there you go. Now you’ve addressed the problem of the verbosity. But the result doesn’t really look all that much like Visual Basic anymore. It’s almost a different language.

You could likely get around all this by making all the keywords we removed optional, but what’s the point? A large body of the folks who use Visual Basic have an ardent devotion to keeping the language just as it is; messing with it in any way runs the risk of stirring their ire and starting a war of religious proportions. Then you have to consider the problems that arise from one developer who uses the keywords, and one who doesn’t, and both of them working on the same code base.

And what happens when those old keywords become the goto of the 21^st century?

Just leave it alone. If you want a terser version of Visual Basic, then make a new language. Personally, I’d love to be able to make the keywords lowercase, and not have to pamper the compiler any more than I have to. But I’d rather not waste any more time than I have to debating what’s sure to become a religious war when people realize what’s really involved in addressing the terseness of Visual Basic.

It’s not about the case of the characters. It’s about eliminating the keywords that don’t help the compiler or the developer. And the end result of that effort is a radically different language.

Why Does Software Cost So Much?

So my sister-in-law recently discovered that the computer a "friend" built for her has an illegal copy of Windows XP installed on it. (Big surprise, that.) When she asked me what she should do about that, I told her, quite simply, that she'd need to get a legal copy of Windows. When I told her what it cost, she was flabbergasted. She looked at me with disgust on her face and demanded, "I don't get it! Why is software so expensive?"

I looked her dead in the eye and said, "Do you really want me to explain it to you?"

Now, she knows that I write software for a living, and she still, in her naiveté, had the temerity to ask that question of me. She's well aware of how constantly stressed out and tired I am from the work I do. So she backed up a second, swallowed, and said, "No, I guess not."

In hindsight, however, I think she posed a fair question. I hear it alot. It's probably a fair statement that most folks have no real grasp of why software costs as much as it does. So I will try to point out some of the reasons why I believe that it is. These are my opinions, mind you; your mileage may vary.

Software is expensive for one very important reason: the people who make it have to live, pay their bills, and feed their families. Beyond all other reasons, that's probably why it's so darned expensive. It's a job, just like any other. And, like any other field, it's not just a simple task: it's a very complex task that requires lots of people, lots of resources, and lots of time.

(There seems to be this preconception out there that writing software is easy because using it is easy. It's just a game, right? How hard can it be?)

I can't speak for the open-source community who do everything over the Web, and develop software on a volunteer basis. But then again, this article doesn't necessarily apply to them. But certain things must be in place in order to develop software in a corporate environment:

• You have to have somewhere to do it. If you're a freelancer, working out of your house, you have rent or a mortgage to pay. On the other hand, if you're a business, it means you need a lease.
• For businesses with a building, you need insurance, so that you're covered in case your employees are injured on your premises. You need flood and fire insurance as well.
• You have to pay utility bills (heating, cooling, electricity, water, etc.). 
• You have to pay your local, state and federal taxes.
• You have to have office equipment. Depending on how many people are involved, you may need LOTS of it: desks, chairs, bookshelves, computers, printers, fax machines, extra toner, phones, paper, notebooks, file folders, filing cabinets, trash cans, pens, and all that other jazz. You'll probably need whiteboards for collaboration. If you don't think that stuff is expensive, start browsing your local office supply store web sites. You'll be in for a big surprise.
• You have to employees. Employees get paid. Depending on how complex your product is, it can take anywhere from a handful to hundreds of employees to develop your product.
• You have to provide your employees with benefits (medical, dental, 401k, workmen's compensation, etc.), unless they're contractors. If they're contractors, they have to cover their own benefits which means they get paid more than W-2 employees.
• You have to have lawyers to ensure that your intellectual property is protected from copyright infringement.
• You have to spend money and invest time to develop a plan for what the product will do. This is often a long, arduous process that involves a lot of arguing, shouting, frayed nerves, and confusion.
• You have to spend money and time creating mock-ups of what it will look like. This mockup goes through several revisions as people heatedly debate why they hate it, what they want changed, and what a crappy job you did in the first place. They'll want to know why you didn't understand that by "circle" meant an ellipse and that by "square" they meant a beveled rectangle with a shadow in the lower right-hand corner. They'll send you back to the drawing board. Repeatedly. What one user demands another will despise. No one will ever be completely satisfied.
• You have to spend money to finally start developing the actual software. You'll do this with a severe shortage of time, money, and hands, and the developers will want to kill the management. They'll be unhappy because the specs will likely be hastily put together, the time will be insufficient, and they'll be grumbling about the likelihood of "crunch time scheduling" that requires overtime that they won't be getting paid for.
• You have to spend LOTS of money testing the solution once it's put together. This is the hardest part of the whole thing. You will have made the mistake of thinking that it works. It doesn't. It never does. Just when you think you know what you're doing, a user is right there to prove you wrong. The system will have to be ripped apart, rewritten, retested, over and over and over again. And all of that takes time. An adversarial relationship will develop between the testers and the developers. Finger-pointing will rule the day. Some people will quit, costing you money as you have to replace them unexpectedly and retrain them. The schedule will slip, costing you further. And as long as you're doing that, you're paying for rent, utilities, taxes, payroll, benefits, office supplies, insurance, and everything else that goes with it.
• You have to spend money to develop a marketing campaign for the product.
• You have to spend money to package the product (put it on disk, print the materials that go inside the box, put it in the box, shrink wrap it).
• You have to spend money to ship it to the retailers who will carry it, or negotiate deals with online resellers who will carry it for you.
• You have to employ a customer support staff after the product ships. (Benefits, payroll, etc.)
• You have to pay to support the customers when they call to complain about the product after it ships, or when they can't figure out how to install it or find the icon to start it up or find the CD ROM drive on their computer. You have to deal with irate customers who think it's your fault that the software has too many features when they're the ones that demanded them. You have to deal with customers who are angry and seem to think that it's okay to scream at you because they made a mistake and spilled soda on their keyboard, or the dog yanked the laptop onto the floor, or they didn't pay their cable bill and they want to know why your Web-based software doesn't work anymore. And you have to smile through it all while the bills keep piling up.

These are just a few of the reasons that software is so expensive.

And let's bear in mind one very important fact: writing software is not like writing an essay, or building a house, or fixing your car. Writing software is damned hard to do. Hell, I seriously suspect that disarming bombs is easier.

From where I sit, the computer is just a stupid box armed with the vocabulary of a three year old. It will do exactly what you tell it to do, very quickly, and very efficiently. If you tell it to do the right thing, it will do it very quickly, and very efficiently. Tell it to do the wrong thing (like, erase all files in the My Documents folder) and it will do it very quickly, and very efficiently. This is why I get irritated when someone says, "Oh, the computer hiccupped!" or "The computer screwed up." No, the computer did not. The computer did exactly what some programmer told it to do.

You have to teach a computer everything. Consider a simple task that we take for granted, such as "Transfer $100 from my savings account into my checking account." In its simplest state, a computer is completely incapable of doing that. It doesn't know what a transfer is, what an account is, what savings is, or what checking is. It doesn't know what a dollar is, or a bank is. It has to be taught everything. Software is about teaching that dumbass box with a 3-year-old's vocabulary how to do extremely complex tasks without making any mistakes.

In short, a computer programmer is an individual who sits down at a computer every day, and figures out how to handhold a mechanical idiot through tasks simple and complex, mastering the task of tutoring that idiot through those tasks until the idiot becomes a savant. It's grueling, frustrating, and infuriating. It takes time, and it's expensive. Depending on how big the task is, it might take lots of programmers to teach the idiot how to do the task.

So there you have it. That's why I think software is expensive.

Coincidentally, I also think it's why I and a lot of my peers in this field are psychotic (or very close to it).