Wayne Allen's Weblog

Why is Software Hard?

I read an article recently that in part was asking the question, "why is software so hard?" They were using the statistics that 1/3 - 2/3 of all projects are late, over budget or canceled. Whether this is really any different in other industries is another article.

One of the reasons software is hard is that it depends on many individual parts from multiple development teams from multiple vendors. Since each of these parts has differing levels of quality, robustness, and other non-functional type attributes the product your team is putting together has to account for these differences, most of which are unknown at the time your received them. Additionally vendors release patches for various reasons that change these attributes in subtle and not so subtle ways.

One third party vendor we deal with releases patches on a monthly basis. However, from time to time they (usually unintentionally) change the API signatures. As an integrator of this product these kinds of changes cause no end of debugging and explanations to management why things are broken, or can't go forward.

Multiply this times the number of vendors you use and the varity of changes that can be made and you have a recipie for schedule deviations and cost variances. It is no wonder some companies prefer to build vs. buy.

How do we fix this? No easy answers really. Some pundits call for holding vendors accountable, but how? We already do to some extent by continuing to buy their products or not. Another solution batted about is some kind of quality standard, but the realities and costs of such a standard are not realistic.

Probably the most realistic way is for each company/team to take responsibility on themselves to produce high quality software through whatever means are appropiate for them and to communicate with your clients about the realities of your product.

Session Variables are Globals Too

Patterns for Replacing Global Variables - Reduce Scope of Global

The closest I can come to this one is Reduce Scope of Variable.

Add Parameter from Refactoring by Fowler (buy it if you don't own it) and Introduce Parameter Object are also related patterns.

The downside to this pattern combination is that it can affect large numbers of methods and may be incorrect if the global is used to create a side effect. Essentially this is an out parameter, but with unknown scope.

Summary: Good, but hard to predict where side effects are implied.

Patterns for Replacing Global Variables - Replace Global(s) with Singleton

Replace Global(s) with Singleton

I'm not sure this is a superior solution as it replaces many globals with one global structure. Granted you can add access control, but to what effect since you must grant global read/write, also it is difficult to enforce semantic meaning/intent.

I'd go as far as to say that using singletons is really no better than having a naming convention for globals.

Additionally, it makes code difficult to test since many singletons in the OO world are typically self configuring and are referenced deep down inside private methods. How does one test code that gets it's database connection inside a private method from a singleton ? (Don't laugh, it happens all the time.)

Summary: Better than many globals, but just barely.

Global Variables Considered Harmful

Prof. William Wulf and Mary Shaw wrote a paper of this title in 1973, although I couldn't find the original paper online I did find some references.

Here are the key disadvantages:

1. Side effects - hidden access
2. Indiscriminant access - can't prevent access - may be difficult to make changes later
3. Screening - may lose access via new declaration of variable
4. Aliasing - control shared access to prevent more than one name for reference variables.

Backgound: I have been adding unit tests to existing stand-alone code to support refactoring and eventual migration to our current framework. The code is full of global variable references. Not only that, but work-arounds have been developed that depend on side effects caused by the use of a single global to mean more than one thing depending on which code ran last.

Because of all the things identified by Prof. Wulf I cannot be sure that if I change anything the code will still run as originally created. However, I must change things to make them testable. Luckily I do have access to other developers who have worked on the application (just fix the bug, don't change anything else) for some level of confidence about what is supposed to happen. Also, I don't have any refactoring tools (VB6) so all changes must be tediously made by hand with great attention to detail. What fun!

Version Control

I had such good responce to my original post on version control software I thought I'd risk posing the question to a wider audience again.

What version control software do you use? What version control software did you use, but replaced? And why?

We are considering replacing VSS. Current candidates are CVS, Perforce, Vault and maybe Subversion.

Comments, flames, additions?

Project Organization

In reflecting on my previous post regarding shared libraries in VSS vs CVS I realized that the end of the post got to the real meat of the matter. Turns out we are using a feature of VSS to help us organize our shared libraries, however, shared libraries really have very little to do with version control (except for released versions of course).

So I did a little more research and found the Team Development articles on MSDN, specifically the one on Managing Dependancies. Here is their main recommendation:

Project references are the main reason you should adopt a single solution or partitioned single solution model wherever possible.

In the Single and Partitioned Solution Systems section:

Use project references wherever possible and aim to minimize the use of file references.

These recommendations are a little simplistic. Surely Microsoft dosen't have a single solution for the entire .NET framework! And they are only building a single product.

Further on they propose an alternative that sounds promising - use a build server and place the shared libraries on a file share. Additionally you can copy the shared libraries locally from time to time to support disconnected development and developer control over when libraries are updated.

This sounds like it will work well as long as you have a build server and all developers map the shared library share to the same drive letter. In fact using a mapped drive letter allows a lot of flexability in that just by changing the drive letter mapping you can point to the release version, debug version or the local version of the shared libraries since VS.NET stores the absolute path to shared libraries in the project file (in the HintPath attribute).

Weblogs as Community

Spatial Thinker

Issues Moving to CVS from VSS

We are considering moving from VSS to CVS but have run into some feature differences (i.e. sharing) that we currently rely on to distribute shared libraries to all dependant projects.

Our primary constraint is that we want to keep using VS.NET (specifically solution files) for development.

The two solutions we've come up with are: place the shared libraries (dlls) in well known locations and use relative paths to reference them. Or somehow integrate NAnt scripts into the local developer build process and build all the dependancies whenever the source changes.

I know this has been solved before as it is not specifically a CVS issues, but rather a shared library issue. Anyone have any suggestions?