Writing software is hard!
OK, let me clarify. Writing a piece of software code that does something interesting isn't all that hard. With the right tools and a little bit of pretty basic understanding, almost anyone can have a basic, working software application in only a few moments' time.
[STAThread]
static void Main()
{
MessageBox.Show("Hello, world!");
}
This is C# syntax, but programmers of any language will recognize this as the classic example of the most basic computer program you can write that actually does something. Seems pretty easy right?
It is pretty easy, until you start thinking about software development in terms like "professional," "commercial," or even "shareware." It's one thing to write a "Hello world" application to impress your girlfriend (actually, you and I both know that if you're writing software to impress your girlfriend, you probably don't have a girlfriend). It's quite another to write "Hello, World (TM)" the shrink-wrapped home productivity application. Let's take a look at what that might entail:
- We decide that we want to support alternate-language versions of the program like "Hola, Mundo!" We could simply hard-code that into the application, but since we are good programmers, we need to add resource file handling or some similar strategy for storing internationalized versions of the text.
- We may even want the data to come out of a database so that we can provide individual logins for multiple users.
- Thanks to Winamp, no self-respecting modern application can fail to offer custom skin support, so we'll definitely need to offer the Star Trek version of "Hello, World (TM)."
- We should probably add things like error handling and logging so that if anything goes wrong with the application it can be handled appropriately.
- We may even want to report any errors back to the mother ship so that we can be aware of how the application is behaving out in the wild. To do that, we'll need code to manage internet connectivity for the application.
- Speaking of connectivity, while we're at it we should also throw in automatic version checking so that when we want to distribute our next version ("Hello Again, World!") our software can simply update itself over the internet.
- Of course, we'll also want to build the ability to offer a time-limited trial version of "Hello, World (TM)" that will expire after 30 days so that people will have to purchase the application from us.
- Speaking of purchasing, I guess that means we actually have to support the ability for someone to give us money! Either we have to set up our own merchant account or affiliate with an existing service that provides such capability.
- We probably also want to set up a website to market our new application, offer downloads, provide a user forum, product support...
- Ah, crap. We forgot about support! That means we'll have to set up an email account and monitor it on a regular basis so that if people have problems with the software, they'll have someone to help them out.
...and you get the point. There's also writing the help documentation for the application, adding a nice logo and graphics, creating a testing framework to validate that it works properly, building the installation package and delivery infrastructure, setting up a defect tracking apparatus to handle the inevitable bug reports, creating our third-party plugin API so that other developers can leverage "Hello, World (TM)" as an application development platform, patenting our unique implementation of "Hello, world" so that we don't get sued by the original inventors, etc.
Now, imagine that you're trying to write software that's only slightly more complex than "Hello, World," but one that shares most of the same basic issues listed above, as well as many more highly technical issues that go beyond the scope of this post? Building software on this scale is do-able, but doing it well is pretty damn hard!
I am interested in the feedback of other folks who have gone through the commercial application development cycle from scratch, especially as a small organization of only one (or maybe a few) developers. How did it go? What other issues did you face that weren't mentioned above? How did you balance the technical side with the business side of managing your product(s)?
We are just on the leading edge of this process ourselves. Most of these are questions that we are facing right now, trying to decide what to deliver, what to postpone, what to ignore, and most importantly, HOW to do it all. As we figure out some of the answers for ourselves, I will surely share what we discover.
