I'm glad you asked.

You don't got to be a Hanselman to know all this.

Here's a pictographicatorial guide to compatibility checking in the windows 7.

* In point of fact, it's a virtual Raymond Chen (a VRC), but the MS guys are so freakin good at virtualization now that You Will Never Ever Ever EVER Be Able To Detect The Difference. Even Mrs Chen is rarely sure. And only when that fails do they invoke the real Ray Chen.

So take it from me, a world expert on the computing technologies, that this new version of windows will be just about the best thing since Vista.

sorry i redacted it slightly; i think the guilty deserve some protection too; they're just hard working kids in the end)

3 Questions... in cartoon form too!

I really love this timeless Tom Van Vleck article from 1989.

It teaches us to ask ourselves:

Three Questions About Each Bug You Find

Those questions being:

1. Is this mistake somewhere else also?
2. What next bug is hidden behind this one?
3. What should I do to prevent bugs like this?

When I first read these rules, I was foolish enough to think:

'Cute, But Too Obvious! i do this intuitively all the time.'

But watch yourself closely! I've caught myself out on occasion, and maybe you will too.

I'm making an effort to be more explicit about the three questions. Maybe i'll end up fixing related problems at first hint more often than i do now.

Vilfredo Pareto: don't got time to shave.

I keep hearing rather a bit too much about this Pareto Principle.

Apparently, with just 20% effort, correctly applied, I can achieve 80% of the desired effect. Marvellous stuff!

I was about to go ahead and do this when it occurred to me:

"Why waste all that time, doing a whole 20%?

"If I only did 20% of that 20%, then surely I could achieve 80% of the 80%?"

Then with a little more head scratching, and the help of an excel spreadsheet, I determined that with just 0.8% of the effort I could achieve 51.2% of the result -- which is a PASS in anyone's books.

So from now on, you will excuse me while I spend 99.2% of my time:

1. Lounging around, drunk, in a pool bar and

2. Determining exactly which 0.8% of the effort to apply myself to.

Unless, of course, it takes 80% of the effort to work out exactly which 20% will achieve the desired effect. And it takes...

A couple of weeks ago I put out a twitter post I've been meaning to come back and explain:

"the habits of a good programmer are not simply orthogonal to good communication -- frequently they're in direct opposition."

http://twitter.com/secretGeek/status/1870937085

This is a pretty startling and upsetting result: I'd like to think that the heart of good programming is crisp and direct communication. That all of my efforts to be better at programming will, somehow, make me a better all-round person. If only it were true.

Here's a bunch of ways that good programming practices are directly opposed to good communication practices.

In bullet form:

1. D.R.Y. Does Not Apply.
2. Humans don't mean what they say.
3. Compilers don't need to see an example.
4. Programs love definitions; Humans get flummoxed.

And in detail:

1. D.R.Y. Does Not Apply

The golden rule of programming is D.R.Y. -- don't repeat yourself. This is the heart of effective programming. But this is the opposite of effective communication.

Let me say that again:

The golden rule of programming, DRY, is the opposite of effective communication. ;-)

Say everything once and only once -- go ahead -- then be amazed as everyone misses your point!

Humans are not machines. Memories made of this gooey, spongy stuff called a brain are nothing like memories made of silicon.

With Humans, nothing sinks in the first time. And furthermore, you may be surprised to hear that NOTHING sinks in the first time.

"Human, All Too Human" Nietzsche preferred the company of a good compiler over that of a human. "Compilers never make fun of one's moustache," --Ibid., pg 293.

2. Humans don't mean what they say.

Compilers are of course perfectly literal. They don't care at all what you mean, they are always hung up on precisely what you say.

Even if you didn't start off life as an anal-retentive git, you'll slowly gain the requisite faculties over years of trying to please a compiler.

The art of trying to please a compiler consists of the ability to logically, dispassionately, analyse what you've said, to discover and remove any mistake or ambiguity -- to always produce an output that is perfectly comprehensible to the strictest of master.

Try being like that around real people. Just try it.

People are barely literal at all. If you take them literally when their meaning differs from their words -- they will get quite irate with you. They won't see that the mistake is theirs.

When the words they use differ from their intent, you may feel an overwhelming desire to 'correct' their mistake. You may even think you are doing them a favour.

This is a natural feeling, amongst programmers, who would be happily spared the torture of spending time trying to remove all ambiguity from the words they provide to a parser.

But please (please) hold back. You might score a small point in the 'intelligence' column for pointing out their 'mistake'. But you'll also score about a bajillion points in the 'what a freaking dork' column.

3. Programs don't need to see an example.

Explain a function to a compiler, and it will be able to calculate the answer.

Explain a function to a human... and then give them an example, and draw them a picture, and give two counter examples, and draw another picture, plus provide an interpretive dance on the topic of functions -- and maybe, just maybe, if you've danced very nicely, they will begin to see "what you're trying to say."

"What I'm trying to say?" I'm saying it damn clear! I'm saying it directly, concisely and with perfectly constructed phrases! I'm not trying to say anything! I'm succeeding, you're just not listening, you freaking imbecile!

And don't take that tone with me. With humans I mean. There's no point yelling. Their rational mind shuts down, their sympathetic nervous system takes over. They get ready to fight or flee. Your point is lost when you get them angry.

Computers don't mind if you type angry. Humans think the anger is more important than the words themselves.

When you have the customer in a headlock, knocking their face against the ground with every syllable: the syllables themselves are no longer of tremendous consequence.

True: that bit about beating up the customer may not be a typical trait amongst great programmers. Perhaps I included it just for entertainment purposes. Continuing...

4. Programs love definitions; Humans get flummoxed.

In programming we define new terms all day long. We define class names or function names or variable names.

We immediately attach a specific definition to them -- and then we use that definition throughout our code.

I imagine that some part of the brain is associated with the ability to define a new term and then hold onto its definition. That part of the brain would be monstrous in programmers. Very over-developed. Gigantic -- a tiger amongst kittens.

But define a new term in front of an audience of non-programmers: watch as the eyes glaze over. Heads slump forward. They start planning their weekend.

Let's call this our Neologismic Synaptic Aptitude, or NSA. Actually: let's not call it our NSA, because if we do, then programmers will start bandying the terminology around like it's something we've known about all their life. And the normal people will just look at us with that 'freak' expression, and we'll be even further from ever making it into the boardroom.

I think this aptitude for new terms is what makes TLA's so abundant in the IT world. I do hope you realise it scares everyone else.

So please, I implore you...

Stop defining new terms. Stop expecting non-programmers to understand the specific and concrete definitions you attach to funny little abbreviations.

Stop striving for brevity and conciseness.

Stop correcting other people.

Stop expecting people to understand you first time around.

Start giving examples -- real examples, earthy examples.

Let people be people -- let them be vague and a little incorrect -- listen more for the gist of what they're saying than the exact terminology.

Be a compassionate speaker, a compassionate listener. Embrace the 'all too human' aspects of the strange bipeds you interact with.

Then drop me an email and please, for the love of god, tell me how you managed it.

"The amount of physical memory in your system has increased. This typically does NOT indicate a hardware failure. Contact your Help Desk if you did not personally change your system's physical memory configuration."

Why didn't they say "Congratulations!" or "Good news" or "Ahhhh! thanks for feeding me those yummy ram chips!" or best of all:

"Well, how about that! The tight bastards in IT must've approved that RAM upgrade request we noticed you writing in MS-Word, all those months ago.

"Now let's see if we can get the cowards to consider upgrading the browser to IE 7."

These are the 'ghost bloggers'.

'Ghost-blogging' is the practice of sharing true stories about your own working life, true stories too cutting, too poignant and too true to share on your own blog.

The following is an example of a ghost blog entry, sent to me by someone I know, appalled at some of the Kafkaesque behaviour they've been subjected to inside the kind of enterprise everyone should find familiar.

(I've ghost-blogged my own personal stories on other blogs, at times...)

Here goes...

Version Control, Requirements Tracking and Deployments

In the enterprise, nothing is what it seems

In the enterprise when they say: "don't worry about that, another team will do that for us" what they mean is: "you just took on a dependency that you have no control over".

In the enterprise when they say "we want you to re-use this standard asset" what they mean is "we want you to hold on to this gold-plated, diamond encrusted anchor while we throw you over the side".

In the enterprise, the group allegedly responsible for 'provisioning developer desktops' will, in actual fact, be the group who expends every effort imaginable to stop developers from being able to actually install developer tools onto their desktops.

In the enterprise when there are three separate groups, allegedly responsible for version control, requirements tracking and deployments, you'll find in practice the requirements are documented through excel spreadsheets over email, the source code won't build, and the deployments take everyone by surprise, including the deployment team.

In the enterprise when they talk about 'strategic direction', they mean 'strategy tax'.

In the enterprise when they ask you to "simply call a web service", what they mean is, "use ftp to push a fixed-width file onto a queue that feeds the mainframe which routes another file to a web service that calls you back on a random port". With a completely straight face.

"I too am cool! I too have an iphone!"

1. Go to the settings area of the mail client you use on your regular PC



2. Change your email signature to read 'Sent from my iPhone'



3. Send short, pointless emails to everyone you know

Okay, you won't technically have an iPhone. But for the most part, other iPhone users will *want* to believe that you have joined their "team" -- hence, they will be convinced.

And -- as a final twist -- once you're thought to be a member of their team, you'll find that acquiring an actual free iPhone will be easy. Other iPhone owners will be more than happy to let you borrow one of their iPhones next time you see them, if you claim to have momentarily misplaced yours, for example in the pocket of "your other white leather trousers".

--lb
Sent from my iPhone

Well, It turns out that the 80's geek classic, 'War Games' has inspired a sequel, the film

'War Games: the dead code' was released in 2008. Though, perhaps the correct term is 'foisted.'

WG: TDC is such a deliberately bad film that you can only begin to enjoy it once you grok that it's a comedic satire.

For the first hour and a half I assumed it was trying to be a cool, teenage-targetted tech-savvy thriller, like the original. This had me wincing in agony at every bad line and predictable twist. Only then did I realize it was all a joke: a parody of the teenage-targetted tech-savvy thriller. A kind of 'scary-movie' style satire of the entire genre. Hopefully?

Well, I've just finished watching it and it's inspired me to share a few helpful tips for up and coming programmers.

As one of today's young parents, I can tell you what concerns us. Not swine flu, or global economic disasters and so forth. What really keeps us terrified at night is a desperate hope that we, as parents, take all of the right steps to ensure that our sons and daughters grow up to be thoughtful, well-meaning, much loved people. In short: How Can We Be Certain Our Children Will Become Programmers.

And a lot of hard work (err, blog posts) have gone into that endeavour, but as usual I like to look beyond the obvious problem, and into the deeper realms or possibility:

If you're child does (thank god!) grow up to be a Programmer -- what simple lessons can you provide to ensure they don't inadvertently destroy the planet?

Programming is a powerful profession, and as you well know, global apocalypse is but a keystroke away. We want to give our kids the right tips to ward off such misadventures -- to learn from our wisdom, as it were.

Fortunately, like all global catastrophes, this one can be averted with another 3 minute guide from secretGeek.

Please, sit back, breath a deep sigh of relief for the salvation of your measly planet, and drink deep of this crucial lesson to imprint upon your younglings:

10 Simple Rules To Follow Incase Your Software Becomes Self-Aware

(I have included links to information about Government-Approved documentary films on each of these points. I only pray you heed my warnings and enforce these lessons before we are all routinely destroyed.)

1. Teach your software that war is futile.

   If, after pre-supposing a minimal competency level in your opponent, a game's inevitable state upon termination is mutually-assured destruction, then the only winning move is not to play.

   [reference]

2. Prepare a virus that can be used to remotely shut down the program from any terminal in the world.

   My personal contiuous integration suite won't let me commit any code until I can demonstrate 100% code-coverage with remote-shutdown killer viruses.

   [reference]


3. Don't discuss switching off the computer if you are, in fact, being observed by the computer.

   This is s.o.p. (...that's standard operating practice, if you're not a super-spy type like me, who knows all the jargon). Never discuss shutting down your software until you have found a locked, sound-proof chamber, where the computer system cannot hear your discussion. Also, in case there is a remote possibility that your software has learnt to read lips, let me suggest you cover your mouth.

   Simple, every day precautions.

   [side note: a parody of this famous Kubrick scene was included in 'the dead code'. nice.]

   [reference]


4. Ensure that when faced with a tricky question, your software will either breakdown completely, or devote all of its resources for a long time.

Grandiose, open-ended philosophical questions tend to have a compute time in the order of millions of years.

Similarly, when given a dilemma (e.g. "This sentence contains a lie") a self-aware program will tend to explode spectacularly. A competent programmer will keep a few of these handy.

[reference 1]

[reference 2]


5. In case of emergency, have time machine handy.

   You may need to send someone back in time to protect the mother of the person who leads the rebellion against the self-aware software in the future.

[reference]


6. Don't make your self-aware machine indistinguishable from a human.
   

   Maybe you're not very creative, and don't have the time to give your machine a stunningly inventive new exterior. So you fall into the tired old pattern of mimicking the human body.

   That way, badness lies.

   [reference]


7. Should your software become self-aware, don't let it near your girl.

   Fairly self-evident that one.

   [reference 1]

   [reference 2]


8. If applying temporary appendages to a self-aware robot, be considerate of your legislation governing public safety.

   Scissors for example, are not recommended, even if they are 'just for now'.

   [reference]


9. Be safety conscious.

   Switch off all electrical equipment during thunder storms.

   [reference]


10. Use a rules engine.

    Hardwire 3 clear and unambiguous rules into the program's positronic brain that will ensure all humans are safe from harm.

    [reference]

Hopefully, if you follow my advice, we can avoid any more major disasters. But please: always be nice to your inventions. Hopefully then, should the unthinkable happen, your self-aware creations will take pity on us and keep us barely alive in liquid chambers so they can gorge on our brains.[reference]

Oh, and if you don't believe in self-aware robots... (cough cough) here's some i prepared earlier.

See also (important information in similar vein)

• server in the movies
• The Grand List of Overused Science Fiction Cliches
• Some thoughts on the coming Robot Apocalypse
• Pure Evil: The 12 most evil robots of all time and how to thwart them

Example: two toolbar buttons titled 'Lower' and 'Upper'.

Right click the toolbar to edit a button (or add a new one)

The button hosts a python macro that does whatever you want. (The current document's main textbox is exposed as txt.)

Add more buttons, edit the menus... everything's extenisble... everything.

I've open-sourced a side project of mine, MetaNote.

Here's the gist of it...

MetaNote is a text editor. Ultimately, MetaNote intends to be the most versatile editor imaginable.

See that button in the toolbar? Right click on it, and edit the code behind it.

Don't like the way 'Find' works? -- right click on it, and edit the code.

Need a new button in the toolbar? So add it already, with a single click.

Share packs of extensions and macros with other users.

Everything in MetaNote is under your control, effortlessly, at runtime.

It's easier to show than to describe -- maybe the pictures on the right give you the idea.

The source code is available to browse or download. This is very much pre-alpha. It is explorative and non-commercial.

binaries are also available to download.

The project is written in C#, and I need your help getting it done.

I've got many of the basics done, but I'm only at the tip of what's needed.

I'm looking for clever kids like you, willing to help out.

What do you think? Can you take a look at the code, and lend your fellow programmer a few minutes of your time?

I'm not doing it for any commercial gain, i just want a text editor that I can bend to the whims of whatever writing task I come across.

There's a great many features still in need of implementing, and already there are wrong turns to be corrected.

Down the track I really want to find some way to embed the WPF-based Text Editor Control from VS2010. It's the same one used in intellipad (part of Oslo) and in Powershell 2.0's (awesome) Integrated Scripting Environment -- I didn't have any success bringing it to life just yet. So, for now the text is plain text, and features like syntax highlighting and intellisense will have to wait.

One of my mentors tells me the smart approach would be to bring in MEF for giving a really powerful plugin model, where plugins can have plugins and so on.

The intermediate goal though, is just to make the tool sweet enough that I'd use it for my own day to day text editing needs.

And one day, hopefully one day soon, this thing won't suck at all.

Couple of days ago I wrote a C# function for a colleague and emailed it to him.

This is the function:

private static string EscapeCsv(string value)
{
  //Double all quote characters
  value = value.Replace("\"", "\"\"");

  //If it contains a comma or a quote char -- qualify it with quotes.
  if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
  {
    value = "\"" + value + "\"";
  }

  return value;
}



The syntax highlighting looks very strange, because I wrote it in sql server management studio. It just happened that the only text editor i had open at the time was SQL server, so that's what i used.

(Real developers don't use any particular editor - they just use whatever's open at the time. Even the act of opening notepad is too cumbersome for the ubergeek.)

After I emailed it to my colleague I had a moment of weakness, when I suffered the tiniest smidgen of self doubt.

"Perhaps I should've tested the code in some way. Or -- at least -- compiled it?"

Scott Bellware and the cool alt.net kids are always banging on about this sort of stuff, so I wrote an awesome console app to test it.

namespace tests_are_for_wusses
{
  class Program
  {
    static void Main(string[] args)
    {
      System.Console.WriteLine(EscapeCsv("fred") == "fred");
      System.Console.WriteLine(EscapeCsv("fre,d") == "\"fre,d\"");
      System.Console.WriteLine(EscapeCsv("fre\"d") == "\"fre\"\"d\"");
      System.Console.ReadLine();
    }

    private static string EscapeCsv(string value)
    {
      //Double all quote characters
      value = value.Replace("\"", "\"\"");

      //If it contains a comma or a quote char -- qualify it with quotes.
      if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
      {
        value = "\"" + value + "\"";
      }
      return value;
    }
  }
}


Naturally, the awesome code passed my awesome tests first go.

Thus I have once again shown that testing is a waste of time if you are awesome like me.

And the so-called cool kids from alt.net are just bad programmers.

Thank you.

Wait a second... I still feel I'm missing the point. Care to enlighten me?

(By the way -- pretty much every sentence in this post was sarcastic... while the story is true, my real interpretation is that i just got lucky this time. There's definitely some bugs still hidden even in a simple function like this)

I guess I'm Doing It Wrong :-(. Here's all the places where I distribute my todo list...

• In my current moleskine (pronounce it with me -- Moh-leh-skeen-ah) on pages 9, 12, 31, 57 etc.
• in my phone
• in outlook (at work)
• in my code using //TODO: tags (scattered over numerous projects)
• in my code using NotImplementedExceptions.
• in timesnapper's hosted fogbugz account
• in 'nextaction' on my work pc
• in 'nextaction' on my home pc
• in 'nextaction' on my laptop
• in my gmail account (emails labelled 'todo')
• in my gmail account (emails marked with a star)
• in my gmail account (any emails from me)
• in my other moleskine, beside the bed

Still, I think i'm pretty good because I do actually tend to 'get things done'. But also because i resist keeping lists in all these other places:

• in iGoogle
• in sharepoint (at work)
• in my gmail account (using the Gmail Tasks plugin)
• on pieces of paper on my cubicle wall
• in my other notebooks
• in timesnapper using flags/tasks/notes
• in yet another todo.txt file
• on sticky notes randomly decorating places I inhabit
• in twitter
• in tada list
• in that surprisingly popular codeproject todo list
• in remember the milk
• in a tiddly wiki
• in the iphone i don't have
• in the PDA i don't have
• in chandler
• at trimpath 'next action' web site
• on my blog
• using tattoos (memento style)
• in google calendar

There's no shortage of places to keep your things to do.

I don't worry about having too many systems. A bigger fear is failing to capture a problem as it arises.

You frequently get just one chance to capture an idea, so I capture it anywhere I can.

Abstractions should be as high-level as possible, and no higher. #

Einstein of course said,

"Make everything as simple as possible, but no simpler."

... and that's a kind of programming mantra, as so often in our race to simplify we end up over-simplifying. (The famous 'Worse Is Better' philosophy could be phrased as an argument that sometimes you should actually sacrifice correctness for the sake of the simplicity -- i.e. 'Einstein was wrong.')

In a similar vein, I think there there is such a thing as 'too abstract'. And it is a terrible thing.

Pre-emptive Abstraction is at least as bad as Premature Optimization #

• If your class name contains the word "Abstract" -- you're doing it wrong.
• If ClassName.Contains("FactoryFactory") -- you're doing it wrong.
• If Your ClassName Ends With "BaseBase" -- you're doing it wrong.
• If ClassName.Contains("Factory") && ClassName.Contains("Provider") -- you're doing it wrong.

Economists re-evaluate bird in hand as 1.9 times bird in bush. #

A more appropriate tweet might've been:

'Economists write down bird in bush to 0.45 times bird in hand.'

Or:

'Government provides 8 trillion birds-in-hand to replace 16 trillion birds lost in bush.'

Someone (I think that cockroach poet Archy) once called humanity something like "a strange species of bipeds who cannot run fast enough to collect the money which they owe themselves."

i am *not* homophobic. Infact, some of my best friends have iPhones. #

And I'm still waiting to see them make the millions of dollars from iPhone apps that they promised themselves last year.

If a job's not worth doing, it's not worth doing properly #

The original statement: "If a job's worth doing, it's worth doing properly" has the corollary that any job that is not worth doing properly is therefore not worth doing at all.

This is patently absurb and a kind of shining example of why perfectionism doesn't pay.

The slightly twisted variation:

If a job's not worth doing, it's not worth doing properly

...may seem defeatist and sloppy -- but i think it's the very soul of true productivity.

That's what no one seems to appreciate about being rich: the first 100 bazillion is the hardest. #

After that, you can just sit back and live off the interest of the interest.

And your next code editor is... a browser. #

I still think it's true -- and once i get a bunch of other things out of my todo pile -- i'm going to make it happen. Maybe.

Meanwhile I'm working on TimeSnapper v.Next, and tinkering on something tentatively called MetaNote -- about which you'll be hearing more.

When you're looking at a query window that's connected to Production, it would be nice if it was visually distinct from a non-production environment.

For example, there could be a red theme applied to the window.

Furthermore, there could be a warning before a potentially destructive query is executed. (Essentially, any query that isn't just a select - for example, a drop, delete, update, insert, create or alter)

This would be an effective way to lower the chance of something being done to production that was intended for another environment (pre-prod say, or development)

I can imagine a straw-man counter-argument to this concept that says:

"The only people who should have access to production are people who know what they're doing"

Or alternatively,

"Developers shouldn't have access to production"

And that's fine by me.

We can limit who accesses production, and we can give minimum privileges to those that do have access.

But even then:

*Someone* will have destructive privileges in production.

And that person will definitely have access to more than one system.

And that person, no matter how smart or conscientious they are, will be fallible.

Hence, it's helpful for that person to be able to differentiate (visually) between the different environments.

Why am I writing this blog entry right now?

Don't worry. I stopped myself in time ;-)

(And like all blog posts everywhere, there is already a stackoverflow question that says the same thing and a whole lot more)

• A button with no click handler.
• A click handler with no code.
• A parameter that is not used.
• Code that throws A 'NotImplementedException'
• A //TODO: token.
• An #if DEBUG
• A phrase that contains more than one dot, e.g. Control.Parent.Parent.Parent.Controls[3].Controls["Accept"]

Q: Why do I want the compiler to be so mean?

A: It takes a tough man to make a tender chicken.

(attributed to Purdue, quoted in 'Worse Is Better')

No, the common thread here is these are pitfalls common to a top-down, (or an outside-in) design approach.

As you move top-down, (or from front to back), you throw off "branches" -- kind of last strands -- that you need to back-track to complete later. I want the compiler to help me find those branches. (Tests are a poor substitute)

In his 2005 classic 'Does Visual Studio Rot the Mind?' Charles Petzold showed how intellisense-and-friends encourage bottom-up programming.

These are some little features that could help out the die hard top-down coders.

Details...

"A button with no click handler"

Why does a button exist? Is it just to look good?

No! Buttons are for clicking!

A button with no click handler is a fail.

And a click handler with no code is a fail as well.

What does the user expect when you click a button?

Unless this is that Early Internet Phenomenom known as The Really Big Button That Doesn't Do Anything, a user expects *something* from a button.

Why would you check that in? What good can possible come from letting do-nothing buttons end up in the hands of unsuspecting users?

The world of static code analysis has gone very far - but does it stop and help us avoid this sort of psychological torture?

(This same concept may be true for many other objects that raise events. The object's author might be able to indicate "There's really no point using this thing unless you handle the following event(s).")

A parameter that is not used.

Unused variables raise a warning, but unused parameters don't.

This is a little bit good, but it's a little bit bad as well.

Here's an example where the unused parameter is clearly a bug:

    private void CopyFile(string sourcefileName,
                        string targetFileName,
                        bool overwrite)
    {
        System.IO.File.Copy(sourcefileName, targetFileName);
    }

Oops!

The programmer forgot all about the 'overwrite' parameter!

I consider that a pretty clear error.

But consider our click handler for a moment:

    private void Button1_Click(object sender, EventArgs e)
    {
        MessageBox.Show("Hello");
    }

Neither parameter is used. But if we were to call this an error, a hell of a lot of code that's shipping today would fail.

Some design changes could alleviate the dilemma - I'll leave the consideration of possible solutions as an exercise for the interested reader. The goal is to avoid busy work, not create it.

Code that throws A 'NotImplementedException', and //TODO: token, #if DEBUG conditions and everyone from System.Diagnostics.Debug

Not Implemented Exceptions are excellent stuff.

But your goal is always to eradicate them, right? They're a kind of hardcoded place holder. A warning ought to suffice. (You treat warnings as errors, most of the time, right?)

I put //TODO: tokens and #if DEBUG conditions in the same category. They're very handy scaffolding or place holders as you crank out your code -- but they're not supposed to remain indefinitely. A warning would be nice. Maybe Debug.WriteLine and its friends should fall into the same category.

A phrase that contains more than one dot, e.g. Control.Parent.Parent.Parent.Controls[3].Controls["Accept"]

Why would a compiler let you get away with this kind of monstrosity?

It would be quicker to just replace that whole line with "throw new NullReferenceException()". The effect would be the same.

My point here is that this kind of implementation of the house of cards anti-pattern is easy for static analysis tools to pick up.

I know that there are existing static analysis and code grepping tools that can be used for some of these cases, but they tend to run 'after the fact', outside the tight code-compile loop. Worse: they tend to produce a lot of noise and take a lot of care and feeding.

StyleCop is the worst 'busy work' generator I've seen. (If only they'd finished the job and had it auto-correct many of the problems it finds... instead, like '100% code coverage' it's a kind of training tool for Coder's OCD.)

Alrighty -- that's all I've got for now, though if I keep my eyes open, I bet I'll spot some more.

I've often wondered what people really mean when they said 'Architect' while talking about software.

None of the literal meanings seem to capture the way the word itself is applied in this context. But I think I've hit the thing on the noggin at last.

A 'swear word' is a word whose literal meaning differs wildly from its contextual intent -- and whose intent can be bent to suit a great many contexts.

Take 'F---', for example. The word has a literal meaning, something like 'To copulate vigorously' -- but in actual use, the intent is generally bent to suit the context.

For example, when I hit my thumb with a hammer I say "F---!" and in that context the meaning is: "It hurts a lot when I hit my thumb with a hammer."

Or, when I get a flat tyre I say "F---!" and it means, "This flat tyre is an unexpected interruption to my day that will cause undue expense and wasteful exertion." The quickest way to say all that is simply "F---!".

Now imagine there is a guy in your organisation whose coding skills are terribly out of date, but who is not capable of performing any managerial duties.

If someone asks you, "Who is that guy?" then you probably won't waste your breath by saying, "Him? A guy whose coding skills are terribly out of date, but who is not capable of performing any managerial duties." Instead you'll permit yourself to emit a nasty little swear word and simply say, "Him? Architect." Ouch!

Now, just say you work with an impractical fool with an over-inflated sense of self-importance who destroys whatever thing he touches, never ceasing to bring layers of accidental complexity to even the simplest of contrivances, but who is, thankfully, kept out of harm's way by being assigned the task of writing grandiose-titled corporate documents that no one is ever expected to read. When someone asks you who that guy is, you draw your breath in deep, and prepare to say:

"Him? An impractical fool with an over-inflated sense of self-importance who destroys whatever thing he touches, never ceasing to bring layers of accidental complexity to even the simplest of contrivances, but who is, thankfully, kept out of harm's way by being assigned the task of writing grandiose-titled corporate documents that no one is ever expected to read." So, again, you'd just curse and say "Him? Architect?"

TimeSnapper version 3.4 went live a few days ago!

It can now run from a USB key, and is prettier in a few ways.

But the main feature is the new plugin model which lets you extend TimeSnapper with your own features.

The plugin model has been there for quite some time, but we've never publicised it before, or released any plugins that use it.

We've now released our first official plugin. A simple plugin that lets you create animated gifs from your snapshots. I've written a guide to help anyone who is interested in writing plugins of their own and provided a sample in VB, and a sample in C#. I can provide lots more examples, and information for anyone who is interested.

The animated gif plugin owes a debt of gratitude to Jon Galloway -- we reuse the Gif.Components.dll that he put together for his cropper plugin.

We're hoping to host plugins from other people -- we'll provide a nice page where people can download them. We'll help out with development, debugging and so on, wherever needed. If there's sufficient interest we'll spawn a separate forum for plugin development. (For now, the regular forum is the best place to ask questions).

APIs are funny things -- and I received a hell of a lot of criticism while writing this API. The criticism came from a particular nasty and vocal user who never seems to be happy with any of the work I provide. That user is (of course) (in case you haven't yet guessed it) -- me.

So, if you're looking at the plugin model and you see something you don't like about it. Well, I understand. Constructive critcism and suggestions on how to improve the API are very welcome.

As always there are full details in the release notes, and there are lots more goodies on the way.

• Tabs versus Spaces
• VB versus C#
• Java versus .Net
• Perfectionism versus Pragmatism
• Quality versus Quick and Dirty
• Linux versus Windows
• Apple versus Microsoft
• Emacs versus Vim
• SQL Server versus Oracle
• credit versus debit
• truth versus lies
• Lisp versus Scala
• Python versus Ruby
• spider-man versus batman