Skip to main content

88 posts tagged with "programming"

View All Tags

The Mythical Man-Month: Wiki and Customer Service

· 3 min read
info

Part three in a series about Dr. Frederick Brooks Jr.'s The Mythical Man-Month:

1, 2, 3 (this piece), 4, 5

Many of the recommendations Dr. Brooks makes in this work can seem outdated at first glance; however, it does not take much to bring them into today's software development environments. Take the telephone log for example:

"One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive." (p69)

The Mythical Man-Month: Conceptual Integrity

· 4 min read
info

Part two in a series about Dr. Frederick Brooks Jr.'s The Mythical Man-Month:

1, 2 (this piece), 3, 4, 5

Aside from being a fascinating inside-look at some of the challenges faced by the mainframe programmers of the sixties, The Mythical Man-Month presents many lessons-learned that are no less applicable today. This is the second article in a series exploring some of these lessons, in particular: conceptual integrity.

Rediscovering C++ / Performing SQL Bulk Copy Operations

· 5 min read

When last I worked with C++, it was while working on my master's thesis ten years ago, using a basic text editor in a Red Hat Linux 5.0 installation. A new task in front of me: replace a Reporting Services report, which was exporting to CSV, with a new solution that will allow me to create multiple files, with max 150,000 records each. The first challenge is speed: with that many records, only bulk copy will be reasonable. The second is splitting the file. I thought about calling BCP from a C# process, because unfortunately managed code only offers bulk loading into a SQL Server database, not from database to file. But C++ is another story, thanks to the Bulk Copy Driver Extensions made available by Microsoft. So, time for a C# developer to brush up on C++, and learn it the Visual Studio way!

What about uint?

· One min read

I'm writing a class with several methods that take integer input. The input values cannot be less than zero. Since we're not on .Net 4.0 yet, I'm manually writing code contracts (that is, my functions check preconditions), e.g. before doing anything else, I write something like…

if (sequenceNumber < 0)
{
    throw new ArgumentOutOfRangeException("sequenceNumber", "Sequence number must be 0 or greater");
}

This got me thinking: why don't we ever use unsigned integers? Seems like having a uint would better communicate the requirement, and would simply not allow a negative number. The main answer seems to be that casting between uint and other data types, which is inevitable, is ugly. And that uint is not CLS compliant. Even though I'm not trying to write CLS-compliant code at the moment, I think I'll stick with int — because that is our existing convention, and I don't see enough reason to change the convention.

Diagnosing Production Problems: Zeroth Law

· 2 min read

Stephen's first law of diagnosing problems in production should have been: make sure you actually know the scope of the problem. We have a process that checks for duplicates in an inbound file. Records marked as duplicates are not moved into production. A refinement of the process was installed this week. All the sudden, e-mails showed that thousands of records were being marked as duplicates. I came over to help investigate, and found people looking at code, trying to figure out what was going on, because they knew without doubt that these records were not in fact duplicates.

But we needed to step back and ask what is the scope of the problem? We looked at the e-mail with the duplicates, picked a name or two from the list, and looked in the original input files and confirmed that they were not in the files. So how/why were they reported? But then let's set that aside, and ask: did all of today's records make it into production? If yes, then we have a problem but not a crisis. The answer was yes: we could see a 1-1 match between inbound file and outbound production data. Therefore, we have a minor reporting problem, but the core of the system was working just fine. Panic averted.

So what was the cause? A staging table that had not been truncated after a previous file was processed. All those records were being reported as duplicates.

Diagnosing Production Problems: First Law

· One min read

Stephen's first law of diagnosing problems in production: try to replicate in test. (Assumptions: you have a test environment, you use it regularly, and it is reasonably close to production). Sometimes you just can't replicate the problem — for instance, it might be due to an oddity in a customer data file that you're not allowed to run outside of production. In those cases, see if you can use a proxy. For instance, try copying the file and masking the sensitive data, then running it in the test environment (of course, the masking process might cover up the error that is causing all the problems).

Production needs to stay clean, and as developers we need to keep our hands out of it as much as possible. This is particularly true in a highly secure environment with strong separation of duties, wherein you might have to drag a sys admin into the picture just to get to obscure log files, for instance. Replicate the issue, solve it, document it, and make sure everyone else in the company is able to share in the lessons learned.

safnet logo