Auto-updating deployed software is easy right?  I mean come on, how hard can it be to download a file from the internet and replace the old with the new. Why wouldn't I roll my own? I'd knock this out in a day or two.  All I'd need to do is...

Replace some files

I'll need to download the new files and replace the old ones.  Well... since my application is running and the files I need to replace are locked I'll need to do something with that.  Let's see, I'll just shadow load the exe.  When the application starts, I'll just copy it to another location and run it from there.  That way when my updater wants to replace it with the new one, it'll work.  I might have problems when I want to add another assembly to my application. I guess I'll have to copy all the assemblies when my app starts.  That could get messy, but it's quick and easy.  Moving on...

I'll need to know when an update is available.  OK, I can just retrieve a little file that will tell me what the current update is.  If the current update is newer than what is on the client, I'll download it and replace the client file with the updated file.  What?  Hmmm.... your right.  This will have to be changed if I ever want to update just part of the install, but I'll sort that out later when I have more time and I actually need to do it.  On to downloading...

Downloading an update

Downloading should be easy. The .Net framework gives me the WebClient class, which will make it as easy as pie.  I'll probably want to give my users some feedback and let them cancel.  My updates won't be very big so I don't think I'll need to worry about resuming from a previously failed update.  Everyone has fast internet connections now anyways. What's that?  Proxy servers could be a problem?  Well that'll take some time to sort out, so I'll just auto-detect, and if that fails then those users will just have to download the installer again and update the old fashioned way.  You think I should worry about getting hacked?  Not likely.  After all, we're pretty small and don't have that many users.  If they did though, I better do something to prevent that. That'll take some time to sort out, so I'll worry about it when we get big. Maybe crypto-signing or something... later.  Let's move on to actually updating the client...

Updating the client system

This will be super easy.  I'll just launch a little exe that will download the new files and replace the old ones.  What? Permissions might be a problem?  Never mind all that.  My users are all administrators on their machines anyway. What? Vista and Windows 7 doesn't even let administrators replace files everywhere?  Well then my users will just have to install the application somewhere where they do have permissions to replace files, or get someone who does have permissions to update their software.  We'll make a better solution later when we have more time to sort it out...  We can always update the updater later.  What?  I know the updater is running!  I'll just have to shadow launch the updater too so that I can replace it during an update.

And when the updater fails

All I am doing is replacing a file or two.  Why would the updater fail?  The user can just tell me which files are replaced and which ones aren't.  Later... when we have more time we can back up the files before we try to replace them or maybe even totally change the way we update the files.  Someday maybe we'll even add some logging so that we can figure out what happened when things go wrong.

Publishing updates

We'll just copy the new files to our web server whenever we build a new version so that the updater can download them. That's easy enough.  Yeah your right. Maybe we should compress them or something.

You know... this sounds like a lot more work than I thought.  It might take me weeks, not days to get this done.  I wonder if there is something I can buy that will do all this?  That would save me a lot of time.

When discussing software requirements documentation, a very common question asked is "When is a software specification complete?"  This is a very subjective question, and answers are often as far apart as discussions comparing waterfall to agile software development methodologies.  I like to break the discussion into two parts.

1. When is requirements elicitation complete?
2. When is requirements elaboration complete?

If you split the question and look at the issue in this way, you can at least get to a non-subjective half answer.  I know... what a terrible result.  But the truth is sometimes like that.  The answer to question 1 is still subjective, but at least we have succeeded in identifying a more specific point to discuss.  The answer to question 2 is far less subjective.  In fact, removing arguments based on the quality of the elaboration work product, one could argue that answering question 2 is absolutely non-subjective.  Requirements elaboration completeness is identified when all elicited requirements are described sufficiently to transfer understanding of the requirement to the software documentation reader.  In other words, when each requirement is checked as complete by the software documentation author, and agreed as complete by stakeholder reviewers.

The Requirements Elicitation Completeness Conundrum

Question 1 is much harder to identify. The inability to identify the answer to this question, and the frustrations of teams that have tried, is a huge contributor to the industry-wide recognition of agile methodologies as a potential better way to work software projects.  Any attempt at identifying completeness can only take into account known issues. You simply don't know what you haven't yet discovered, and the best advice in assessing requirements completeness is to acknowledge this simple truth.  Don't get hung up on it.  Diligently attempt to elicit the known requirements, and plan to iterate early and often in order to catch the unknown requirements. 

It can become very costly when we try to completely identify all requirements of a software project up front.  This cost is not just in the analysis time we spend chasing perfection, but also in all the requirements that are identified in our quest, but are not really requirements. These requirements turn into software features that are developed, but never used.

Software teams should expend reasonable resources in identifying known requirements up front, elaborate those requirements to completeness, then recognize and embrace requirements change that comes from iterative understanding of the problem domain and iteratively incorporate changes as the unknowns become known.  This is scope creep, but it is not bad, and should be planned for.  Your team will fair far better technically and financially when necessary scope creep is expected, planned for, and then analyzed and documented as part of your iterative development process.

It used to be that if you needed a quick business app you could fire up FoxPro or Microsoft Access, bang away for a day or two and end up with a solution to a problem that could actually be used.  With FoxPro already phased out and the future of Microsoft Access in question, software application frameworks are filling the void.

In the Microsoft development sphere, .Net development using C# or Vb.net is the most common answer given to replace the front-end client development features of Access and FoxPro.  However, when a developer starts up Visual Studio and creates a new project, they are a long way from a useable application.  Yes, all the pieces are there in the .Net Framework to build applications... good applications..., but application infrastructure is still needed as well and though you can go quite far with data binding and point-and-click wizards within Visual Studio, creating usable applications quickly will still require considerably more time and knowledge than past rapid application development platforms.  You can jump-start application development significantly by choosing and adopting an application framework product such as Component-based, Scalable Logical Architecture (CSLA) or StrataFrame.

Advantages of Choosing a Software Framework

There are many advantages to using an existing framework.  These include:

• Rapidly Create Applications (After the initial learning curve)
• Consistency of development practices across your applications
• The infrastructure code is proven and you enjoy the benefits of more widespread usage and the mature code that arrives from such usage
• Re-use of extensions you create for your specific application environments
• A community of developers using the same technology to interact with and share thoughts and work

Building your own framework can provide a few of these advantages as well, but not all.  Whether you build your own or choose an existing framework, a framework will get you to writing code that actually addresses your application requirements faster. For developers and consultants that work on many different projects, the pace at which usable applications can be developed is often what judges your worth, and affects your income. Investing the time to analyze and learn the use of an existing application framework will provide an excellent return on your investment.

The lines distinguishing a web application from a desktop application have certainly been blurred with the adoption of application platforms such as Microsoft Silverlight and Adobe AIR. 

Rich Internet Application, or RIA's, are what these applications are called.  They run in a browser, and most applications built on these platforms usually communicate with a backend server.  That sounds like an internet application.  But peel back a layer and you'll see that RIA's have much more in common with their desktop application brethren than your traditional server-hosted internet application.  These apps run in a browser, this is true, but they run completely on the client system.  Unlike a traditional web app, and much like a desktop app, once started, neither the server or the browser is really necessary. It's so not necessary, that upcoming releases the major RIA platforms plan to include a no-browser mode, so that these apps can run outside of a browser.  Right now, as I type, there are .Net development leads out there pondering whether they should build their next app as a Silverlight application or as a smart client app (WinForms or WPF) deployed through ClickOnce.  Cross-platform capabilities notwithstanding, the case for ClickOnce and WPF over Silverlight is so strong, it's difficult to understand why there is even an argument. Understanding comes in a word...

Deployment.  It's like the four letter word (that's not a four letter word) of software development. Nobody wants to even think about having to actually deploy software.  The mere thought invokes headaches. Deployment is so much at the root of these decisions that we should be calling these applications Browser Deployed Applications, or BDA's.  A Browser Deployed Application is an application that can be downloaded and launched using any standards compliant browser and runs on multiple computing platforms.  More accurate I would say.

The most interesting aspect of this is that over the same period of time that RIA's have come on the stage, deployment of thick desktop based applications has become so much easier than it once was, and hardware virtualization promises that soon we'll see seamless cross-platform capabilities though virtual functionality.  Surely, for many applications and target environments, the pain of limited development capabilities that come with RIA's would be much more burdensome and costly than the deployment challenge of today's .Net thick client applications.

The future may indeed be computers with nothing but a browser installed. But that day is not today. Today, users still expect more than that from their computers and their applications.  Don't be afraid of software deployment. You just might spend less and get more by stepping out of the browser for your next application.

Do you remember the days before Agile changed the software development discussion? Back before waterfall wasn't the term coined for all things bad about software development.  You should. It wasn't really that long ago.  Back in those days, believe it or not, there... gasp.... were successful software projects.  But how could that be!  Any time spent in today's software blogosphere would have you asking that question for sure. Successful projects have always been worked through some level of iteration. There just hasn't always been a recognizable methodology name for it.

Back in those long lost days of yesteryear it would have been unthinkable to initiate a software project without any documentation.  Today, it seems almost unthinkable to document anything. Tomorrow, we think that today's experiences will bring about a resurgence of the importance of software requirements documentation.  These documents will not be created and managed like they were yesterday though. Iteratively creating and maintaining requirements documentation will be the way it's done.

But what does it mean to iteratively create documentation?  Isn't all documents inherently created iteratively?  Iterations in requirements documentation are as much a mindset as it is an action. Its accepting the notion that documents are never finished, and that acceptance does not have to mean finalized.  Yesterday, a requirements document was written with the expectation of completion.  The document was completed when it passed a thorough stakeholder review.  Upon completion, strict change control was set in place, requiring the organizational equivalent of an act of congress to modify.  This type of requirements documentation is probably familiar to you, and it is not an iterative requirements doc. Authors of requirements docs that cannot be easily changed have an overwhelming burden to continue analyzing beyond the point of effective prudence.  These documents take a long time to "complete" and once completed, they are not maintained due to the organizational resistance to change.  These documents are often very expensive to create and filled with inaccuracies and bad assumptions. Instead of providing clear guidance, accurate estimates, and minimizing scope creep, they creating more harm than good.   This is precisely what has lead to the agile wave and a constant search for a better way.

The "better way" is not to abandon documentation all together, as desirable as that may be to some.  Requirements communications always live longer than the verbal discussion they are born in.  If they are not captured somehow, problems later in the software development cycle will surely ensue.  If requirements documentation can be viewed as an iterative communications medium, a capture of conversation, and not a stone tablet, your documentation efforts will be worthwhile and lead to less scope creep, rework, and higher quality software.  Welcome to the future.