vbbox.plan

It is by will alone I write this stuff.

 

Inject new life into that Win3 box

Calmira is a kewl desktop manager for Windows 3.1x that literally turns that OS' tired desktop into a facsimile of Windows 95, 98 or XP. Very nice, but I wish I'd had it nine years ago =)

Remember the Program Manager? If you're running anything other than XP or 2003, just hit Win+R and enter 'progman' Ahh. The good old days!

Hmmm. I still have a lot of my 16-bit software lying around somewhere. I wonder how fast WFW will run on a 3GHz P4...

 

Scams: Sucking the bandwidth

This is interesting. It's a page that loads on your browser and refreshes a bunch of images coming from known phony scam "bank" and other "financial" sites so that their bandwidth is saturated, thus increasing their cost of operation.

Of course it's using your bandwidth to do it, but imagine what would happen if a million people loaded this page in the morning and closed it at night. There would be no more phishing scams, fake escrow dealers or 419 rats. It would be too expensive to maintain an scam operation under that kind of load.

Of course you could easily point this somewhere else and use it for evil. But it's an interesting idea. Maybe Lycos is right on track — or maybe not.

 

MSSQL: Using newid() on a UDF

Last night I was playing around with a SQL Server database trying to figure out how to enable a field on a table to take a unique identifier value — however, I couldn't use newid() because I needed different formatting. newid() returns a GUID in the form 4DA89473-83F5-40E6-9D6A-345A6E6D987A and I needed the string to be exactly 32 characters long, so that meant dropping the hyphens to get 4DA8947383F540E69D6A345A6E6D987A. It's a long story, but anyway.

Not really being the most proficient data dweeb in the planet (databases for me are mostly fancy stateful storage engines) I thought I'd "go 1337" and create my first user-defined function to return the formatted GUID. If you're amused by this please understand the last time I wrote a stored procedure Bill Clinton was still president. Well, not quite. I mean, I can write sprocs, I just don't like them. They remove all possibility of writing portable data access code. But I digress. I fired up the mighty query analyzer and got right down to it.

In my relational hubris I coded a simple thing that would take no parameters, call newid(), use SUBSTRING to splice the GUID and then concatenate the parts. Hahaha — hmmmm. SQL Server complained (with error 403, no less) that I had a case of "invalid use of newid() in a user-defined function". I told myself "eh?" and Googled a bit. It turns out that you can't call non-deterministic built-in methods from UDFs. This includes GETDATE() and so on. WHAT THE HECK IS WRONG WITH THIS THING???

But then I said to myself, I said "d00d, you can always just pass whatever newid() returns to the UDF!!". Boy, I'm so smart. Right. So I ended up coding the thing like this:

CREATE FUNCTION udfGuid (@uid varchar(36))
    RETURNS varchar(32) AS  
    BEGIN 
        declare @part1 varchar(8) 
        declare @part2 varchar(4)
        declare @part3 varchar(4)
        declare @part4 varchar(4)
        declare @part5 varchar(12)

        set @part1 = SUBSTRING(@uid, 1, 8)
        set @part2 = SUBSTRING(@uid, 10, 4)
        set @part3 = SUBSTRING(@uid, 15, 4)
        set @part4 = SUBSTRING(@uid, 20, 4)
        set @part5 = SUBSTRING(@uid, 25, 12)

        return (@part1 + @part2 + @part3 + @part4 + @part5)
    END

Then to incorporate it into the default value of a table field you'd do something like this:

([dbo].[udfGuid](newid()))

Where of course you're just passing te value returned by newid() to the UDF. A word of caution though — this introduces a dependency as far as MSSQL is concerned, so you won't be able to edit the UDF after you "bind" it to a table field. You've been warned.

I have absolutely no doubt someone out there has a better solution for this, but damn it, I feel proud of myself and I had to blog this <g>

 

Architecture: A rant about defects and XP

While looking at Martin Fowler's blog archive (looking for something unrelated) I noticed he has a brief write-up about how XP (nee eXtreme Programming) contributes to low defect rates in software projects.

This puzzles me because I've always considered good design, modularity and domain expertise (understanding what the heck you're doing before you actually do it) are the two keys to defect-free software. It puzzles me because he mentions "we are also seeing some of this at ThoughtWorks". Color me elitist but if a company at the top of the software architecture chain relies on something like XP to reduce their defect rates then I can say I'm genuinely scared.

XP might be the latest thang but ultimately it is a simple methodology with two basic premises: maintain your overhead low (in terms of administrative muck one has to deal with when working in corporate IT environments) and introduce checks and balances into the development cycle. The approach is novel but hardly groundbreaking — XP simply formalizes things that many of us have been doing for a long time — but perhaps more importantly, it gives IT managers a valid excuse when they have to say they didn't assign six analysts to "get the requirements going". There's nothing wrong with that, but then again it's hardly the silver bullet. Communication is a Good Thing, yes. Unit testing is also nice, especially if you happen to think it's some newfangled thing that some blogger invented last year =)

Defect rates in software are defined by different people in different ways. Personally I've always measured DF as "the number of bugs that require physical changes to the code that actually made it to the production environment, divided by the number of lines of code in the overall project". In other words, if you have a project that spans 30,000 lines of code and you've had to fix 24 defects in production so far, you have (24/(30000*.001)) = 0.8 or a Defect Rate Per Thousand Lines of Code (DF/KLOC) of 0.8%. That's pretty good. The ideal ratio is always under 1%, with the average business application being around 10-25% (in my experience). If you're writing infrastructure code you'll want to keep things under 0.7% or so, lest you find yourself coding client-side JavaScript or drawing unemployment benefits. Defect rates below the 0.1% threshold or so are difficult to achieve but not unheard of. Rates way below that are the lofty preserve of people who write software that goes to the moon or make the tip of the bomb and things like that.

What the DF/KLOC standard measures is overall quality of code and the ability of your team or organization to test software and identify defects in it. It does not measure productivity (we all know measuring developer productivity in lines of code is shortsighted and dumb). But it does give you an idea of how well you have this coding thing figured out. It gives you a concrete number you can worry or gloat over. But writing defect-free software is not easy, and in my very humble opinion no amount of methodology thrown at the problem will make it any easier. You might see improvements over what you're used to (and by %DEITY% we kow some shops are really challenged), but in the end it comes down to individual talent, dedication and skill. Last I checked those don't come in a book and are not given out at conferences in shiny shopping bags along with kewl swag.

Some of my six readers might think I have something against XP. The truth is that while I don't particularly like it, I do se its value, especially when used in development teams who, erm, are a bit lacking in the talent and experience departments. But I definitely don't appreciate people claiming XP has somehow heralded in a new age of defect-free software. Some of us were doing that before Beck, Cunningham et.al ever received their first royalty check.

There are a few simple rules for writing defect-free software that I've always relied on with some (if I may say) measure of success:

  1. The only time software is important is when it makes it to production. I really don't care that it works on your machine.
  2. If you don't understand it, you can't code it. If you didn't understand it but you coded it anyway, it will never work well. Ever.
  3. Cleverness is not a synonym for efectiveness, or elegance. If you can't figure out how to do it you probably shouldn't be doing it in the first place. See #2.
  4. Whatever you didn't code for will eventually happen, and you'll be sorry you didn't code for it.
  5. If you can't explain it to a manager in less than 5 minutes it's probably too complex. Keep it real.
  6. If it requires a midget to pull levers on the server four times a day you're probably designing in too many dependencies and requirements. Keep it clean and neat.
  7. If you can't tell me how it might be being used in two year's time you probably didn't think it through enough. When it does have to change (and believe me, it always does) you'll be in a lot of pain. Keep it flexible.
  8. If you requre physical access to the data center and a dry martini to deploy you probably pooched it. I should be able to deploy with a one-page instruction sheet printed in 12pt Times New Roman.
  9. If I can't understand it after looking at it for about an hour you probably didn't document it enough. Keep it verbose.
  10. "Ship early and often" is a cute motto used by people who ship defective software and expect others to find bugs for them. Unless you happen to be writing a twelve-line script that outputs the time of day, understand the project's scope and effort and make solid, realistic estimates — and then stick to them.
  11. There's nothing wrong with iterative development, as long as you're not iterating crap. Effective iteration in software development requires a sound design to begin with. Please don't insult my intelligence by trying to argue that releasing the same broken beta six times qualifies as such. There's an important difference between an incremental implementation and a fundamentally broken one.
  12. No programmer is an island. Don't code in a cave and come out only to feed and mate. Peer review will help you catch your most and least obvious mistakes. Never overestimate the depth of your own intellect. However, don't expect other people to lend you their brains to do something you're supposed to know how to accomplish.
  13. Asking questions is not a sign of stupidity, unless you're asking stupid questions. Not asking questions is also stupid.
  14. And finally, attention to detail is everything. Lack of attention will get you into trouble faster than you can say "holy crap". This is what you get paid for — do it well.

I remember a line from a Tom Clancy novel I read a few years ago about an aircraft carrier pilot who "knew naval aviation from tailhook to catapult". Successful software developers — and more importantly, successful architects — know the software development cycle from design to deployment and beyond. There's nothing extreme about that.

 

Architecture: New tool

Here's an interesting bit of tool I noticed thanks to an announcement in the MSNews server. Looks useable enough.

 

New plan for success

  1. Go to basketball game.
  2. Get beat up (was "???")
  3. Profit!

 

The open source "community" strikes again

I was perusing Google News today and I made my way to this article in the Seattle Post Intelligencer about some remarks made by Steve Ballmer at a conference in Singapore.

As always whenever anyone from Microsoft upper management says anything remotely targeted at open source, everyone related to open source immediately takes everything out of context and proclaims how yet again Microsoft is attacking them. Of course the Reuters wire article from which the original quote came from was later amended to note that Ballmer was quoting a study Microsoft had nothing to do with (of course it's well known that Microsoft pays for all studies that say anything other than gushingly positive things about open source and Linux, because it's a fact that Microsoft is the only entity that is competing with Linux). I noticed the nadir of the internet also picked it up yesterday, with the usual 500+ insightful "comments" as to how Microsoft is going to go away Real Soon Now. No, really. Trust us. We said that five years ago but This Time We Mean It.

Now, there is something deliciously ironic in seeing everyone moan and roll on the floor in amazement at what Ballmer says or doesn't say. As if they expect his job to be to defend open source warez. Or ignore them. I wonder what would happen if Microsoft ignored open source? They moaned when Microsoft ignored them, and they moan when Microsoft turns around and faces them. Damn if you do, damn if you don't. Of course for most of these people the idea that their hobby OS has been taken over by corporations because that's the only way it will ever make it out of hobby status is hard to swallow. And the idea that Microsoft now has an actual tangible target to compete against should scare them, because that's what Microsoft is good at. It's interesting to see how they consider themselves to be somehow untouchable. How dare anyone say anything negative about us!? We give stuff away and that makes us superior in every way!!1! Their problem is that they still think it's them against the "Evil Empire", as if at this point anyone sees them in any way other than as a user base or actually cared about them.

Speaking of that Bashdork article, I was reading through the "comments" and I noticed a common theme in the ones that were "modded" positively: Ballmer's comments are a bad move because they amount to claiming that "if you don't use Microsoft software you'll be sued", and that apparently does not go over well with Asian businesses. Regardless of whether or not you make that connection (and I don't, though of course I doubt he said that just because he didn't have anything else to talk about) this is an interesting opinion because it's championed by the same group of people who claim businesses are "stupid" because they use Microsoft software. If you've ever heard one of these zealots rant about why "M$" is successful you always come around to the same thing: companies (and the people who run them) are "stupid" because they do not see the light and switch their IT infrastructures to "open source". It's surprising you can call them "stupid" and then turn around and claim the same poor stupid sods can actually grasp the nuance of a paragraph in a speech. But I suppose stranger things have happened.

But anyway, what really triggered this blog entry were the comments in the Seattle PI article. I've written before about how this "community" is going to figure out one of these days that it was probably a bad idea to attract all these borderline zealot extremist retards — the most dangerous of which come disguised in the "I sound like I know what I'm talking about" internet-enabled façade. Boy, I had quite the chuckle session there.

 

The latest meme?

This might be right up there with AYB. Maybe.

Wonder where that darn frog is though.

 

 

 

 

 

 

 

 

© 2003-2004 Klaus H. Probst BLOGGER