Silly C# Dictionary Error

So, I stumbled across an interesting error while coding today, which in hindsight is really simple (less tactful and more self-deprecating would be to say “stupid”). In C# (3.0), there is a set of classes that supply you with some really common generic data structures, such as the Stack or the Queue. Using generics, you specify the type(s) such that you can have handy, type-safe collections to work with.

In a small bit of code, I was making use of the Dictionary, more specifically Dictionary. I was first filling it with keys only, which corresponded to specific pages in a large PDF. I then iterated (foreach) through said Dictionary a second time, chopping up the large PDF based on the indexed pages, creating smaller ones, and putting the resultant file name in the value part of the KeyValuePair. Many times, we fill and iterate in a read-only way with the structures, so this error is uncommon if you forget something basic about them.

When first stepping through my code, on the second foreach block, I got a “Collection was modified; enumeration operation may not execute.” Wha? I had forgotten that you will get this error if any reference in the Dictionary gets changed to a new reference. IOW, if you take an instance of a class that is stored in the Dictionary and replace it with a different one, while looping, the IEnumerator notices the change and chokes on the “dirty” collection.

You are allowed to change the properties of objects stored in your collection, though. So, a simple fix is that instead of using a string, which is immutable, and doing something like:

Dictionary pageDictionary<int,string> = new Dictionary();
for (int i = 1; i <= theDoc.PageCount; i++)  // first loop
  pageDictionary.Add(theDoc.PageNumber, "")
foreach (KeyValuePair<int,string> idxPair in pageDictionary)  // second loop
  pageDictionary[pageIndex] = extractFileName;

You should use StringBuilder, which is like String, but mutable:

Dictionary pageDictionary<int,StringBuilder> = new Dictionary();
for (int i = 1; i <= theDoc.PageCount; i++)  // first loop
  pageDictionary.Add(theDoc.PageNumber, "")
foreach (KeyValuePair<int,StringBuilder> idxPair in pageDictionary)  // second loop

Duh. Silly me.

Adding A BitTorrent Client To A Proxmox Host

The Proxmox VE (a.k.a. PVE) host does not have a BitTorrent client by default, but this is a common way to download stuff in the Linux world. Here are the steps I took to setup BitTorrent on the PVE host system.

The PVE host environment is basically a Debian installation, so the first step is to download the newest BitTorrent tarball to a convenient directory. There are deb packages, but we will need to get a little manual to get it installed properly in a 64-bit OS. I SSH’ed into the host as root, created and used a /root/downloads/ directory for the download. Make sure to verify the BitTorrent site and download the newest version of the client.

The easiest way to download is to use wget:

On an unmodified PVE host, you’ll be missing a lot of dependent packages and should install those beforehand. These packages include python-wxgtk2.6, python-crypto, python-twisted and python-zopeinterface. Install each package with:

# apt-get install [package name].deb

There is one more dependency package that cannot be installed, python-psyco, as there is no 64-bit version and PVE is 64-bit. BitTorrent seems to work without it, though. The only way to deal with this is to edit the dependency out of the deb package and regenerate a deb package.

# tar xpfz BitTorrent-5.2.2.tar.gz
# cd BitTorrent-5.2.2
# vi debian/control

In the file, remove and locate the dependency on python-psyco by deleting the ‘psyco’ entry from the Depends line. This will drop the check when you install it. Next, I install sudo and use it to get BitTorrent rebuilt with the changed file that results in a new package.

# apt-get install sudo
# sudo bash

Finally, install the BitTorrent client and download torrent files by calling bittorrent-console at the command line:

# cd dist
# dpkg -i bittorrent_5.2.2_python2.4.deb
# bittorrent-console ‘some-link-to-a-torrent-file’

By default, the file will end up in /root/BitTorrent Downloads/. Now, you can download to your heart’s content, pun intended…

Top 13 Funny Software Development Quotes

Over the years, I’ve collected some of the smartest-yet-funny software development quotes I have read. Here’s the current short list in no particular order. Oddly enough, there are thirteen of them and they all address the woes of programming.

Feel free to add any like quotes in the comment section!

  1. “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” – Tom Cargill
  2. “In order to understand recursion, one must first understand recursion.” – Author Unknown
  3. “I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.” – Bjarne Stroustrup
  4. “A computer lets you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila.” – Mitch Ratcliffe
  5. “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” -C.A.R. Hoare
  6. “The gap between theory and practice is not as wide in theory as it is in practice.” – Author Unknown
  7. “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.” – Gerald Weinberg
  8. “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” – Edsger Dijkstra
  9. “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates
  10. “Nine people can’t make a baby in a month.” – Fred Brooks
  11. “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” – Rich Cook
  12. “There are two major products that come out of Berkeley: LSD and UNIX. We don’t believe this to be a coincidence.” – Jeremy S. Anderson
  13. “Before software can be reusable it first has to be usable.” – Ralph Johnson

Outsourced Or In-House Developers?

So, you have a workload of software projects, a veritable plethora of projects to get off your plate. Or, maybe you are considering an expansion of your capabilities. Your current team is tapped out… hopefully not overworked and tired; you don’t want to break their backs.

WARNING: I will be using the word “outsourcee” to refer to any entity not in-house performing work on behalf of your company. There’s nothing wrong with the word itself, although it’s full of negative connotations of lost jobs, cheap labor and evil executives. But, if you are a die-hard isolationist or a nationalist, you will be unable to read further. You have been warned. 🙂

You’re looking at various reasons and wondering if you should hire more in-house developers, or farm out. Here’s the top-level factors I look at to help me decide when to farm the work out. Of course, this is all from an SMB point-of-view; larger companies have a completely different perspective and set of tests to check against.

  • Niche/Esoteric Skills: If the project involves some fringe technology, or unique skill set that will not see much re-use in-house, then farm it out. Note that this could be an emerging technology, or an old one that would bore your in-house team to tears. Usually, hiring in-house for this is a big challenge anyways…
  • Time-To-Market Pressure: If the project involves the need to get something out before competitors claim the territory, farm it out. You should seek an outsourcing shop that will properly staff up so as to get your project out in the time frame you set for it. You’ll pay through the nose, but that may be the difference between sick or swim…
  • Overwhelming Workload: Obviously, one reason to consider farming out is if you have a large spike in the overall short-term workload. This is quite common in small businesses. Instead of slowing down and stretching thin, just bring in short-term, contract-based workers to shore up your team(s).
  • One-off or Short-Term Project: If the project is a side-bar to a core project, or some “throw-away” task where ongoing maintenance is not going to be an issue, consider farming it out and don’t bog down your core, in-house team(s) with it.
  • Experience Gain: You may want to consider randomly outsourcing the “easy, non-critical ones” just to gain experience with outsourcing options in your local area, or the broader market, simply so that you then know a little bit more about who to go to when it really counts.

There are undoubtedly more reasons, but I think these are the main, big ones. The more these reasons exist in any one project, the more you should consider farming out the work. Otherwise, don’t. It is better, and less costly, to go in-house. No really!

First, less face it, every dollar you spend creates/elevates talent in some individual, and it is generally best to keep that talent close to your vest rather than see it go to another company, especially a competitor.

Second, there’s more to developers than churning out code, even the so-called “boilerplate” stuff. Being able to effectively understand and translate requirements and interact with business users comes, in large part, from close familiarity with the people and the processes, a.k.a. the “ramp-up” or “learning curve”, and the short feedback cycle that comes from being in-house. These two have had a larger, empirical, hard-to-measure impact on any team’s performance than anything else. It doesn’t help the “super-awesome outsourced guru” if he has to wait two days for an email reply on a process issue from some department because they are swamped with some monthly peak of work. Every time you farm out, you’ll hit this over and over again. In-house is undoubtedly both a short-term and long-term investment. Treat it as such.

Lastly, contrary to the typical assumption I hear, farming out is usually not cheaper. A good, in-house team will simply cost less than an equivalent, good outsourced team, even if you consider all indirect costs. My off-the-cuff, empirical, “from-the-SMB” conversion factor is that outsourced is 2-4x more than in-house. One main problem is that because the outsourcing market, even post-dotcom bubble, has an incredibly high markup on IT work. Unfortunately, the perception that outsourcing is cheaper is because the comparison is usually between a bad, in-house team and a good outsourced consultancy.

If you are going to farm it out, the next question typically becomes who to farm out to. There are four general categories:

  • Freelancers: These are the “unincorporated” outsourcees that cost on the low-end of my conversion factor. They usually don’t have much overhead to worry about because the job isn’t their primary source of income. Lots of developers from large, status-quo-loving companies want to expand their skills and so pick up work on the side. Or, out-of-work, between-job developers will take on short-term contracts to fill the income gap. The main and dominant problem is the lack of accountability on multiple levels, from the personal involvement to the legal ramifications if they drop out on you. If you don’t know any freelancers, consider shopping on websites like Rent-A-Coder.
  • Local Outsourcee: The local outsourcee is a local, incorporated shop, usually with a smallish team or teams, that makes a living providing recurrent, happy IT service. They are usually not cheap, because of their business overhead. However, as a manager, if I can’t keep the capital in the house, I sure try to keep it in the neighborhood, because it eventually comes back to us. I’m not talking about “paying it forward” (although if that does happen, then great!), just that a vibrant local economy is indirectly good for my business. On a selfish level, it also helps me build out my local personal and corporate network of contacts.
  • Remote Outsourcee: There are all sorts of levels of outsourcing here, ranging from neighboring states, to neighboring countries to full use of sweatshops in Central Nepal. If you are an SMB, you should really not go to this option, unless you have a direct reference to an active shop used actively by another SMB you know and trust. I have heard too many horror stories of SMBs burned by this kind of outsourcing. The problem is that lots of these big offshore consultancies are driven by big customers and you’ll simply get lost in the mix. The smaller, satellite consultancies that emerge in such areas are usually unable to serve you properly because the big shops drain the area of real talent. The former is exorbitantly expensive, the latter is expensive in terms of direct cost due to the inevitable mess-ups. You’d be surprised how not cheap offshore work in places like India has become.
  • Internship: Don’t forget to consider using variants of the idea of internship. The concept is that you get some raw talent and let him/her beat his head on a project in exchange for a low wage and a great reference. Like farming out locally, there’s a lot of goodwill generated in this route. You may find your next hire in an intern; you certainly may find out who not to hire too. Each individual will hopefully go on to speak highly of you to other students or junior co-workers, generating potential future hiring opportunities. But, if you want to do this right, don’t hire just to stick a kid in the corner cube, and leave him or her to sink-or-swim. What you save in hard dollars will have to be spent in your own or senior developer’s hand-holding time.

This pretty much sums up how I consider outsourcing, short of a lengthier novella on the subject.

One last warning: Be open with the work and get your team’s opinion on farming out any work. Don’t let them hear about it indirectly and give them the opportunity to step up if they want and can deliver. Psychologically, from a morale point-of-view, keeping your team out of the loop is a big no-no.

What are your experiences? Do they match up with the above?