Over at the design-oriented Smashing Magazine site, you’ll find Brad Colbow’s comic, The Life and Times of Internet Explorer 6. It’s the browser we all love to hate, including we who collect a nice fortnightly deposit from Microsoft into our bank accounts. I got a great laugh at DemoCamp Toronto 21 when I said “If you got a cat when IE6 came out, it’s dead now.”
It wasn’t always this way, as the first section of the comic shows (you can click it to read the whole thing):
There’s a fair bit of history covered in the middle section of the comic, but I feel that the most important sections are the first (shown above), and the end, shown below:
That is the real question: “Can we stop supporting IE6 yet?”, followed by a real answer: You have to look at your audience. If you can drop IE6 support without ruining the experience for the majority your audience (you have to make the call on what constitutes a majority), then by all means, go for it.
Expecting people outside our industry to have as much interest in browser technology is about as fair as my insurance agent expecting me to have as much interest in the ins and outs of insurance as he does. I only care about the amount of coverage, the deductible, the slip of paper that goes into my glove compartment, and how much I have to pay a year. Everything else is just yappity-yap from some suit who’s interrupting my work day, trying to show me pages of boring legalese. That’s how we look to most end users.
Every Thursday in March and April, my co-worker John Bristowe and I will host the Ignite Your Coding webcast series. Each hour-long webcast will feature a guest speaker selected from the bright lights in software development. John and I will start off by asking them about their views on the industry and how to thrive in an era of great technological, business and social change, and then it’ll be your turn to ask the questions.
The theme of the webcast series is “staying on top of change”. I can’t deny hat there’s a certain thrill to the changes in this still-very-new industry (remember, the formal definition of “computable” isn’t even a hundred years old, and some of the pioneers, like C.A.R. Hoare, are still alive). They can also be overwhelming. All the guests on the show have ideas about how to cope with the ongoing changes, how to make the most of your career and life as a developer and intriguing stories about their life “in the trenches”.
John and I started getting interviewees for the show by drafting a list of “dream guests” and then inviting them to speak. John’s pretty well-established in the .NET world, so he went after people that Microsoft developers would know well. I’ve spent more time in the world outside Microsoft development, so I was assigned to invite people often seen in those spheres. We ended up with a great and varied set of guests, some you might have expected and some who might surprise you. We think that you’ll enjoy the webcast and find it both entertaining and informative, whether you eat, breathe and sleep Visual Studio, dream in TextMate or stand on the front lines in the Emacs/vi holy war.
All you have to do to catch the live Ignite Your Coding webcasts is register for the ones you want (see below). We’ll record them all, so if you can’t catch the live shows, you can at least listen to them later.
Andy Hunt has been behind some of the biggest ideas in everyday software development in the past decade. From co-authoring the Agile Manifesto and The Pragmatic Programmer to starting The Pragmatic Bookshelf, one of the most influential developer book publishers, to helping bring about the rise of MVC web frameworks, chances are that he’s had some influence on your day-to-day work. In this one-hour webcast, we’ll talk with Andy about the ideas in his latest book, Pragmatic Thinking and Learning. We’ll discuss why your brain is where software development really happens, how you can refactor your thinking and as he puts it, “just the plain old weirdness that is people”.
Glenn Block is an industry expert who has broad enterprise software development experience including architecture and system design. Typically, developers of client applications face a number of challenges. One of the more common challenges is to build applications in a way that allows its various parts & pieces to be interchanged quickly and seamlessly. In this conversation, Glenn Block will provide guidance on how to structure your applications in such a way that will facilitate this capability.
Jeremy Miller is no stranger to the developer community of .NET. He is the author of StructureMap and the forthcoming StoryTeller, as well as being a major contributor to FubuMVC and Fluent NHibernate. In this one-hour webcast, we’ll discuss a wide range of topics; including how newer OSS efforts in the developer community of .NET are trying to reduce friction, AAA-style mocking instead of record/replay mocking, the effective use extension methods for cleaner/readable/easier unit testing, jQuery magic, and much more!
David Laribee is currently an Agile Coach at VersionOne. Technical debt refers to the costs associated with byzantine dependencies and sloppy code. Technical debt is a drag. It can kill productivity, making maintenance annoying, difficult, or, in some cases, impossible. In this one-hour webcast, David will provide us with some advice for “paying back technical debt” with agile techniques.
Richard Campbell knows a thing or two about scalability and performance, having designed and built applications for over 30 years with a number of leading North American organizations. He’s also taken that knowledge and applied it at his company Strangeloop, which builds an appliance that specializes in website acceleration. In this webcast, Richard will help us navigate the world of scalability and performance and how developers need to think differently when building applications for the future.
Scott Hanselman is a household name to nearly every developer of .NET worldwide. From his deeply-informative blog to his engaging podcast, Scott is well known for his expertise and insights that he shares willingly with the broader community of .NET. In this webcast, we’ll talk to Scott about the state of the developer nation of .NET; a “what’s hot and what’s not” with developers of .NET today. We’ll also chat with Scott about his role at Microsoft and tips on staying on top of your game as a developer in the industry today.
Jeff Atwood writes the popular developer blog Coding Horror, created and helps run the Stack Overflow and Server Fault and SuperUser community Q&A sites and co-hosts the Stack Overflow podcast with Joel “Joel on Software” Spolsky. With a schedule like this and a one-year-old, he somehow stills finds the time to keep his Rock Band skills finely honed. Join us as we chat with Jeff in a one-hour webcast where we talk about the Stack Overflow phenomenon, how Coding Horror grew to become one of the most-read developer blogs and career strategies in the post-desktop age.
His business card may say “Robert C. Martin”, founder and CEO of the Object Mentor consulting firm, but we know and love him as “Uncle Bob”. He’s been coding since the Beatles broke up, and in that four-decade span, he literally wrote the books on agile and extreme programming as well as the letters UML, OOP and C++. Throughout the industry, he’s known as a champion of proper design, test-driven development and just plain writing good code. We’ll chat with Uncle Bob in this one-hour webcast, where we’ll talk about software craftsmanship, why it takes work and why it matters.
I met Peter “Mudge” Zatko at the Cult of the Dead Cow’s hotel bungalow at DefCon 8, the 2000 edition of the notorious hacker conference. My coworker at OpenCola, Oxblood Ruffin, was a member of the the “cDc” and introduced me and the other OpenColans to him and the other nicknames in the group: “Sir Dystic”, “Dildog”, “Deth Veggie”, “Night Stalker”, “Grandmaster Ratte” and many other black-clad, charmingly oddball characters far more interesting than the characters in the movie Hackers. I think I learned more about security in the hour-long group conversation with him than I’ve learned from countless corporate security training videos and training courses. Later at the conference, the cDc would hand out more copies of Back Orifice 2000, a tool that would cause much heartburn to many people at the company where I now work.
Mudge was responsible for the early research into buffer overflow attacks and published one of the first papers on the topic. In 1998, he and others from L0pht Heavy Industries (a.k.a. “The L0pht”, a hacker think tank) testified before a Senate committee, saying that they could take the internet down in 30 minutes. L0pht was acquired by the security company @stake in 1999, and in 2000, the company where I worked, OpenCola, hired them to do some security consulting. He’s met with President Clinton to talk about DOS attacks and worked at BBN as a division scientist.
I’m curious to see what Mudge can do with government gear and a big budget. In the cnet article, he talks about actively responding to threats. "I don’t want people to be putting out virus signatures after a virus has come out," he says. "I want an active defense. I want to be at the sharp pointy end of the stick."
If you’re looking for the latest and greatest version of Visual Studio, you’ll want to get your paws on the Release Candidate for Visual Studio and .NET Framework 4.0! It was made available to MSDN subscribers yesterday (if you’re an MSDN subscriber, you can download it immediately), and will be available to the general public tomorrow, Wednesday, February 10.
The changes in the Release Candidate (RC) are based on your feedback from the Beta 2 version and include improvements to:
General UI responsiveness (including painting, menus, remote desktop and VMs)
Editing (typing, scrolling, Intellisense)
Designers (particularly Silverlight and WPF)
Memory usage
Debugging (stepping, managed/native interop)
Build times
Solution/project load times
Here’s a Channel 9 video featuring Visual Studio General Manager Jason Zander talking about how the Visual Studio team addressed the feedback you gave for Beta 2:
The team has tested the RC on all the projects they could get their hands on, but not all the projects in existence. That’s why we’re making the RC build freely available to you so you can try it out on your projects! We want to hear from you, so please give the RC a try and let us know what you think via our survey site.
In the meantime, the Visual Studio team is working closely with vendors who’ve created popular Visual Studio add-ins, such as Resharper, CodeRush and so on to make sure that Visual Studio 2010 works with them.
Update: An Extra Note from Scott Guthrie
Our goal with releasing the public RC build today is to get a lot of eyes on the product helping to find and report the remaining bugs we need to fix. If you do find an issue, please submit a bug report via the Visual Studio Connect site and also please send me an email directly (scottgu@microsoft.com) with details about it. I can then route your email to someone to investigate and follow-up directly (which can help expedite the investigation).
Last week, I presented Kodu (pronounced “Code-ooh”) to a group of teachers and high school students at Corpus Christi Catholic Secondary School. Kodu is a system created by Microsoft Research for programming videogames without using a traditional programming language; instead, you use a combination of menus and visual programming. It was designed to be a gentle introduction to programming that would appeal to children, but many adults – myself included – have ended up getting drawn into it, spending hours constructing and tweaking game worlds.
Kodu’s a little tricky to describe – it’s one of those things that’s much easier to show rather than tell. Here are a couple of videos that should give you a bit of Kodu’s flavour. First, here’s IGN’s look at Kodu:
Kodu was designed to be programmed with the Xbox 360 gamepad, which you can use if you’re programming it on the Xbox 360 or a computer (if you’re using a computer, you’ll need either a wired Xbox gamepad plugged into one of its USB ports or a USB adapter for your wireless Xbox gamepad). If you’re using Kodu on a computer, you have the additional option of using the keyboard and mouse.
This is the first of a series of articles on Kodu programming that will appear here from time to time. If you’ve got kids (or know some) who are curious about programming, or if you’re looking to try a completely different kind of programming, get Kodu on your Xbox or PC and give it a try!
In this first installment, I’ll show you how you can build a simple little program that lets you drive an avatar around a small world. In later installments, I’ll show you more game-like elements and the “code” for a game of mine called “Stupid Sparkling Vampire Game”.
Touring Teran00bia
In addition to a programming “language”, Kodu provides you with tools for editing the worlds in which your games take place. I often start with a simple, no-fuss world that I created called “Teran00bia”. It’s a small, flat square world suitable for experimentation. If you have the Windows version of Kodu, you can download Teran00bia here. I can also share the Xbox 360 version, but you have to “friend” me on Xbox Live first – my gamertag is “Accordion Guy”.
Teran00bia is a blank slate, a world with nothing in it. Here’s what it looks like when you load it:
In this exercise, we want to stick a single character – Kodu – into the world and allow the player to drive him around using the controller’s left stick.
To start programming, get into Edit Mode. Press the “Back” button on the gamepad to switch to Edit Mode. Your screen should now look like this:
In Edit Mode, the left thumbstick moves your “cursor” (the purple “donut”) around the world, while the right thumbstick changes your camera angle. You use the left bumper (that’s the button just above the left trigger) to zoom out and the right bumper (the button above the right trigger) to zoom in. The screenshot below shows a zoomed-in view of Teran00bia:
The floating icons near the bottom of the screen make up Kodu’s menu. You use the left and right triggers to scroll through the menu and the A button to select a menu item.
Select the Object Tool from the menu. It’s the second menu item from the left, and its icon is Kodu, who looks sort of like a blue fish with an antenna. When you select the tool, the Kodu menu disappears and you’re now using the object tool, as shown below:
The Object Tool lets you add items to the world or edit any existing ones. There aren’t any items in the world at the moment, so let’s add one. Use the left thumbstick to move the cursor to the spot where you want to place an object, then press the A button. The following menu will appear:
This menu lists the items available to you. Starting at the top and going clockwise, the items in the menu are:
Kodu (the game system’s mascot, who can be used as either a player character or a non-player character)
Apple (useful as a health power-up, but nothing stops you from making them poisonous or explosive)
Bots 1 (a set of characters that can be used either as player characters or non-player characters)
Bots 2 (more characters that can be used either as players characters or non-player characters)
Objects (things that characters in the game can interact with, such as rocks, coins, castles and factories)
Tree (another object that characters in the game can interact with – I have no idea why trees weren’t part of the set of Objects)
Path (lets you draw paths which Kodu and the other bots can follow)
Use the left thumbstick to select Kodu from the menu, then press the A button to confirm the selection. A Kodu will appear:
You can move Kodu around by pressing the A button to select him, using the left thumbstick to pick a new location and then pressing the A button to drop him there.
What we want to do is program Kodu to move in response to the left thumbstick, as is the convention for most Xbox 360 games. While Kodu is selected, press the Y button. The screen should look like this:
Every programmable object in the Kodu game system has a set of behaviours, each one having two parts:
When, which describes the event that the object will respond to
Do, which describes what the object will do in response to the event
The behaviours are numbered starting at 1 and are listed in order of descending priority – that is, behaviour 1 has first priority, followed by behaviour 2, then behaviour 3, and so on.
Your programming “cursor” is the pencil. Move the pencil over the “+” in the “When” part of behaviour 1 and press the A button. You’ll see a menu pop up:
This menu lists the events to which Kodu can react. For now, we’re concerned with making him respond to the left thumbstick, which is part of the gamepad. Select “Gamepad” from the menu with the left thumbstick, then press the A button to confirm the selection. The menu will vanish and you’ll see that a “Gamepad” tile has been added to the “When” part of behaviour 1:
We need to specify which gamepad control Kodu should respond to. Make sure the pencil is over the “+” of the “When” part of behaviour 1, then press the A button. A menu containing various controls on the gamepad will appear:
Use the left thumbstick to select “L stick”, then press the A button. The menu will disappear and you’ll see that the “When” part of behaviour 1 has two tiles: “Gamepad” and “L Stick”:
We’ve just described an event that Kodu should respond to. Now it’s time to describe the response. Move the pencil over the “+” of the “Do” part of behaviour 1 and press the A button. A new menu will appear:
This menu lists responses to events. In this case, we want Kodu to move where the player tells him to move, which is specified by the left thumbstick. Select “Move” from the menu with the left thumbstick, then press A to confirm the selection. The menu will vanish, and you’ll see that a “Move” tile has been added to the “Do” part of behaviour 1:
We’ve now completely defined a single behaviour for Kodu: “When the player moves the left thumbstick, move in that direction”. It’s time to take our (admittedly simple) game for a spin.
Press the Back button to stop programming Kodu. You’ll now be in the Object Tool. Press the Back button again to return to Edit Mode, where Kodu’s main programming menu will become available. Use the left trigger to select Play Mode and press A to confirm the selection.
The program will start with the intro screen. Press A to dismiss the intro screen.
You’ll now be in the game world. Use the left thumbstick to move Kodu around:
Kodu moves, but he’s not so fast. Let’s look at a way to speed him up a little. Press the Back button to exit the program and return to Edit Mode. Use the triggers to select the Object Tool from the menu, then press the A button to confirm the selection.
Move the cursor under Kodu so that he’s selected:
Press the Y button to program Kodu. You’ll be return to his set of behaviours:
Move the pencil over the “+” of the “Do” part of behaviour 1, the press the A button. A menu will appear:
The menu will contain modifiers for the “Move” response. Select “Quickly” from the menu using the left thumbstick, then press the A button. The menu will disappear and you’ll see a “Quickly” tile has been added to the “Do” part of behaviour 1:
To make Kodu move even faster, you can add another “Quickly”:
…in fact, you can add up to three “Quickly” tiles to push Kodu to his maximum speed:
Play Around
I could cover more Kodu features, but you should use it the way it was meant to be used – experiment! Try adding other objects to the world and adding behaviours to them. Take a look at the programming behind the worlds that were provided with the Kodu game system (be sure to check out “Left 4 Kodu Classic”, a cute Kodu version of the zombie thriller game Left 4 Dead).
"I made the first important discovery of the 21st century: that JavaScript has good parts!"
The Software Crisis dominated the computer industry for a decade: 1960s
The crisis was that software projects were becoming too complex to manage
Projects were:
Over budget
Late
Unreliable
Not fully meeting their requirements
Unmaintainable
Failing
Insecure (this is a relatively new thing)
The software crisis isn’t over — we’re now in year 45
It never went away, we just stopped talking about it
"In other news, the sun will eventually exhaust its supply of hydrogen"
Craft vs. Engineering
Some people said that we weren’t bringing enough engineering discipline to the practice of programming
Some said programming isn’t the same thing as engineering and therefore engineering discipline doesn’t apply
Both miss the point
The real problem with software is that it’s the most complex thing we make
It requires perfection, which humans aren’t good at
It’s amazing we can make software at all
Software construction
Computer science has taught us lots of things, but not how to manage software projects
In some ways, building software is like any other sort of construction
But in some other ways, it’s quite different
You have to keep in mind that "construction" when applied to software is just a poetic metaphor
Take the case of building a wall:
It’s easy to estimate, based on the size of the wall how much time it will take, and also how far progress will be at any given time during its construction.
Try doing that with software!
Part of the problem is the nature of software
It’s both powerful and malleable
The qualities are both a blessing and a curse
One problem: The lack of metrics
There’s no objective measure of quality or completeness
We can test software, but the tests are on the same level of quality as the software being tested
Consider one of the old stand-by metrics: LOC (lines of code)
It’s not an indicator of quality
Nor is it an indicator of completeness
Another problem: Estimation is difficult
Programmers, by nature, are optimists
You have to be and optimist to do this kind of work! You wouldn’t be able if you weren’t
"I think rational people could not do programming"
As a result, we’re probably the least qualified people to do estimating
What doesn’t help is encouragement from management like "You’re a smart guy, you should be able to do it in 3 months!"
Another problem: Programmers don’t understand how they spend their time
They think they spend most of their time typing
Measurements show that most of their time is actually spent in meetings or tech conversations
(And there’s also the time spent staring at the screen going "My God, what have I done?")
As a result of this disconnect between perception and reality, programmers tend to be skeptical of process improvements that might require more keystrokes
[Story about developer who refuse to switch from a CamelCase naming scheme to a words_delimited_with_underscores naming scheme]
The programmer had an emotional attachment to the CamelCase naming scheme and argued that the underscore-based scheme slowed things down
Consider the first rule of optimization: optimize the process that is taking the most time
When it comes to programming, that process isn’t the typing!
It’s the thinking, worrying and puzzling
Programming is a social activity
Solo cases are the exception
Cost of innovation
Doing what’s been done before vs. doing what hasn’t
We’re constantly doing things we haven’t done before
That’s most likely to lead us to mistakes
Legacy
In other industries, legacy is seen as the wealth of practice and tradition, the wisdom of experience
Not ours! In software, past accomplishments are considered to be a liability
The age at which programs become "legacy" is getting younger and younger
Some programs become legacy before they’re finished\
No industry disrespects legacy the way the software industry has
It’s the best movie ever made about project management
Blandings’ problems:
Lack of knowledge of technology
Poor control over requirements
[Joey’s note: This movie’s been remade in modernized form with Tom Hanks in The Money Pit(1986) and Ice Cube in Are We Done Yet? (2007).]
Feature Cost
Development time
Deployment cost
Maintenance cost (bloat, cruft)
Download time
User confusion/training
Bug delivery
Code Value
Microview: good coding conventions
Macroview: good architecture
We need better program architecture
Architecture is hard, but conventions is easy
Think of how hospitals were improved just through simple conventions of hygiene, such as washing your hands
The simplest thing we can do to increase the value of our code is to make it readable
For example, when returning a value from a method, we should use return value, not return(value) — the latter implies that return is a function
Whatever improves human parsing of programs is helpful
Communicating
You should think of programs as a medium of intentional communication:
Communicating detailed instructions with the machine
Communicating with your development community
Communicating with yourself (and especially your future self)
Good architecture is about not collapsing into a puddle of confusion, and should enable you to change a correct program into another correct program
Cruft
It’s software scar tissue
Comes from lots of sources:
Premature optimization
Inexperience
Misread source
Feature enhancement
Death marches (which are the most avoidable source of cruft)
As cruft accumulates, complexity grows and progress slows
Eventually, the code itself becomes a source of friction
Bloat
It’s "software obesity"
In the old days, memory was expensive and you didn’t get much of it, so your programs were lean by necessity
Having only 8K – 64K of RAM in a machine put incredible constraints on what you could do
I used to dream of the day when memory would cheap and abundant enough so that we wouldn’t have to do evil things to get programs to fit
Now I wonder if maybe those constraints weren’t so bad
"Bugs hide in those rolls of fat in our programs"
Insecurity
Most programs these days have marginal security
Programs that once didn’t have security implications now do
Any bug is potentially a security bug
Good secure programming is good programming
Thinking about security might make programming easier
Refactoring
The process of code refinement, involving things like:
Correction of formatting
Insertion of documentation
Removal of cruft and bloat
Restructuring
Perhaps we should take advice from Exodus: "Plant and harvest crops for six years, but let the land rest and lie fallow during the seventh year."
Maybe do six sprints where you add new features, but on the seventh sprint, don’t add new features at all
Sometimes the best course is to start over
This is quite difficult to accept
The pain of the crash
Loss of a week’s work, a day’s work, an hour’s work, is unbearable
The illusion of completion
"It’s in the can!"
I once worked as an expert witness on conflict between 2 game companies
The original game company had split up; the new company was being sued for plagiarizing the original company’s game engine
I reviewed both game engines and determined that the new game company had written a whole new engine in 2 month — they’d learned for the experiences writing an engine for the old company
The owner of the old company couldn’t accept that; he thought the value of the codebase was 100 man-years, not 1
An experienced team can redo what they just created quickly. The team’s focus must be on simplicity to avoid second system effect
Have regular code readings
Don’t wait until release to do code reviews
Do team code reading regularly during development
Problems can be discovered early
Good techniques can be shared early
Experienced developers can lead by example; novice developers learn from the group
They should be: frequent, helpful and respectful
You need a healthy team – a dysfunctional one will tear itself apart
Conclusion
Quality first. Quality last.
Readable code. Code reading.
Invest in the quality of your code base.
Invest in your programmers and managers.
Quality is the most important feature.
If you look at all the polished, completed code you write at the end of a year, you could type it all in a day
Typing is not what we do; it’s thinking and communicating
You young’uns may have learned about typefaces and the difference between serif and sans serif from using the “font” settings on your computers, but I learned from using Letraset (and often, its budget-priced brother, Geotype). They were sheets of rub-down transfer lettering and clip art. The principle behind Letraset wasn’t all that different from temporary tattoos. The stuff went the way of the dodo once desktop publishing and laser, inkjet and dye sublimation printers caught on.
I met 
