Exceptions

Some comments on C# exceptions:
Unlike Java, C# doesn’t have checked exceptions. Heres what Anders Hejlsberg has to say about it. And heres an MSDN article.
In C#, the ‘throw’ keyword preserves the type of an exception.

This results in “Arithmetic Exception caught” being output to the console.

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.

Tracking Software Complexity

Building great software has as much to do with the actual design and coding of it, as it has to do with project management. As they say, behind every successful software project is a team that has dedicatedly followed some form of software methodology. As team and code size increases, it becomes more and more imperative that some methodology be rigorously followed.

So what do I mean by ‘some form of software methodology’? I mean a software development method that works for the team. Specifically, I’m talking about unit test policies, build integration policies, code ownership policies etc.

Now the method doesn’t have to be TSP-PSP/Agile/Extreme Programming (or some other known method), it could be something the team came up with, feels comfotable with, and most importantly follows dedicatedly.

Hello World!

The obligatory “Hello World!” first post!

About me: I work as a software developer with .NET technologies, in Seattle.

Disclaimer
The information in this weblog is provided “AS IS” with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. The opinions expressed herein are solely by own. Inappropriate comments will be deleted at the authors discretion. All code samples are provided “AS IS” without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time, snapshot you should not consider out of date posts to reflect my current thoughts and opinions.