I've just published my 32nd article on CodeProject.
It's kind of like a software release. You know you've tested it to buggery and you have a level of confidence but there's still the chance that you've missed something that's forehead smackingly obvious... after the event!
Would I have it any other way? Not on your life. I enjoy writing articles and I'll take my chances with relevance. I won't take my chances with accuracy or correct code - those are both under my control. But as long as these hands can type I'll be wanting to write and share.
Tuesday, November 30, 2004
Monday, November 29, 2004
This is a little gem
I found this in some C++ code I've inherited. The preceding code isolates a file extension into an STL string, strExt. The code then does case sensitive compares against a range of file extensions and branches to appropriate code. Somewhere along the line my predecessor must have run into a variety of capitalisations, hence this.
else if (strExt == _T(".txt") strExt == _T(".TXT") strExt == _T(".Txt"))
else if (strExt == _T(".txt") strExt == _T(".TXT") strExt == _T(".Txt"))
The state of car advertising
If you've never heard an advertisment, on the radio, for cars in the USA you have a treat ahead of you! A 30 second spot usually consists of about 15 seconds of fluff about how if you're not driving an XXX you're going bald, not getting enough sex and have halitosis. That or you're not a dynamic go-getting 20something power broker about to solve world hunger in between brokering a world shattering deal and being kind to kittens. You get the idea.
After that initial 15 seconds you get another 5 seconds of how this particular dealership has the best deal. Ho hum.
The final 10 seconds is incredible. I've never heard anyone talk so fast! X does not apply, not subject to Y, loyalty bonus of such and such, residency restrictions... etc etc. I reckon the average dealership manages to cram 15 outs into that final 10 seconds!
So this weekend Lou Grubb Ford, Scottsdale, are advertising a 'dollar below invoice sale'. Yes, you heard right! They'll sell you any car on their lot for one dollar below invoice. Sound too good to be true? Uh huh. In that final 10 second gabble is this gem. 'Invoice may not reflect true dealer cost.'.
How can that possibly represent adherence to any kind of fair advertising code let alone a reasonable state requirement for accurate advertising?
For the record: I drive a Kia.
After that initial 15 seconds you get another 5 seconds of how this particular dealership has the best deal. Ho hum.
The final 10 seconds is incredible. I've never heard anyone talk so fast! X does not apply, not subject to Y, loyalty bonus of such and such, residency restrictions... etc etc. I reckon the average dealership manages to cram 15 outs into that final 10 seconds!
So this weekend Lou Grubb Ford, Scottsdale, are advertising a 'dollar below invoice sale'. Yes, you heard right! They'll sell you any car on their lot for one dollar below invoice. Sound too good to be true? Uh huh. In that final 10 second gabble is this gem. 'Invoice may not reflect true dealer cost.'.
How can that possibly represent adherence to any kind of fair advertising code let alone a reasonable state requirement for accurate advertising?
For the record: I drive a Kia.
Thursday, November 25, 2004
Loss of privileges
I've finally bitten the bullet and changed my user account on this machine to non-admin. Yeah I know, should have done it years ago. Better late than never eh? There wasn't any particular prompt for the change (no disaster caused by my being an admin). It just seemed like it was time to 'do the right thing'. It's early days yet but so far everything I do on a day to day basis seems to work just fine.
Almost the only inconvenience is that I'm working on a new series of CP articles involving services. Naturally this means I have to start and stop em at various times which means frequent 'runas' sessions.
Almost the only inconvenience is that I'm working on a new series of CP articles involving services. Naturally this means I have to start and stop em at various times which means frequent 'runas' sessions.
Wednesday, November 24, 2004
Musings
This article[^] by Raymond Chen got me thinking about the whole software user/developer relationship. Actually it wasn't Raymond's article, it was the responses. It's pretty clear to me that Raymond's readership is primarily software developers. And it's also pretty clear to me that among developers there's a culture of 'I know better than the user'. Which at one level may be true. I do know better than the average user if we're talking about the mechanics of developing software. Does that mean I know better than the user when it comes to how the software shall be used?
You're going to have to argue very very persuasively indeed to convince me that developers know better than the user all the subtle nuances of the ways a user may employ our products.
Raymond's talking about those 'annoying' directories that get created when you install windows. My Documents, My Music et al. Those of us close to the development process have probably been doing it for years and we've learned from prior art. I spent some years (1986 - 1990) working with Unix; to this day my development machine has \usr\src and all my projects below that. I also have \usr\bin for various tools, \usr\man for my documentation and so on... How very non windowsish!
And now Windows comes along and creates My Documents, My Images etc.. I don't want to use those locations for my own stuff, though my reasons for not wanting to use them are totally illogical. I just want to keep on using \usr\ because that's what I'm comfortable with. And yet, whenever my non developer friends ask me how they should organise their system (I'm a programmer so I'm obviously an 'expert') I always advise them to save their documents in My Documents, their photos in My Images and so on. Why? Because I can't advance a single convincing reason, even to myself, to NOT use those classifications. For the most part this is more than enough; and when it comes time for me to be called in my capacity as computer rescuer it makes it sooo much easier to find the stuff I need to backup before reinstalling their O/S.
This is a case where I think Microsoft got it right. I've read enough about how Microsoft approach the user experience to know that they didn't just pull the My Documents stuff out of thin air. I don't know a single developer who uses their classifications; we all have 'good' reasons to stick to the way we've been organising our stuff for the last ten/twenty/thirty years. But I know many users who do use their classifications. The mere act of creating those classifications, on a user by user basis AND defaulting the storage location to those classifications based on document type is a huge step forward for the average user.
[Post shower addendum]
We most of us developers assume a level of knowledge (and ability to care) in our users that just isn't there. It's not a lot different from a car designer assuming that we know how to tune a dual carb system. It's not all that difficult (I learned it 30 years ago and forgot it 20 years ago) but it's just not something I want to do. Likewise our users simply don't want to know how to organise their stuff into nice neat directory heirarchies. Just as I want my (single) carb car to just start tomorrow morning I believe our users want the system to take care of saving their stuff and finding it the next time they want to look at it. Exactly where it's stored is of no importance whatsoever; what's important is that it's stored and easily retrieved.
[/Post shower addendum]
You're going to have to argue very very persuasively indeed to convince me that developers know better than the user all the subtle nuances of the ways a user may employ our products.
Raymond's talking about those 'annoying' directories that get created when you install windows. My Documents, My Music et al. Those of us close to the development process have probably been doing it for years and we've learned from prior art. I spent some years (1986 - 1990) working with Unix; to this day my development machine has \usr\src and all my projects below that. I also have \usr\bin for various tools, \usr\man for my documentation and so on... How very non windowsish!
And now Windows comes along and creates My Documents, My Images etc.. I don't want to use those locations for my own stuff, though my reasons for not wanting to use them are totally illogical. I just want to keep on using \usr\ because that's what I'm comfortable with. And yet, whenever my non developer friends ask me how they should organise their system (I'm a programmer so I'm obviously an 'expert') I always advise them to save their documents in My Documents, their photos in My Images and so on. Why? Because I can't advance a single convincing reason, even to myself, to NOT use those classifications. For the most part this is more than enough; and when it comes time for me to be called in my capacity as computer rescuer it makes it sooo much easier to find the stuff I need to backup before reinstalling their O/S.
This is a case where I think Microsoft got it right. I've read enough about how Microsoft approach the user experience to know that they didn't just pull the My Documents stuff out of thin air. I don't know a single developer who uses their classifications; we all have 'good' reasons to stick to the way we've been organising our stuff for the last ten/twenty/thirty years. But I know many users who do use their classifications. The mere act of creating those classifications, on a user by user basis AND defaulting the storage location to those classifications based on document type is a huge step forward for the average user.
[Post shower addendum]
We most of us developers assume a level of knowledge (and ability to care) in our users that just isn't there. It's not a lot different from a car designer assuming that we know how to tune a dual carb system. It's not all that difficult (I learned it 30 years ago and forgot it 20 years ago) but it's just not something I want to do. Likewise our users simply don't want to know how to organise their stuff into nice neat directory heirarchies. Just as I want my (single) carb car to just start tomorrow morning I believe our users want the system to take care of saving their stuff and finding it the next time they want to look at it. Exactly where it's stored is of no importance whatsoever; what's important is that it's stored and easily retrieved.
[/Post shower addendum]
Monday, November 22, 2004
And now for something completely different
I went for a drive today, through Phoenix, for no particular reason. Just because I felt like it. Car radio on, listening to something... well let's not go into which aspect of talk radio exasperated me today... So I decided to switch to FM and go find a classical music station. In a city of three and a half million or so there are, naturally, a lot of radio stations. We even have an embarassment of riches. At least 3 classical music stations.
I found the first one; it was playing Mozart. Went searching for a second one. It was playing Mozart. Went searching and found the third one. It was playing Vivaldi. (I bet you thought it'd be Mozart - I certainly expected Mozart ). I was driving for about 3 hours (and add to that a stop at Starbucks). The range of composers these three stations ran through consisted of:
Mozart.
Carl Ditters van Dittersdorf.
Haydn.
Vivaldi.
(for a delicious thrill) Salieri.
Early Beethoven. Nothing later than his second symphony.
You might have guessed that I like classical music. Let's not go into the fact that the term 'Classical' has a specific meaning - here I'm using the word as the great unwashed would use it. So how does it happen that of the three 'classical' music stations in Phoenix, not one of them seems able to play anything written later than about 1800? I might add that, though this might seem like a small sample (3 or so hours on a Sunday afternoon) it's actually fairly representative of the fare on offer whatever the day or the hour.
Now why is this? Do the people who create the program lists have a bias toward the Baroque? Don't they know about the excellent music that's been written under the 'classical' umbrella since 1800? Many years ago I went through some musical education: it was biased toward the Baroque. Are these programmers the natural outcome of an educational process that emphasises the Baroque?
This differs a little from the situation where I come from; there we had two classical music stations that I can recall, MBS and ABC. Neither was a 'for profit' station. Indeed, the ABC is government funded. Even in that situation it was rare for a radio station to commit to running a symphony that ran a whole hour, let alone 3+ hours for an opera but they did do it. I'm sure you can see where I'm going with this. I suspect the classical music stations here stick to Baroque due to the relative brevity of a piece - it lets them get more ads in per hour.
I found the first one; it was playing Mozart. Went searching for a second one. It was playing Mozart. Went searching and found the third one. It was playing Vivaldi. (I bet you thought it'd be Mozart - I certainly expected Mozart ). I was driving for about 3 hours (and add to that a stop at Starbucks). The range of composers these three stations ran through consisted of:
Mozart.
Carl Ditters van Dittersdorf.
Haydn.
Vivaldi.
(for a delicious thrill) Salieri.
Early Beethoven. Nothing later than his second symphony.
You might have guessed that I like classical music. Let's not go into the fact that the term 'Classical' has a specific meaning - here I'm using the word as the great unwashed would use it. So how does it happen that of the three 'classical' music stations in Phoenix, not one of them seems able to play anything written later than about 1800? I might add that, though this might seem like a small sample (3 or so hours on a Sunday afternoon) it's actually fairly representative of the fare on offer whatever the day or the hour.
Now why is this? Do the people who create the program lists have a bias toward the Baroque? Don't they know about the excellent music that's been written under the 'classical' umbrella since 1800? Many years ago I went through some musical education: it was biased toward the Baroque. Are these programmers the natural outcome of an educational process that emphasises the Baroque?
This differs a little from the situation where I come from; there we had two classical music stations that I can recall, MBS and ABC. Neither was a 'for profit' station. Indeed, the ABC is government funded. Even in that situation it was rare for a radio station to commit to running a symphony that ran a whole hour, let alone 3+ hours for an opera but they did do it. I'm sure you can see where I'm going with this. I suspect the classical music stations here stick to Baroque due to the relative brevity of a piece - it lets them get more ads in per hour.
Sunday, November 21, 2004
Hidden dependencies
If you've been following my entries over the past week you'll know I've just finished a release. Burned to CD, nicely labelled and dispatched by horny-handed messenger to the corners of the earth.
A couple of days later I installed the release on a clean machine (as I'd done each morning during the release process) but this time I exercised a dialog box I hadn't exercised during the release testing. And dammit, it didn't even appear. Hmmmm. So I go to my development machine running the same code and the dialog box appears. Just to be sure, I installed the release on another clean machine and no dialog box. Actually there were two dialog boxes that didn't appear, but other dialog boxes did appear. The two that failed to appear both use the ListView control. The ones that appeared only use standard pre Win95 controls (edit boxes, buttons etc).
Ok, let's be methodical about this. It works on my development box but not on a clean box. I decided to install the development environment on the clean machine and single step through the code to work out where it's going wrong. So an hour later I've installed VC6, copied the source code from SourceSafe and I'm ready to test. But just to be sure, I run the app again outside the development environment and this time the dialog box appears! WTF?
Hopefully it's obvious that the mere act of installing VC6 (without even running it) fixed the problem. So how does installing VC6 change the system? Well for one thing, it installs and registers a bucketload of OCX's. And, to cut a long story short, that was the problem. This MFC app uses the VB wrapper OCX around COMCTL32.DLL. I ran the app on my development machine under the debugger, waited until all the 'loading *.dll' messages died down and then opened the dialog box. Up pops MSCOMCTL.OCX in the list. Aha!! So I copy that OCX from my development machine to the clean machine (the second one without the development environment) and register it. Voila!! The dialog opens just fine. Unregister the OCX and, of course, the dialog fails.
How did this situation arise in the first place? I inherited this code from another developer who told me he'd started the app in VB6 but couldn't get the performance required so he migrated it to MFC. Along the way he'd taken a control he was familiar and comfortable with and used it instead of learning how to use ListView directly. Well ok, that explains how this MFC app ended up using a VB wrapper OCX. But how come it's taken until now (around 2 years) for the problem to surface?
My predecessor's method of installing the software was to install the development system on each new system (I should note that we have a very restricted audience for this software - it's part of a half a million dollars production machine). Then he'd copy the latest source code from his laptop and compile it in place. His average time to achieve all this was at least a day.
When I joined the company I was aghast at this. I set myself the goal of producing installation CD's and bringing up a new machine in less than 30 minutes. Achieved it too; if you're upgrading an existing machine. Ah well, next months release will contain the OCX so it'll work properly on virgin hardware too.
And now for the mea culpa. It's obvious that my release testing isn't thorough enough. From now on release CD tests will include exercising every dialog box. But methinks I need to test much more than I've been testing. Much thought is required.
A couple of days later I installed the release on a clean machine (as I'd done each morning during the release process) but this time I exercised a dialog box I hadn't exercised during the release testing. And dammit, it didn't even appear. Hmmmm. So I go to my development machine running the same code and the dialog box appears. Just to be sure, I installed the release on another clean machine and no dialog box. Actually there were two dialog boxes that didn't appear, but other dialog boxes did appear. The two that failed to appear both use the ListView control. The ones that appeared only use standard pre Win95 controls (edit boxes, buttons etc).
Ok, let's be methodical about this. It works on my development box but not on a clean box. I decided to install the development environment on the clean machine and single step through the code to work out where it's going wrong. So an hour later I've installed VC6, copied the source code from SourceSafe and I'm ready to test. But just to be sure, I run the app again outside the development environment and this time the dialog box appears! WTF?
Hopefully it's obvious that the mere act of installing VC6 (without even running it) fixed the problem. So how does installing VC6 change the system? Well for one thing, it installs and registers a bucketload of OCX's. And, to cut a long story short, that was the problem. This MFC app uses the VB wrapper OCX around COMCTL32.DLL. I ran the app on my development machine under the debugger, waited until all the 'loading *.dll' messages died down and then opened the dialog box. Up pops MSCOMCTL.OCX in the list. Aha!! So I copy that OCX from my development machine to the clean machine (the second one without the development environment) and register it. Voila!! The dialog opens just fine. Unregister the OCX and, of course, the dialog fails.
How did this situation arise in the first place? I inherited this code from another developer who told me he'd started the app in VB6 but couldn't get the performance required so he migrated it to MFC. Along the way he'd taken a control he was familiar and comfortable with and used it instead of learning how to use ListView directly. Well ok, that explains how this MFC app ended up using a VB wrapper OCX. But how come it's taken until now (around 2 years) for the problem to surface?
My predecessor's method of installing the software was to install the development system on each new system (I should note that we have a very restricted audience for this software - it's part of a half a million dollars production machine). Then he'd copy the latest source code from his laptop and compile it in place. His average time to achieve all this was at least a day.
When I joined the company I was aghast at this. I set myself the goal of producing installation CD's and bringing up a new machine in less than 30 minutes. Achieved it too; if you're upgrading an existing machine. Ah well, next months release will contain the OCX so it'll work properly on virgin hardware too.
And now for the mea culpa. It's obvious that my release testing isn't thorough enough. From now on release CD tests will include exercising every dialog box. But methinks I need to test much more than I've been testing. Much thought is required.
Thursday, November 18, 2004
We got it out the door today
and it wasn't even that painful. Ummm what am I talking about? Software release number 1 under my control .
I got to the office this morning and found an email awaiting me that said the tooing and froing about a portion of the release (between two developers) was over and it was ready for the big time. Included in the email were exact instructions from one of the developers about which files I needed to get from SourceSafe to create the installer. So I go to our build machine and 'get' the installer script for that product. It has references to drive H. It turns out that when that developers machine was built there was some kind of USB device exposing multiple logical devices and the XP install saw them first - so his drives C to G are USB devices and his hard disk is drive H. Now you'd imagine that this shouldn't present a problem. After all we all of us use relative paths and we never hard code drive letters right? Right!
Alas, the build product I chose (Visual Build Pro version 5.5), whilst an otherwise excellent product and warmly recommended, insists on having a drive letter as part of every path. I can think of good reasons for this and good reasons against this.
So it's about 10:00 AM. The timestamp on the email telling me which files I need to get is 4:37 AM so I know the poor bugger was up late. I decided to wait until about noon but he rang me a little earlier than that to check what was happening. At this point we have a choice; we can spend most of the day working out what to do and possibly miss shipping yet again or we can do whatever it takes to get it out today and worry about it tomorrow. Part of me says we spend the time to get it right the first time (in terms of the build process). Another part of me says that from the customers point of view they don't care about our build process - they care about getting functional software. My arguments about not releasing whilst we're working through issues with the software don't hold when we're discussing the build process so I decide we'll hack his install scripts to get a working installer that 'does the right things' and 'we'll fix the scripts tomorrow'.
A bit of tooing and froing and we have an installer that installs his software. A bit more tooing and froing and we have a complete set of manuals. I do a couple of test burns of the complete suite and run my standard tests and we're good to go! It's now about 3:30 PM.
So I burn 10 cd's and print 10 labels. 4 cd's go to one location, 2 each go to 2 other locations, one goes home with me (I like trophies) and one goes into our physical library at the office. Each cd passes burn verification and also is readable on other PC's.
So now I've got 10 cd's and 10 labels. Do you remember a post I made a day or two ago about how this was going to be our first release with professional looking deliverables? You'll never guess what I overlooked. Not in a million years. Our cd contains professional looking manuals, professional looking software. When you stick it in the CD drive autostart takes over and pulls up a somewhat spartan but nonetheless professional looking web page with our company logo and a bunch of links to install the software or read the manuals.
I apply the label to the first CD and sit back examining it. Damn damn damn. The one thing I didn't think about was this: when I did my first test run two days ago I'd used a Memorex CD. They have silver printing that doesn't show through the labels. On Tuesday I went to Staples to get a bunch of Jewel Cases and found they had a special - Jewel Case AND blank CD-R for about the same price I'd pay for the Jewel Case. So I got the combo (shrink wrapped) without checking what was printed on the label side of the CD. So we've got this white label on the CD and clearly visible through it is the Staples logo. To make it worse, the large black Staples logo was obviously seen by me as I inserted each CD into the burner and it STILL didn't click. It's now 4:30 PM and there ain't enough time to get more blank labels, a bunch of blank CD-R's without anything printed on the label side, burn the buggers and make the Fedex pickup time. So our first CD release had to go out with the Staples logo clearly visible through the label.
I got to the office this morning and found an email awaiting me that said the tooing and froing about a portion of the release (between two developers) was over and it was ready for the big time. Included in the email were exact instructions from one of the developers about which files I needed to get from SourceSafe to create the installer. So I go to our build machine and 'get' the installer script for that product. It has references to drive H. It turns out that when that developers machine was built there was some kind of USB device exposing multiple logical devices and the XP install saw them first - so his drives C to G are USB devices and his hard disk is drive H. Now you'd imagine that this shouldn't present a problem. After all we all of us use relative paths and we never hard code drive letters right? Right!
Alas, the build product I chose (Visual Build Pro version 5.5), whilst an otherwise excellent product and warmly recommended, insists on having a drive letter as part of every path. I can think of good reasons for this and good reasons against this.
So it's about 10:00 AM. The timestamp on the email telling me which files I need to get is 4:37 AM so I know the poor bugger was up late. I decided to wait until about noon but he rang me a little earlier than that to check what was happening. At this point we have a choice; we can spend most of the day working out what to do and possibly miss shipping yet again or we can do whatever it takes to get it out today and worry about it tomorrow. Part of me says we spend the time to get it right the first time (in terms of the build process). Another part of me says that from the customers point of view they don't care about our build process - they care about getting functional software. My arguments about not releasing whilst we're working through issues with the software don't hold when we're discussing the build process so I decide we'll hack his install scripts to get a working installer that 'does the right things' and 'we'll fix the scripts tomorrow'.
A bit of tooing and froing and we have an installer that installs his software. A bit more tooing and froing and we have a complete set of manuals. I do a couple of test burns of the complete suite and run my standard tests and we're good to go! It's now about 3:30 PM.
So I burn 10 cd's and print 10 labels. 4 cd's go to one location, 2 each go to 2 other locations, one goes home with me (I like trophies) and one goes into our physical library at the office. Each cd passes burn verification and also is readable on other PC's.
So now I've got 10 cd's and 10 labels. Do you remember a post I made a day or two ago about how this was going to be our first release with professional looking deliverables? You'll never guess what I overlooked. Not in a million years. Our cd contains professional looking manuals, professional looking software. When you stick it in the CD drive autostart takes over and pulls up a somewhat spartan but nonetheless professional looking web page with our company logo and a bunch of links to install the software or read the manuals.
I apply the label to the first CD and sit back examining it. Damn damn damn. The one thing I didn't think about was this: when I did my first test run two days ago I'd used a Memorex CD. They have silver printing that doesn't show through the labels. On Tuesday I went to Staples to get a bunch of Jewel Cases and found they had a special - Jewel Case AND blank CD-R for about the same price I'd pay for the Jewel Case. So I got the combo (shrink wrapped) without checking what was printed on the label side of the CD. So we've got this white label on the CD and clearly visible through it is the Staples logo. To make it worse, the large black Staples logo was obviously seen by me as I inserted each CD into the burner and it STILL didn't click. It's now 4:30 PM and there ain't enough time to get more blank labels, a bunch of blank CD-R's without anything printed on the label side, burn the buggers and make the Fedex pickup time. So our first CD release had to go out with the Staples logo clearly visible through the label.
Wednesday, November 17, 2004
Wdevs is doing something right
I just did a search on my name on google and WDevs rated even higher than CodeProject. Yikes, I hope my boss doesn't do these kinds of searches. On the other hand, if you find this blog entry oh boss of mine - you're NOT paying me enough you cheap bastard!!!
In other results, I'm fascinated to see that my article on using MAPI, dating from 1999 on CodeGuru, is featured on a link from the University of Wisconsin where the URL implies that it's the department of Neurophysics. I have good company there; there are also articles by P J Naughter, Chris Maunder and Mike Dunn What really fascinates me about my article being featured is just how bad it is. Back in 1999 it seems that I thought it was enough to present two paragraphs plus the header file and consider it an article. Rereading that article makes me cringe. I redid the article on CodeProject in 2004 with a lot more explanation (and a mention that it had first appeared on CodeGuru).
The other thing that really stands out is how many sites mirror articles from CodeProject. There seem to be dozens of Russian sites that host, in English, CodeProject articles. I haven't yet found a site that translates my English to another language - but rest assured that when I do I'm going to save that sucker and burn it to a CD, purely for ego purposes :)
In other results, I'm fascinated to see that my article on using MAPI, dating from 1999 on CodeGuru, is featured on a link from the University of Wisconsin where the URL implies that it's the department of Neurophysics. I have good company there; there are also articles by P J Naughter, Chris Maunder and Mike Dunn What really fascinates me about my article being featured is just how bad it is. Back in 1999 it seems that I thought it was enough to present two paragraphs plus the header file and consider it an article. Rereading that article makes me cringe. I redid the article on CodeProject in 2004 with a lot more explanation (and a mention that it had first appeared on CodeGuru).
The other thing that really stands out is how many sites mirror articles from CodeProject. There seem to be dozens of Russian sites that host, in English, CodeProject articles. I haven't yet found a site that translates my English to another language - but rest assured that when I do I'm going to save that sucker and burn it to a CD, purely for ego purposes :)
Tuesday, November 16, 2004
Wish me luck, part 2
Well, the release didn't happen. I'm going to word this very carefully because I know at least one person at the office reads this blog - but also because effecting cultural change is a slow process and in a relatively creative field such as S/W development it's very difficult to achieve such a change without everyone on the team buying into the deal.
The long and the short of it is that the release didn't happen because a new feature, added at the last minute by one developer at the suggestion of another developer had a bug.
The two developers in question test each others work. I, as the new chum on the team, don't know enough (yet) about what their part of the product does to be able to offer constructive suggestions. Unfortunately, one of the two developers in question is on the other side of the International Date Line at the moment and 15 hours ahead of us. So he gets a new build and tests it - reports a bug and goes to bed. The other guy awakens, sees the bug report, fixes it, sends a new build and goes to bed. The first guy awakens and.... well you get the idea.
So here we are with a release sitting right on the edge and ready to go - with a bug in a new feature. Do you wait another day, just ignore it, or do you conditionally compile out the new feature and postpone it to the next release? I've already said I don't know enough about that part of the product to offer constructive suggestions so my gut feel was to let the author of the new feature make the decision. He believes it's fixed in the build currently awaiting verification (actually, at the time of writing it should have been verified) so I'll let it go another day.
Now understand, I'm not affixing blame here. I've been a software developer long enough to know that curbing enthusiasm is sometimes a good thing but I also know how an idea can take hold of you and beg to be coded. I don't want to, and won't, discourage anyone on the team from offering up ideas for consideration. I also don't want a situation where the 'release date' becomes the all consuming passion of everyone and every decision is warped by that looming presence. Nonetheless, sometimes it's necessary to draw a line in the sand, freeze features and focus on getting a functioning release out the door.
When I arrived at the office this morning I found an email from the developer who's currently on the other side of the IDL suggesting a change to my part of the product. It's a good suggestion, pretty easy to implement and useful to the customer. And my first thought was 'no way is it going into todays release'.
Let's be honest. In part that thought was because even though the idea is a good suggestion, pretty easy....... blah blah..... it's just not sexy and we, as developers, are partly driven by the sexiness of an idea. 20 years ago I'd have probably started implementing it anyway just to prove what a clever/fast bastard I can be. But not now. Now I know that we're not judged solely by how clever we are. Customers want, first and foremost, software that works. In much the same way that I'm no longer impressed by an engine with double overhead cams and an all aluminium head (because I don't care how the car works - just that it gets me to where I want to go) our customer isn't impressed by how cleverly we wrote a multithreaded pool manager. They don't care how we do it - what they want is for their $80,000 batch of semiconductors to be tested in 8 hours and to get an accurate report that tells them which ones to ship and which ones to post mortem.
We've now agreed that we're going to feature freeze 5 days ahead of release date. Let's see if that agreement holds shall we?
[Let down]. So today I created the template for our CD label and wrote the HTML page our CD will offer up when autostart kicks in. I did a test burn with what we had, labelled the CD and tested it on every machine I could see (to be sure the label didn't render the CD unreadable). I'm going to keep that incomplete CD and probably staple it to a wall somewhere to remind me of today.
So we missed the deadline but I still finished the day feeling like we'd accomplished something. I even got to go home early
The long and the short of it is that the release didn't happen because a new feature, added at the last minute by one developer at the suggestion of another developer had a bug.
The two developers in question test each others work. I, as the new chum on the team, don't know enough (yet) about what their part of the product does to be able to offer constructive suggestions. Unfortunately, one of the two developers in question is on the other side of the International Date Line at the moment and 15 hours ahead of us. So he gets a new build and tests it - reports a bug and goes to bed. The other guy awakens, sees the bug report, fixes it, sends a new build and goes to bed. The first guy awakens and.... well you get the idea.
So here we are with a release sitting right on the edge and ready to go - with a bug in a new feature. Do you wait another day, just ignore it, or do you conditionally compile out the new feature and postpone it to the next release? I've already said I don't know enough about that part of the product to offer constructive suggestions so my gut feel was to let the author of the new feature make the decision. He believes it's fixed in the build currently awaiting verification (actually, at the time of writing it should have been verified) so I'll let it go another day.
Now understand, I'm not affixing blame here. I've been a software developer long enough to know that curbing enthusiasm is sometimes a good thing but I also know how an idea can take hold of you and beg to be coded. I don't want to, and won't, discourage anyone on the team from offering up ideas for consideration. I also don't want a situation where the 'release date' becomes the all consuming passion of everyone and every decision is warped by that looming presence. Nonetheless, sometimes it's necessary to draw a line in the sand, freeze features and focus on getting a functioning release out the door.
When I arrived at the office this morning I found an email from the developer who's currently on the other side of the IDL suggesting a change to my part of the product. It's a good suggestion, pretty easy to implement and useful to the customer. And my first thought was 'no way is it going into todays release'.
Let's be honest. In part that thought was because even though the idea is a good suggestion, pretty easy....... blah blah..... it's just not sexy and we, as developers, are partly driven by the sexiness of an idea. 20 years ago I'd have probably started implementing it anyway just to prove what a clever/fast bastard I can be. But not now. Now I know that we're not judged solely by how clever we are. Customers want, first and foremost, software that works. In much the same way that I'm no longer impressed by an engine with double overhead cams and an all aluminium head (because I don't care how the car works - just that it gets me to where I want to go) our customer isn't impressed by how cleverly we wrote a multithreaded pool manager. They don't care how we do it - what they want is for their $80,000 batch of semiconductors to be tested in 8 hours and to get an accurate report that tells them which ones to ship and which ones to post mortem.
We've now agreed that we're going to feature freeze 5 days ahead of release date. Let's see if that agreement holds shall we?
[Let down]. So today I created the template for our CD label and wrote the HTML page our CD will offer up when autostart kicks in. I did a test burn with what we had, labelled the CD and tested it on every machine I could see (to be sure the label didn't render the CD unreadable). I'm going to keep that incomplete CD and probably staple it to a wall somewhere to remind me of today.
So we missed the deadline but I still finished the day feeling like we'd accomplished something. I even got to go home early
Monday, November 15, 2004
Wish me luck
Tomorrow (Monday November 15th) we do our first software release for which I take responsibility. It's taken a while to get my organisation to agree that ad hoc releases where someone decides it's 'ready' and emails a copy off to the customer should be a thing of the past.
I've instituted daily builds based on 'gets' from our sourcesafe database. So far no one's broken the build but it's early days yet - we've only been doing this for about 3 weeks. But it has given me a certain level of confidence - we're now able to get unbroken debug AND release builds. My build script (I'm using Kinook Softwares Visual Build) deletes the entire source tree on the build machine, gets the latest source and recompiles from scratch. Then it builds each install package. At the end of the build process it emails the results to me and each member of the team. Each day I review last nights build results. And each day I spend a couple of hours reformatting the hard disk on a computer, install Windows XP and install our packages. It's not quite as wasteful as it sounds. I kick off the boot from the Windows XP cd when I arrive at the office and carry on with normal work with only the occasional interruption. I probably waste more time stepping outside for a smoke than I do with the clean installs
So far it's looking good (and it's orders of magnitude better than the situation I found when I joined this company).
So tomorrow is crunch day. I do the final build - the final clean machine install - the final functional test. And then I get to do it all again on a machine that didn't experience clean machine install. I get to run it all on a machine that's being upgraded from our old (random) version, to our new standardised version. All being well I'll be burning our CD of the release mid-afternoon.
Don't imagine that tomorrow is the first time I'm doing this . I've been playing this game way too long to fall for that.
Nevertheless things can go wrong. If they do I'm going to dig my heels in and insist that, even though we're two weeks past the initial release date, we DO NOT release. Sure, we might miss a date by a day or more (added to the two weeks we've already missed). Will our customer forgive a bad release because we stuck to a date that we and they pulled out of our bums? I suspect not.
If nothing goes wrong our customer will recieve, for the first time, a set of professionally labelled CD's. None of this cheap memorex CD-R with the name and version of the software written with a felt tip pen. Ummm well it will be cheap memorex CD-R's but they'll be properly labelled and looking professional. What's more, when they insert em and let Windows auto notification take over they'll get a professional looking web page with release notes and install links.
Let's be fair to management where I work (especially since I'm part of management - much to my surprise). They hadn't thought in terms of the oobe. Oobe? Out of box experience. I'll be the first to admit that much of what I do is based on what I've read about how Microsoft manage their software development process. They do daily builds and visit the wrath of hell on s/he who breaks the build. As shall I. And they obsess about the oobe.
Two nights ago I had to reinstall the kids computer. Because it's the kids computer it is always the one that has the spyware/malware/viruses on it. They neither know nor care that someone out there wants to own their computer. So every so often I get to the point of throwing up my hands and blowing that machine away, reinstalling and the whole works. This time I installed WinXP on it (instead of Win2K). Imagine my surprise when, after the install, I discovered that it had gone out and found our network printer and automatically set it as the default. This is what I think of as a good oobe experience. It did the right thing.
I'm disposed to like Microsoft (though I don't want to work for them). Our customer is disposed to like us - if we can get it right. I'm disposed toward Microsoft because, despite their flaws, they get most things right. So I come at this whole thing from the point of view of wanting to impress the hell out of MY customer by looking professional AND by getting most of it right. I don't expect to get it 100% right. But if we can, for the first time, deliver them software that works, whatever its imperfections, that's a big step forward.
I've instituted daily builds based on 'gets' from our sourcesafe database. So far no one's broken the build but it's early days yet - we've only been doing this for about 3 weeks. But it has given me a certain level of confidence - we're now able to get unbroken debug AND release builds. My build script (I'm using Kinook Softwares Visual Build) deletes the entire source tree on the build machine, gets the latest source and recompiles from scratch. Then it builds each install package. At the end of the build process it emails the results to me and each member of the team. Each day I review last nights build results. And each day I spend a couple of hours reformatting the hard disk on a computer, install Windows XP and install our packages. It's not quite as wasteful as it sounds. I kick off the boot from the Windows XP cd when I arrive at the office and carry on with normal work with only the occasional interruption. I probably waste more time stepping outside for a smoke than I do with the clean installs
So far it's looking good (and it's orders of magnitude better than the situation I found when I joined this company).
So tomorrow is crunch day. I do the final build - the final clean machine install - the final functional test. And then I get to do it all again on a machine that didn't experience clean machine install. I get to run it all on a machine that's being upgraded from our old (random) version, to our new standardised version. All being well I'll be burning our CD of the release mid-afternoon.
Don't imagine that tomorrow is the first time I'm doing this . I've been playing this game way too long to fall for that.
Nevertheless things can go wrong. If they do I'm going to dig my heels in and insist that, even though we're two weeks past the initial release date, we DO NOT release. Sure, we might miss a date by a day or more (added to the two weeks we've already missed). Will our customer forgive a bad release because we stuck to a date that we and they pulled out of our bums? I suspect not.
If nothing goes wrong our customer will recieve, for the first time, a set of professionally labelled CD's. None of this cheap memorex CD-R with the name and version of the software written with a felt tip pen. Ummm well it will be cheap memorex CD-R's but they'll be properly labelled and looking professional. What's more, when they insert em and let Windows auto notification take over they'll get a professional looking web page with release notes and install links.
Let's be fair to management where I work (especially since I'm part of management - much to my surprise). They hadn't thought in terms of the oobe. Oobe? Out of box experience. I'll be the first to admit that much of what I do is based on what I've read about how Microsoft manage their software development process. They do daily builds and visit the wrath of hell on s/he who breaks the build. As shall I. And they obsess about the oobe.
Two nights ago I had to reinstall the kids computer. Because it's the kids computer it is always the one that has the spyware/malware/viruses on it. They neither know nor care that someone out there wants to own their computer. So every so often I get to the point of throwing up my hands and blowing that machine away, reinstalling and the whole works. This time I installed WinXP on it (instead of Win2K). Imagine my surprise when, after the install, I discovered that it had gone out and found our network printer and automatically set it as the default. This is what I think of as a good oobe experience. It did the right thing.
I'm disposed to like Microsoft (though I don't want to work for them). Our customer is disposed to like us - if we can get it right. I'm disposed toward Microsoft because, despite their flaws, they get most things right. So I come at this whole thing from the point of view of wanting to impress the hell out of MY customer by looking professional AND by getting most of it right. I don't expect to get it 100% right. But if we can, for the first time, deliver them software that works, whatever its imperfections, that's a big step forward.
Wednesday, November 10, 2004
In the 'for what it's worth' category
I've been going over some older code I've written (more than 2 years old) and comparing it with more recent code. In a purely subjective judgement I think much of my recent code is much more OO than previous code.
For example, say I'm writing a class that performs some lengthy operation in a separate thread where there's a need to periodically inform the containing application of progress. The way I used to do it was to add a window handle, and a custom message code to the class and post messages as necessary. In other words, I'd build into the object the assumption of a specific notification method with no easy way to change the behaviour.
These days I do the same thing by calling a virtual function passing the notification message and expect the user of the class to write a derived class that does application specific things with the notification message. Simple and obvious huh? With my 20/20 hindsight yes, but it's taken a while to get there. and I attribute the change to my writing articles for CodeProject. The fact is that when you know your article is going to be picked apart by a ravenous mob of bloodthirsty nit-pickers it concentrates the mind wonderfully!
For example, say I'm writing a class that performs some lengthy operation in a separate thread where there's a need to periodically inform the containing application of progress. The way I used to do it was to add a window handle, and a custom message code to the class and post messages as necessary. In other words, I'd build into the object the assumption of a specific notification method with no easy way to change the behaviour.
These days I do the same thing by calling a virtual function passing the notification message and expect the user of the class to write a derived class that does application specific things with the notification message. Simple and obvious huh? With my 20/20 hindsight yes, but it's taken a while to get there. and I attribute the change to my writing articles for CodeProject. The fact is that when you know your article is going to be picked apart by a ravenous mob of bloodthirsty nit-pickers it concentrates the mind wonderfully!
Saturday, November 06, 2004
You just never know
Yesterday I posted another article on CodeProject[^], about an encryption scheme I wrote 5 or so years ago for an IRC chat client and matching game software. I wrote most of the article a year or more ago but always felt nervous about publishing it. Why? A couple of reasons. The first is that I'm no cryptographer. I've read just enough of the literature on the subject to be completely certain of that . So there was a certain amount of diffidence about putting a simple XOR encryption scheme up for public scrutiny and ridicule. The second reason is that I take considerable pride in my involvement with CodeProject and am proud that most of my articles have high ratings. I wasn't convinced that this latest effort would rate all that well.
It's early days yet but the rating so far amazes me. 4.94/5 with 8 votes.
This brings up a whole bunch of philosophical issues. I've seen writers on CodeProject protest that they don't care what the ratings are. I've even indulged in that high minded sentiment myself at least once. But I don't really believe that. I write articles published on CodeProject because I want to share knowledge and experience but also because I want to show people what a clever bastard I can be . It's also a real pleasure when people write complimentary comments at the end of the article.
Ego? Of course. But why else would anyone other than Albert Schweitzer write 31 articles for no payment? And never underrate the power of constructive ego.
It's early days yet but the rating so far amazes me. 4.94/5 with 8 votes.
This brings up a whole bunch of philosophical issues. I've seen writers on CodeProject protest that they don't care what the ratings are. I've even indulged in that high minded sentiment myself at least once. But I don't really believe that. I write articles published on CodeProject because I want to share knowledge and experience but also because I want to show people what a clever bastard I can be . It's also a real pleasure when people write complimentary comments at the end of the article.
Ego? Of course. But why else would anyone other than Albert Schweitzer write 31 articles for no payment? And never underrate the power of constructive ego.
Subscribe to:
Posts (Atom)
