What's on HDTV?

Could this be the definitive blog on HDTV? I haven't read it all yet, but it looks like it deserves to be read all the way through from the beginning.

VSTS Part 2

Well, carrying on with the course after the last rant, we come to a useful diagram that shows how the three editions and the "Foundation Server" fit together.

Visual Studio Team System

With eager anticipation of at last being able to do "proper" development without having to scrounge empty fag (that's "cigarette", for younger or non-English readers) packets off of my smoker friends, I hereby embark on a study of VSTS by studying the (currently) free Microsoft Visual Studio 2005 e-learning courses beginning with Clinic 2551: Introduction to Visual Studio Team System.


Well, we're not off to a good start. Here is the modern take on the software development lifecycle (SDLC) according to MS:

• Envisioning (output: scope document)


• Planning (approved plan)


• Development (tested code)


• Stabilizing (approved for release)


• Deploying (productive users)

The output from "deploying" is mine. The course merely says it marks the end of the cycle.

But the big worry for me is where is design? In a "normal" development team, the majority of developers are actually coders and anyway, the output from the development stage is "tested code"; no mention of architecture or design documentation. So design isn't part of the development stage. And we certainly can't expect it to come out of the planning stage.

VS2005 includes a "Team Architect" edition, so the activity hasn't been actually lost, but to exclude it from such a high level view, with no separate output, well, MS might as well come right out and formally declare it to be "deprecated".

Debug.Assert(this.WillNotHappenInProduction)

You couldn't wish for a simpler tool: just stuff a conditional test in your code to document what should be true at that point, and the debug build of your app will throw up a message if you (well, obviously not you; some other developer) got it wrong and didn't satisfy the precondition or screwed up some data somewhere.

But what should your code do if the assert is untrue in the release build? Well, you say, that shouldn't happen because your testing will have uncovered all the bugs that would lead to the assert failing. Hah!

In the best traditions of defensive programming, what you should really do is abort at least that operation by throwing an exception. But if you're going to do that, why bother with the assert in the first place?

The only justification I can think of that isn't pure "my code ain't got bugs" optimism (and if you're that kind of programmer you won't be bothering with asserts), is that you're sure that testing is going to exercise the dubious condition and you really can't afford the enormous time and space penalties of the if not condition then throw exception statement.

Don't get me wrong, I love Debug.Assert; it's a neat way of expressing pre- and post-conditions. But too often after writing one I get this nagging feeling that I haven't done enough to make my code "good". Perhaps what I need is a Release.Assert statement instead.