The size of an identifier cannot exceed 30 characters.

–from Oracle’sPL/SQL User’s Guide and Reference: 10g Release 1 (10.1)

June 3, 2010

Gerald Weinberg
c/o Dorset House Publishing Co.
3143 Broadway, Suite 2B
New York, New York 10027 USA

Dear Mr. Weinberg,

As a computer programmer of thirteen years, I have read and benefited from your writing – specifically, Exploring Requirements and Are Your Lights On? Thank you for working to understand what’s wrong with how the people within software development organizations think and articulating what needs to change and how. Your work has made a difference to me.

I went to your website this morning and saw that you have had a battle with cancer. Recently you were declared cancer-free — praise God for that!

Mr. Weinberg, you have had a brush with death, and because I love you I need to warn you of the Day of Judgment that we all will face. On that day, what will you say to the King?

I do not know the state of your soul before God, but I implore you, please do not deny the existence of the King. God who made the heavens and the earth and gave you every breath you’ve ever taken rules in righteouness, and he will call you to account one day. All have sinned and fall short of the glory of God. Only those who repent and believe in Jesus Christ will be saved.

Oh Mr. Weinberg, repent and be saved!

Sincerely and with love,
Daniel S. Meyer

I don’t have a mailing address for Mr. Weinberg, and I don’t know if his publisher will forward it on to him. Even if they do, how likely is Mr. Weinberg to repent? Am I not a fool for doing such a thing — not to mention for advertising it here? Where is my respectability?

Brothers who are in Christ: souls are at stake. Fool or no, I care about Mr. Weinberg’s soul. On Judgment Day I want to be able to look in the eyes of all, knowing I was faithful to warn.  And may God grant repentance to those He has chosen!

But is our decisionmaking driven by cool reason?  Yes, we say — by cool reason.

What about when we communicate our evaluation of a Microsoft tool to co-workers?  Cool reason?

Not usually.

The fact is, many of the decisions we make as developers are made based on emotional arguments couched in technical terminology.  Reading a post by Jerry Weinberg several months back brought on an Aha! moment that changed my thinking about us developers.

From Mr. Weinberg’s post titled Reasons, then:

…
Recently, I found myself recalling that summer day, half-a-century ago, when a client asked me to find out why their Software Engineering Process Group was having so much trouble getting people to adopt new software tools. It couldn’t be the tools themselves, they reasoned, because quite a few people had adopted them and liked them. So, I set out to interview both adopters and rejecters, to discover the reasons some were using the tools and some were not. Here are some of the answers I obtained:

Darlene: I installed it because the boss told me to use it.

Porter: The boss told me to use it, so I didn’t use it.

Ursula: I installed it because the boss forced me to use it.

Marcy: The boss forced me to use it, so I installed it, but I don’t use it. He wouldn’t know the difference.

Quentin: I used it because it was like what I used before, so I knew I wouldn’t have any trouble adapting to it.

Chuck: Why should I use it? It’s nothing new; it’s just like what I used before.

Carl: Hey, I used it right away, because it was new and different.

Cynthia: I’m not going to use anything that’s new and different. Too many things aren’t tested, and something’s sure to go wrong.

Mary: Of course I used it. Everyone else was using it.

Roy: Everyone else was using it – what a bore! You won’t catch me following the crowd.

Frances: Why should I use it? Nobody else was.

Edgar: Hey, I got to be the first one to use it!

Mort: I couldn’t use it. It didn’t do all the things I needed.

Alan: The thing I liked best about this tool was that it didn’t try to be a Swiss army knife and do everything anyone could possibly want.

Gerri: It was the perfect tool, because it had every feature I could possibly want.

Chico: Every time I hit a key by accident, it would invoke some obscure feature that I didn’t want in there in the first place. Finally, I trashed the whole thing.

Orion: I’m so busy, I needed a new tool to save me some time.

Belle: I’m so busy, I don’t have time to install and learn a new tool.

May: I’m not that heavily loaded. Why would I need a time-saving tool?

Paul: Well, I wasn’t so busy with other things, so I had time to install and learn a new tool.

Earl: It was freeware, so it was a bargain.

Justine: It was shareware, so it couldn’t have been any good.

Jacob: This tool costs $3,000. It must be good, so I’m using it.

Neelie: I’m saving the company $3,000 by not using it.

Willis: I won’t use it because I don’t like the way Microsoft makes software.

Samuel: I knew it would be good because Microsoft makes it.

—–

Well, there were more, many more, but that’s enough of the infinite reasons to make my point. By this time, you may have noticed that I have arranged these reasons in pairs. Why? So you could see the pattern that I saw:

Every single reason to use the tool was matched by the same reason for not using it – and vice versa!

In other words, these reasons may look like logic, but they’re not logic – they’re just reasons. In logic, the reasoning comes first, then comes the decision. But in real life, it’s usually the other way around – first we make the decision, then we make up whatever reasons we need to “justify” the decision and make it look like logic…

Going back to the Microsoft example again, when the Microsoft tool blows up, do we have cursings at the ready?  If so, would we have had similar cursings at the ready if it had been our favorite open source tool that blew up?  If not, why not?  Are we of a mind to be understanding toward our open source tool and impatient with our Microsoft tool?  (The question has the same implications if we reverse the inclinations — positing a tendency for patience toward the Microsoft tool and impatience toward the open source tool.)

What I have described is not a logical argument about a tool.  It is an emotional argument about a company.  Perhaps there is an argument to be made against the company (“Where possible I  do not support Microsoft because of its history of corrupt business practices regarding smaller innovators in the market” would be an example of a moral argument.)  Cloaking such a moral argument as a technical argument against a particular tool, however, is not honest.  As developers, we don’t even realize we’re doing this, but we need to realize it.  It’s part of being a professional.

Read Weinberg’s whole article.

We can do things our family members and friends can’t do. We can take lifeless bits, wave our hands, and make the code live! We have logic. We have design and problem solving skills. We have honed our technical prowess.

All this is good — but there is a problem: We imagine that we live in a larger world than the non-technical people around us. Brothers, let us not be deceived: our world is a smaller world.

What do I mean?

Our technical expertise does not help us prolong the life of our sick child — we thank God for the doctors and pray for grace.

Our design skills do not give us boldness to warn those who do not love Jesus of the judgment they face if they do not repent.

Our logic does not teach us how to live with our wives as with a weaker vessel, leading with honor, gentleness, and strength.

Our ability to do what others can’t do does not confer on us a special ability to honor our father and our mother as we know we ought.

These are matters of eternal import where we are no better than anyone else — and often worse!

Brothers, in our daily work we’re living in a virtual machine.

Yes, let’s continue to work to solve problems, to help people with our software, to work as unto the Lord — but let’s never forget that the rules are simpler inside this machine. The hard problems are out there. We don’t know how to solve those problems. Sometimes we don’t even try to deal with those problems — we hide inside our virtual machine, where the universe is smaller and the rules are better defined.

It’s not wrong for us to do our technical work. But we should be the humble ones, not the proud ones. Brothers, let us remember this.

It’s at these times that I get the nagging feeling — the test was so time-intensive to create and run, why not take the step of automating it so we can run it in the future and catch regressions ‘most instantly?

I wanted an SQL script that I could run that would INSERT the test data as it currently existed on my test machine.  And I didn’t want to create those INSERT statements by hand.  Boy, did I not want to write them all by hand.

Solution

Microsoft SQL Server 2005 comes with something called Database Publishing Wizard (look under Program Files\Microsoft SQL Server\90\Tools\Publishing\1.2\ ).  With the following command:

sqlpubwiz script -d MyDatabase -dataonly c:\temp\MyDatabase.sql

…I was able to generate INSERT statements for all the data in my little test database to an .sql script file.  I then edited the file to remove things I didn’t need (and to avoid key collisions by substituting NEWID() calls for hardcoded uniqueidentifiers as necessary).

Finally, with all the data in place, I could add the following tests. (If anything goes wrong, an error message appears in the Messages window.)

DECLARE @tempTable TABLE(BlahId      uniqueidentifier,
                         BlahType        int,
                         BlahDateUTC DateTime,
                         BlahLength  int,
                         PhoneNumber      nvarchar(60),
                         RightsMask       int);

DECLARE	@return_value int;
INSERT INTO @tempTable
EXEC	@return_value = [dbo].[blah_get_blah_chunk]
		@i_sessionId = @sessionId,
		@i_chunkSize = 50;

IF @return_value <> 0 RAISERROR('Return value should be zero but was %d', 15, 1, @return_value);

DECLARE @expectedRecords int;
DECLARE @actualRecords int;
SET @expectedRecords = 5;
SET @actualRecords = (SELECT COUNT(*) FROM @tempTable);
IF @actualRecords <> @expectedRecords RAISERROR('Expected %d records in result set but found %d', 15, 1, @expectedRecords, @actualRecords);

DECLARE @actualDisplayName nvarchar(60);
DECLARE @expectedDisplayName nvarchar(60);
SET @expectedDisplayName = N'blah_user -';
SELECT @actualDisplayName = (SELECT LocalPartyName FROM @tempTable WHERE RecordingId = N'a0ca1a4f-0933-4565-b5da-d8fc3222a42a');
IF @actualDisplayName <> @expectedDisplayName RAISERROR('Expected display name to be "%s" but it was "%s"', 15, 1, @expectedDisplayName, @actualDisplayName);

GO

In the future we could have a script test runner that keeps track of the output and flags errors as part of the build… but one step at a time, right? This already takes test scenarios that took more than a day to set up and makes them runnable in a minute or two.

Database Publishing Wizard can also generate script to create the entire database schema, but it’s the data generation that will support my unit test needs.

Thanks, Microsoft!

Acknowledgement

Thanks to Pinalkumar Dave for his helpful write-up titled Generate Script with Data from Database – Database Publishing Wizard

N MSI (s) (98:F8) [16:53:58:645]: Hello, I'm your 32bit Impersonated custom action server.

Glad to meet you, sir!

We use virtual machines for a lot of our testing — you just clone a VMWare LabManager image, deploy it, and off you go.  You can do whatever you want to the configuration, because when you’re done you just undeploy and delete the workspace.  It’s really nice.

The “clone a LabManager image” step works because someone regularly takes one of the nightlyish builds and installs it to a VM, creating an image suitable for others to clone.

For less generally applicable needs, such as builds of the team branch I’m working in, an image is not always available, but we can take the main branch and apply transformations to it to update it to the team branch.

And now we’ve arrived at the topic of this post.  One of the tranformations I commonly find myself needing to apply is a database schema update.

I can copy the SQL Server update scripts to the VM and run MS SQL Server Management Studio on the VM.  This is ok, but it requires that I Remote Desktop in to the VM, establish access to the VM’s file shares, and copy files from two different directories… and SQL Server Management Studio is sluggish on the VM.

I would prefer to run SQL Server Management Studio on my local PC, connecting to the VM… but the user account doesn’t have permissions to alter columns or create or drop tables.  Do I have to use Remote Desktop after all?

No, it’s a simple setup issue.

Solution

Edit the properties of your user in MS SQL Server Management Studio under Security->Logins (you might need to get on the VM to do this) and add the sysadmin server role to your user.  Now you can create and drop tables, alter columns, etc. from a remote SQL Server Management Studio connection.

When I ran a query on the database using MS SQL Server (2005) Management Studio, the row that should have looked like this

instead looked like question marks:

??????

Is it just my glasses?

My reaction in a situation like this is: “Is it really foggy out, or is it just my glasses?”  Either the data was being stored incorrectly in the database or I was simply having trouble viewing it.

Answers

Here is a dump of the things I learned:

• The question marks indicate that the data was really not stored correctly (data loss).
• If instead, your query results appear as square boxes (▯▯▯▯▯▯), your PC just does not have the language pack installed to view the characters.  On Windows XP, go to Control Panel -> Regional and Language Options and check the Install files for East Asian languages checkbox.
• One possible cause of your data turning to question marks is if you insert a literal unicode string but do not use the N prefix (e.g., N‘myunicodestring’).  Setting it as just ‘myunicodestring’ can cause non-Latin characters to go to question marks.
• Another cause is if your column is not of a unicode type.  For instance, on SQL Server, you would want to use one of the n- character column types such as nvarchar(x).

There’s a system set up in Japanese that I’m testing on.

I’m not used to feeling so disoriented using a program.  It’s not like a screen in Spanish, where I can understand some of it and guess my way around… the Japanese characters mean nothing to me:

Uhh, hmm… interesting to have the perspective of a non-native speaker.  What can help me?  How can I do anything? (I even know this application reasonably well in English, but the foreignness of the language is overwhelming, immobilizing.)

As I visually scanned the screen for anything that would help me find my way, I found myself focusing on the icons (which I had barely noticed in the English version) and on the arabic numbers.  “Ah yes,” I remembered –  the magnifying glass signifies a search, and “検索 1″ probably means “New Search 1″.

I created a new search and added an attribute to it, and once again the icons were most helpful (otherwise I would have had little hope of knowing what kind of search attribute I was adding):

So what’s the lesson in this?  One is that it’s really helpful to know the language!  But I think my takeaway is an increased identification with and compassion for those using a system who for whatever reason may not understand the language, or not understand it well.  I want the systems I design to not forget that person — and give them a little help when I can.

Now that’s talking my language.

These guys might just get my business.  :)