Ernst Kuschke

Tech Ed 2006 had lots of beer, lots of sun and lots of really cool smart people. It also had no time for sleep, no women, and no chalk-and-talk agenda for delegates. This year the Chalk-and-Talk sessions' topics or location were not included in the agenda, and delegates thus were mostly unaware of them.

Nonetheless, Armand and myself had some smart engineers (guys who have built their own robots) coming to our Robotics chalk-and-talks - guys who know more about robotics in general than we do. After studying the ubercool architecture of the robotics framework from microsoft, both of us became very interested in persueing this as a hobby. One component of the framework, the Concurrency and Coordination Runtime (CCR), is a lightweight port-based concurrency library for C# 2.0 that is used to coordinate asynchronous operations. It is a library that (very cleverly) abstracts the management of threads (which is never fun) from the client. Check it out for use in your own multi-threaded applications. Once stable, this could well evolve into a language-level way of working asynchronously.

Another Chalk-and-Talk that unearthed a very interesting topic was one that was presented by Luca Bolognese (C# Lead Program Manager) and Jay Schmeltzer (VB Lead Program Manager), titled "C# vs VB". We didn't compare Luca and Jay's biceps (since we all know that C# is better, right?). Instead we discussed the work being done at Red Five Labs for a while, after which we moved on to an interesting discussion around the direction these two languages should evolve to in the future. Kevin T raised the point that VB6's biggest and best feature was the speed at which you could develop applications with, and with VB.NET that feature is gone. At the moment C# and VB.NET are just two ways in which you can harness the functionality provided by the .NET Framework - which one you want to use is a matter of personal taste. Sure, both can do stuff that the other can't, but that possibly accounts for 1% of the code most of developers will ever write.

Should C# and VB.NET stay as similar as they are? Should the VB IDE have some more 'wizards'? Should VB.NET focus on the more "beginner" developer, and C# provide more advanced features? Why should the VB guys not get those? And if VB gets ways of developing more rapidly, why should the C# guys not get those features? Do we even need both these languages? These are interesting questions with no clear answers.

From a high level, Google's process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:

- there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.

- there aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.

- it's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

- there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.

- even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.

Read more on life at Google, and also "the Good and the Bad Agile", on Steve Yegge's blog over here.

This is pretty cool - be sure to check out some "episodes" (webisodes?) :-)

IE7 has been released - I wonder when those auto updates will be pushed out.

It's that time of the year again: Tech Ed Africa will be going down at Sun City next week! Lots of cool people, lots of sun, the odd one or two cold beers(!) and great technology: one of a few perfect ways to spend a week! My old talk-team-mate Armand and myself will host two Chalk-and-Talk sessions:

Test Driven Development Demystified
Monday 23rd, 2:45PM - Chalk & Talk Room B
Tuesday 24th, 9:15AM - Chalk & Talk Room B

Test Driven Development (TDD, a.k.a. Test-first design ) is one of the core programming practices of Agile / XP Development. An introduction to the concept, as well as practical implications are discussed. Attend this open discussion, and bring your thoughts, experience, and lessons learned.

Microsoft Robotics Studio
Monday 23rd, 4:15PM - Chalk & Talk Room B
Tuesday 24th, 1:00PM - Chalk & Talk Room B

The Microsoft Robotics Studio is a Windows-based environment for academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware. Key features and benefits of the Microsoft Robotics Studio environment include:

• End-to-End Robotics Development Platform
• Lightweight services-oriented runtime
• Scalable and extensible platform

In the South African market TDD is a mostly misunderstood concept - come see what it is and how it's done.

Microsoft announced that they will distribute IE7 in the "4th quarter of 2006" as a High Priority update via Auto Updates. There is an option to block this update, which will most likely be used by corporations until the impact of the update has been properly assessed. Most home users, however (and most businesses!) will not use the blocking feature and be updated almost without being fully aware thereof. According to some this update could occur before the end of October 2006.

This has a huge impact on providers of any type of online content: all content needs to be tested (and changed) for IE7, which significantly differs from IE6. ISP's can expect large amounts of support calls after the update has taken place.

Microsoft has taken the decision not to provide functionality that mimics IE6 rendering (when supplying an HTML tag for instance) - functionality that gives content providers the opportunity to get ready for IE7 in timeframes that make sense to them.

While Microsoft probably thinks that forcing IE7 to clients is a good move to counter competition from the likes of FireFox, I think that the opposite might be the truth: when a site doesn't render properly in IE7, many users might just make the switch to another browser to get functionality of online content.

A good way to stay updated would probably be via IEBlog.

Google is eying out and possibly buying YouTube for $1.6 billion.