I used to believe (and teach) that comments were a good and necessary thing. Especially "why comments" even bordering on telling the "why" story along side the "how" in the code. The theory was that keeping the two parts of the story together acted as a cross-check during code review and a guide during development and maintenance. That methodology worked really well for a long time, though it did have it's occasional problems. I have now abandoned that methodology and have begun teaching and requiring a fully integrated alternative.

It was a painful transition, but I have been convinced that the best code does a good job at telling both the why and the how. Source code should not be viewed simply as instructions for the computer but rather as an intermediate language that can be shared between the software developers and machines. Both hardware and wetware should be able to interpret the source code with precision and some deeper understanding. It is harder to write that kind of code, but the extra effort has made a profound difference in the quality and maintainability of my code since... Now I teach it the new way.

Here is a blog post I made at the beginning of that transition: http://www.lifeatwarp9.com/2011/02/comments-are-not-literature-i-must-be-mad/

A case in point: I recently had to hand off some of my code to a developer who was completely unfamiliar with the project without much time budgeted for getting them up to speed on it. I was prepared for all the usual breakage and frustration associated with that kind of forced hand-off. Since that code was written with a fully integrated approach in mind the new developer was able to get up to speed quickly and complete their project without any significant learning effort and without any significant errors along the way. Comparing this case with similar cases in the past the "costs" associated with this new methodology are "in the noise" compared to the old.

We have a similar problem at the Mad Lab - we generate a lot of data (from our digital studio and other projects), we need access all the time, and we need reliable storage.

At first we were putting lots of drives into a PC -- but that led to problems. For one thing there was a single point of failure (main board, power supply, take your pick). Another problem was that the system was loud and power hungry. Then there was the backup problem -- there was no efficient way to do it without building another system just like it --- you can't ship TB of data off-site via the 'Net for backups, it just isn't practical. Then to make matters worse we decided we couldn't do anything else with the server without putting our data at risk... that was the last straw for me -- The server was overkill for the task and couldn't be used for anything else. I was stuck in a paradigm - I knew better - but I'd forgotten that temporarily...

Then I hit upon the solution of using D-Link 2-Bay network storage devices. http://www.dlink.com/products/?pid=509 These little guys are reliable, solid, efficient, and affordable. They're also pretty green because they will spin down when you're not using them thus saving power and POH time on the drives.

We use them in pairs: NS0 for storage, and BS0 for backup. With a firmware upgrade they will do NFS - so we have one of our servers map the two devices and then rsync NS0 to BS0 once per day. Newer versions may have the NFS capability built in (it was on it's way, it was beta firmware when we did it).

Now we have the key features of the high-end NAS solutions we use in data centers, but we have it on the cheap. The solution is scalable (more storage, more enclosures), reliable (mirrored drives all around, fast and easy to access (NFS or Samba - take your pick), provides redundancy (outboard power supply for each enclosure - easy to swap, separate controller for each pair of drives), and easy to manage (what's not to love about a scheduled rsync task via nfs for automated backups?).

We can easily access the data from either windows or *nix boxen on the internal network without any trouble. When we need to access the data from outside the Mad Lab we shell into a server and sftp what we need from there.

Here is a pic of the two of them in the rack: http://www.lifeatwarp9.com/wp-content/uploads/2010/01/MadRackBefore-225x300.jpg We've been using this setup for quite a while now and it's been dead solid. When we need to expand we just plug in another unit and map it. We've also installed this kind of configuration in customer facilities to manage backups and solve other storage problems on the cheap.

_M

You will probably want to go the other way with it... Instead of sitting around a table facing each-other, have them sitting inside a ring facing away from each-other.

I've had teams work lots of different ways --- the ring idea has always worked best.

Most of the time when they want quick collaboration it involves something like "take a look at this" -- either on a note pad, or more commonly on a screen. When facing a table the only way to do that is turn the screens (trouble) or walk around (inconvenient).

With the ring concept a quick turn of the chair does the trick and they are face-to-face or co-piloting a workstation.

Also -- when they don't want to be distracted the ear-buds go in and they're facing away from everything.

Also (I know this isn't on most folks radar) -- sneezes an coughs go AWAY from the other devs, so it's not so easy to spread colds etc.

Finally -- from inside the circle the walls of the circle are large and offer a lot of space for personal effects, charts, artwork, etc... It provides a good opportunity for personal expression without adding extra real-estate.

Get in the circle -- you'll be glad you did for lots of reasons.

_M

We've been doing this with Message Sniffer since day 1 (many years now!). It's very effective. In fact some of the first rules we coded (abstracts we call them) are still active and effective. Along the way we've developed automation to help us see key pieces of these patterns in real-time, and bots to take advantage of other vectors, but the process is still fundamentally the same for template driven spam.

It should be noted that this vector breaks down badly when the spam template is strongly modeled after legitimate messages - such is the case for many phishing spam.

Clearly it is not a complete solution either -- I'd say that it's good for more than 40% of new spam campaigns and less than 70% on average.

I have used many IDEs over the years from Borland, M$oft, Metrowerks, IBM - but now I use Code::Blocks.

I write primarily cross-platform command line and server apps.

What I like about C::B is that it doesn't get in my way and I can easily switch back and forth between my Windows and Linux machines without skipping a beat. Using MinGW under the covers and watching my coding I am able to truly "write once & run everywhere".

C::B gives me the basic things I need and then gets out of the way... What's not to love?

I could use anything -- but C::B is consistently getting the job done for me.

I also poke at things from time to time with Visual Slick Edit and of course VIM ... but I wouldn't classify either of those as IDEs (not the way I use them anyway)