Tracking Software Complexity Part II

The last team I worked with had a grand total of 4 members. That is, four people, in the entire company, were working on the project. We were the business, development team, and the testing team all rolled into one. The actual code was quite complex, we used all sorts of C# 2.0 constructs like generics, generic delegates, nullable types, and anonymous methods. The business logic consisted mainly of currencies, securities, portfolios, and equities. A lot of statistical calculations were involved and required lots of PInvoke calls to the NAG C mathematical library. We met once a week, and our build and deployment consisted of making sure our code executes on our machine, and then uploading the bits to Source Depot.

Compared to that, in my current project, there are about 100 people involved (a whole floor, if you can believe it!). This includes the business, the managers, the testers, the support, and the developers. We work on a part of an extended system. The actual code I write here is quite straightforward. But consider some of the problems we have had to face while deploying our solution. We have a bunch of (10+) windows services (most of them interfacing with external systems), some web services, and, of course, a SQL server backend. We have to deploy on three separate environments. Each environment consists of three machines (two machines running our web and windows services and one sql machine), spread over at least two domains. The services run under different accounts and have different accessibility permissions. Add to the mix clustered servers, virtual servers, certificates for authorization, and services sending out emails, and you can imagine what a great time we had deploying our solution.

Here is a partial list of issues we ran into (hopefully, we have learnt from our mistakes),

  • a critical network password expired and had to be reset, while we were deploying the bits
  • an external system had rebuilt their database and so one of our services was failing
  • configuration files had to be changed to match different drives for installation
  • Microsoft Enterprise Libraries weren’t installed on one of the machines
  • we ran out of disk space on a machine, while sanity checking our deployment
  • and (my personal favorite), we installed the wrong bits

The point I’m trying to make here is that software complexity isn’t just about code complexity (LOC, cyclomatic complexity or any other metric), or algorithm optimization, or database design, or patterns used. Software complexity is also about the things that don’t go into the code – the pressure from business, the meetings, the deadlines, the team, the build, the deployment, and other such factors. These affect not only the quality of the code (directly or indirectly), but also mean the difference between great software and barely usuable software.


About soumya chattopadhyay
I live and work in Seattle, WA. I work with Microsoft technologies, and I'm especially interested in C#.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: