Software Made Simple

In a previous article, I mentioned that you should consider building a customization mechanism into your software if you think you’ll need to customize it in order to make a sale. This is frequently a requirement for large, expensive enterprise software.

So, how would you go about this? Here are a few ways that I’ve done it:

Plugins
If you want to provide a way to allow others to customize your software without having access to its source code, then plugins are the way to go.

Plugins are a common way to add additional functionality to an application. You define a plugin format such that someone else can create some code that your application can use just by dropping it in. Most of the development IDEs out there support this mechanism in some way. Firefox also has a great plugin capability which they call “Extensions”.

I’ve had success using .NET to create plugins. An end-user can just create a class library using an interface you have defined and drop the resulting DLL into your plugin folder. This ought to work equally well in Java, although I have not done it myself. REALbasic does not have reflection yet, but it does have RBScript, which can be used to add new functionality. RBScripts are just text files, but you can use them very similarly to plugins.
A problem with plugins is that they may not give you the level of customization that you need. They are isolated and are really great at providing new function points, but may not the best way to change overall business flow, for example.

Hooks
Similar to plugins, but a little more invasive is the concept of hooks. With these, you identify points in your base product code where you want the ability to be able to call customized code. These points simply call unimplemented routines. These routines are replaced with customized code as necessary (the customized code is maintained separately from the base product code). A complete build of the customized product includes both sets of code.

This has the benefit of allowing you to upgrade your base code without breaking the customized code, at least in theory. However, since there is no restriction on what the customized code can do you might find that sometimes something doesn’t work right, but most of the time I find it to be effective.

A downside to hooks is that it can be hard to guess where to put the hooks. You inevitably run into a place where you need a hook, but do not have one, forcing you to upgrade your base product just to add the hook. In addition, unless you give them source code, your customers will not generally be able to access your hooks.

Overriding
This may not be great, but I have used it and it does work. You could create your application structure using inheritance to support a customization layer. Essentially your code would be structured like this:

Base System:

Base Code Layer -> Customization Layer -> Usage Layer
Customized System:

Customization Layer

In the Base System, the Customization and Usage Layers do not contain any actual code. The User Layer is just the final classes that are referenced by the rest of your code.

To customize, you simply add code to the customization layer to either extend or override what the base layer does. This customization layer should be stored in a separate source repository so that you can have different customizations for different customers. Your build would pull down the base and user layers, overlay a specific customized layer on top of it and then build it all together.

This technique is more complex than I like because it requires lots of virtual methods in your base layer and a really good understanding of the object model, but it will allow you to provide customers with powerful customizations, while still retaining the ability to upgrade the base layer.

Mix and Match

It certainly possible to mix each of these techniques together, particularly when you want to allows others to customize your product while at the same time retaining a more powerful mechanism for your in-house staff to use.

What sort of techniques do you use?

It seems like Microsoft Team Foundation Server (TFS) is starting to get a bit more traction. I’ve been using it for several months now and find it to be a pretty good solution, at least for those of you doing .NET development. This posting is essentially a summary of the various TFS presentations I’ve given over the last few months.

TFS Overview

TFS is a separate solution from Microsoft for complete application lifecycle management. It is tightly integrated with Visual Studio 2005 Team System, but does not actually require it. If you are not using VS 2005 Team System, then you need to install Visual Studio Team Explorer which is basically just an extremely lightweight version of Visual Studio 2005.

None of TFS features are revolutionary.  The big thing that it brings to the table is that each of its features have some level of integration with each other.

TFS Features

TFS has the following main features:

• Project Management
• Work Item Tracking
• Source Control
• Build Server
• Reporting

The following sections give a brief overview of each feature.

Project Management

With TFS, everything is done within the confines of a project. And each project that is created follows a specific “methodology”. Included with TFS are two methodologies: Microsoft Solution Framework 4.0 for Agile Software Development and Capability Maturity Model Institute for Agile Software Development.

Everything in the entire project (work items, source control, builds, reports) can be accessed from within Visual Studio (or Team Explorer). In addition, TFS also creates a web-based project portal for each project for easy document and report access. The portal uses Microsoft Sharepoint, which also allows you to enable document versions.

As we’ll see below, TFS is integrated with both Microsoft Project and Microsoft Excel.

Work Item Tracking

Work Items are discrete pieces of information about your work. By default, these work items are included with TFS, but you can create your own as well: Bug, Risk, Quality of Service Requirement, Scenario and Task.

Work items are fully customizable. You can add your own fields to any work item type, you can hide fields you don’t use and you have complete control over where they appear on the form.

Work items can be linked to Source Control Change Sets, Project files, Excel files and Builds. The linking with Project and Excel is especially handy. Essentially, you can populate your Project or Excel file using a Work Item Query. Then you can edit and make changes to work items (or even add new ones) and then publish those changes back to TFS. This allows you to collect a bunch of Task work items together in a project plan or to just collect some subset of Bug work items in an Excel spreadsheet.

Source Control

TFS Source Control is integrated within the Visual Studio 2005 IDE. If you are not using Visual Studio 2005, then you can just use Team Explorer to manage your source code or you can use the Microsoft MSCCI plug-in with your IDE of choice to connect to TFS. I’ve used the plug-in with Visual Studio 2003 .NET and it works pretty well.

Source control has a concept called “Checkin Policies.” These policies allow you to set, on a project-by-project basis, specific rules that must be followed when code is checked in. The default policies are: Code Analysis, Work Items and Unit Tests. For example, if I enable the Work Items policy, then when a developer tries to check in code they will also be required to associate the checkins with at least one work item. This can be a great way to link work that was done with what was actually changed. The Code Analysis policy will run the Visual Studio 2005 static code analysis on the code and only allow it to be checked in if it passes. The Unit Test policy will run Visual Studio 2005 unit tests on the code and only allow the checkin if it passes.

When you checkin multiple files at once, they are grouped into an atomic package called a “Change Set”. These Change Sets are linked to builds as well see in a moment.

A unique feature to TFS Source Control is Shelving. Shelving allows you to check code into source control but to not put it into the current tree. It really just puts it on the shelf. This is a great way to make sure that code is always in Source Control even if it is not quite ready to be officially checked in yet.

Lastly, for those of you that work remotely, TFS Source Control also includes a Proxy Server that caches source on your own local servers for better performance.

Build Server

TFS includes a separate service you can install on your build machines so that TFS can automate your builds. When using TFS Build, you can initiate a build on the build server directly from Visual Studio 2005. Because TFS is so integrated, a build knows which Change Sets it is including and if you’ve associated work items to your checkins, knows which work items were included in the build.

In addition, TFS Build can also run unit tests and static code analysis to help you gauge the quality of your builds.

Reporting

TFS uses SQL Server 2005 Reporting Services to manage its reporting needs. It includes many built-in reports and you can create your own reports using Visual Studio 2005. These reports can then be published to TFS so that others on your team can use them.

The reports themselves run from Visual Studio 2005, Team Explorer or the web portal.

Visual Studio Team System

I’ve written another post here on all the various flavors of Visual Studio, so I won’t go into that again here.

Cost

I also won’t go into specific pricing, but TFS is not necessarily cheap. There are few things to keep in mind, though. If you have a MSDN subscription, you can use TFS Workgroup Edition for free. This edition allows for up to five users to connect to TFS. TFS Standard Edition is a separate purchase (up to about $3000), but you also need to buy client access licenses (up to about $500) for anyone that needs to connect to it that does not already have a license to a Visual Studio 2005 Team edition.  And of course, you can always try the 180-day trial.

Does TFS make sense for you? It depends. I think if having all these things in a nice integrated package is important to you, then you should definitely strongly consider TFS. If not, then you can probably get the same overal functionality for less money by picking up solutions from different vendors.

My company, LogicalVue Software, can help you to evaluate TFS for your business.

Everybody is talking about Web 2.0 these days. What is it? Honestly, I just don’t care.

Don’t get me wrong, I think web applications are quite useful. It is nice to be able to access your information anywhere that you have an internet connection, but they are not a panacea, even with the fancy AJAXy Web 2.0. First, they require an always-on internet connection. This is not always realistic. I like WordPress, but if I were on a plane right now I’d be writing this in NotePad. What if your customer has to suffer with a dial-up connection? What if the network goes down (it does happen)?  I also use ThinkFree.com for word processing and spreadsheets, but sometimes I just prefer to run my word processor locally (and I actually use ThinkFree Office Desktop for that).

But I’m not saying that desktop applications are perfect. They have to be installed on every machine that you use which can be a pain (and licensing doesn’t always allow it either). They have to be upgraded usually manually, although this can be made somewhat automatic depending on the application.

What do you build your software with?
Do you need cross-platform capability? If so, a web application might be a good bet, but be careful not to lock yourself into being Internet Explorer specific because then you’re not really cross-platform at all.

For web applications, I like to use either ASP.NET or Java Server Faces using Java Studio Creator, but I remain torn between these two technologies.  I really like ASP.NET and have done a lot of stuff with it, but developing with it on Mac OS X is not quite feasible yet (yes, I know about Mono).  JSF and Java Studio Creator both looks pretty good, but my Java experience is limited.  I am spending more time learning about it, though.  I’ve bought the Java Studio Creator Field Guide, Thinking in Java and Learning Java from O’ Reilly.

If you need cross-platform desktop applications, then keep in mind that both Java and REALbasic can do this. Java is powerful and complex, but will likely do everything you need. REALbasic is fast, easy, fully native and will likely do most things you need.  Java has a bad rap on the desktop, but I don’t make Java desktop apps so I can’t say if it is deserved.  REALbasic sometimes gets a bad rap as being a “toy” language, but it is really quite powerful.  I thoroughly enjoy using it for creating desktop applications.

I guess I’m just stating the obvious here, but the type of application you create really depends on how it will be used more than anything else.