Ian Shlasko wrote:

Drop the semi-colon? And be forced _ to resort to VB's _ horrible style of _ line continuations!?!?

Of course with the release of Visual Studio 2010, VB will be getting implicit line continuation for most areas :-) Thanks, Seth Rowe [MVP]

I think I'll expand a bit on the lava lamp idea, as it really is a good idea. I originally heard about it from Andy Hunt, one of the Agile founders, during one of his presentations. I'm sure some of the exact details are missing, but it basically goes like this: A team set up a pair of green and red lava lamps in the team room with full visibility to management and had their power sources connected to the build server. When a build would succeed, the green lava lamp would be powered, signaling that all was well. If however the build were to fail, the the green lamp would turn off and the power would be switched to the red lamp. The interesting thing is that lava lamps take a bit to warm up and start flowing, so there would be a time span after a broken build when neither lamps were lit. These lamps were in the team room and had full visibility to management. Depending on the status of the lamps, management could tell the following: 1) Green Lamp - All is well on the project. No involvement necessary. 2) No Lamps - A build error has occurred, but the team is handling it. No involvement necessary. 3) Red Lamp - Significant problem. Might be time to check with the team and see if help is needed. Thanks, Seth Rowe [MVP] http://sethrowe.blogspot.com/

To the extreme end of this, you might even look at pair programming, even if it is only one day a week. If you don't know, pair programming is a type of informal code review where two developers are sat in front of the same computer, one "drives" while the other simply looks over their shoulder and watches for other ways of doing things (not necessarily better, just other ways). The two can switch places whenever they feel it necessary. Be warned that many people are opposed to pair programming, most will say they don't like someone looking over their shoulder or they don't want to lose personal space. There also is a very common misconception that the pair will only get 1/2 the amount of work done. This is not true for experienced teams, as the chance of unknown areas declines with having two programmers, and the code should be more solid, which saves maintenance time. One other terrific way of improving development processes is to set up a continuous build environment such as CruiseControl.NET. Simply set up the server (a 4-6 hour task for someone new to CCNET) and then set up a notification service, be it email, a notification icon (CCTray is the one for CruiseControl.NET), or a pair of lava lamps (I have seen this, it's very effective). The hardest part will then be getting the developers to do constant checkins, as the build is triggered by a checkin. Then, whenever new code is added, a build is automatically started and any unit tests you have setup will be run. If the build or the tests fail, notifications will be sent out, the notification icon will turn red and popup a message, and the team is now responsible for fixing the build. CCNET will list what build failed and why, and what files were changed and by who. Since you know what files to look at, and you know that fairly few lines of code could have changed (b/c of the frequent checkins), the problem should be able to be fixed quickly. Anyways, I hope the above gives you some more ideas on how to proceed. The true test of whether or not you should stay or leave your current job is in management reaction. If management is not willing to invest their time into fixing their procedures, then I would start to wonder if they are a company that's good for you to work for. Thanks, Seth Rowe [MVP] http://sethrowe.blogspot.com/