Some Basic Rules of Development

I've been developing software by myself for the better part of 20 years now, and in a team environment for at least the last 6 years. Here are some of the lessons I've learned along the way. Not all of these are 100% my own ideas, but I can state that I've "taken ownership" of all of them, having been both a developer and a development department manager:

1) A development team should have a single design authority.
The best systems have one member of a team who dominates the design and development and has a clear view of where the system is going. Without this strong focus and lead, many projects throw together a set of conflicting ideas and the system will ultimately stagnate or become extremely difficult to maintain. This person needs to be big on communication and small on ego.

2) Code should be documented, but not overdocumented. Lots of documentation does not equal good design and will not guarantee a good, well designed system. A system can have a good design even with minimal documentation. Especially, keep in mind that the initial set of documentation is for the DEVELOPERS THEMSELVES.

3) Good people build good systems, bad people build bad systems. No amount of processes or documentation will change that, it will only make a relatively small increment in system quality. The overwhelming factor in developing a quality solution is to hire good people. NASA statistics have shown productivity differences of 1000% between their best and worst people.

4) Design for change and flexibility. Things will always change, do not tie your system to rigid principles or business processes that change frequently. Break your system up into its OOP oriented objects and define them as early as possible in the development cycle. Make sure everybody on the team understands what the objects are and what their purpose is, and how they will interact with each other.

5) Don't build a foundation on a sand dune. The first few steps in the project are usually the most critical: the choice of tool, platform, architecture etc. If the wrong choices are made, it can result in a lot of rework and will destroy the motivation of most development teams. If you find early in your process that a decision may have been wrong, be smart enough to change it instead of attempting to "Band-Aid" it into functionality.

6) Keep it simple, don't build in complexity that doesn't need to be there. Don't spend time making the system portable if it doesn't need to be. If you're using SQL 2005 and are going to stick with it, use all the SQL 2005 specific features you like. "Explicit code is easier to understand, which makes the code easier to modify" -- Martin Fowler

7) Use accepted and well-known technology. Niche tools/technologies are expensive, lack support and it can be difficult finding people with the right skills, particularly a couple of years later.

8) Deliver often. A project taking more than 6 months before delivering software will likely fail and the reasons for it being built may not even apply anymore. Delivering often provides good targets for developers and good visibility for the system in question. If you have 3 Alphas and 6 Betas over a short period of time, that's better than no Alphas and one Beta. User feedback is extremely important in being able to be flexible enough to make mid-course corrections.

9) Don't add extra people to a team to try and speed up development. Increasing the size of a team mid project will almost certainly slow development down. A team of 4 to 6 developers is enough for most projects. Large projects should be broken down into small development teams of this size.

10) Use industry-accepted development methods: object-oriented design and modelling, well-structured development process, unit testing, sound documentation, use of version control tools, project management tools.

11) Communicate often within the team. You don't need four different people each creating their own Data Accesss helper class when if they had all sat down and discussed it first, everybody could all be using the same one, with better features.

12) Above all, do be nice to your development team. Developer turnover in the middle of a project can really send expenses through the roof, and morale down the toilet.


Asynchronous Fire and Forget Pattern Redux

Illustrates the use of the Asynchronous "Fire and Forget" Delegate invocation pattern in .NET. Sample console app performs enqueing of 100,000 Sql Server inserts with this pattern in from 2.5 to 5.5 seconds, depending on the machine setup. Complete source code download.

read more | digg story


Build a .NET Windows XP 'Site Changer' Utility

There are several hacks and utilities to enable multiple web sites on Windows XP IIS, but they have nasty side effects. This simple .NET utility just changes the home directory location of the default single site, and has no side effects. Complete source code.

read more | digg story


Unable to install Visual Studio on a 64-bit Operating System

This is a strange one indeed. I got a new laptop (64-bit of course) and put Windows XP Pro x64 on it, Everything is installed perfectly, including VS.NET 2003 Enterprise and VS.NET 2005 Pro.

Now I notice I have ASP.NET debugging issues in VS.NET 2003. So I figure I'll do a reinstall or repair on VS.NET 2003 to see if that takes care of it.

Go to Control Panel, Add/Remove, click on the "Change" button for VS.NET 2003 with the DVD in the drive, get an error dialog. OK, let's just run setup.exe off the DVD, right?

You get:

"Unable to install Visual Studio on a 64-bit Operating System".

DOH! It already installed, right? I'm not going mad or anything. OK, we try running the .MSI directly. It runs OK, starts gathering information, and then it QUITS!

There is very little information on this anywhere. Does anybody have any ideas on this? It's not a big deal for me, VS.NET 2003 runs fine, its just that I get "Unable to Start the Debugger" errors in ASP.NET 1.1, and I"d like to figure out why I cannot reinstall the same product I just successfully installed a week ago, on the same OS and machine, with no changes other than that I put VS.NET 2005 on there afterward. There is only one Product Feedback item on this subject, it is very recent, and no action has been taken yet. If you have this issue, go to Product feedback and VOTE on it, and maybe somebody will get off their ass over there and look at it.

Fortunately, 64-bit is coming of age and you can find drivers now for almost everything. But, apparently, we still need to come up to speed on some 32-bit application compatibility issues!


Binary Serialization To / From String and Encoding

Recently somebody posted on the C# language newsgroup that they couldn't figure out how to convert an object to a string (and the reverse) since all the examples only showed how to write / read to a file.

I chimed in that I thought what the OP really meant was "how to convert a stream to a string" (as in using the BinaryFormatter for serialization), and so I posted the following sample:

Stream to string:

byte[] b = MyMemoryStream.ToArray();
string s = System.Text.Encoding.UTF8.GetString(b);

String to stream:

string s = "whatever";
byte[] b = System.Text.Encoding.UTF8.GetBytes(s);
MemoryStream ms = new MemoryStream(b);

Friend and fellow MVP Jon Skeet, who is pedantic to a fault, responded with this:

"That's a way which is almost guaranteed to lose data. Serialization with BinaryFormatter produces opaque binary data, which may very well not be a valid UTF-8 encoded string.

To convert arbitrary binary data to a string and back, I'd use Convert.ToBase64String and Convert.FromBase64String."

Jon is absolutely correct, and I suspect that many developers are not aware that just by choosing what one would "think" is a broad encoding, that we are guaranteed data integrity. Well, we are not.

The correct way (MSDN documentation links first:)

[MSDN] Convert.ToBase64String:

[MSDN] Convert.FromBase64String:

And, revised code sample:

Stream to string:

byte[] b = MyMemoryStream.ToArray();
string s = Convert.ToBase64String(b);

String to stream:

string s = "whatever";
byte[] b = Convert.FromBase64String(s);
MemoryStream ms = new MemoryStream(b);


World War III and the Lessons Of History

"This is World War III. This idea that we have this one-sided war where the other team gets to plan how to kill us and we get to talk, is nuts." -- Newt Gingrich

While Newt tends to be a little "over the top", sometimes, he's got a point. If we would observe the lessons of history and stand up to bullies early on, instead of engaging in social masturbation (diplomacy) so much, decisive action could have gone a long way toward eliminating a lot of the problems with North Korea and the MIddle East. Iran is clearly behind the Hezbollah attacks from Southern Lebanon and Hezbollah, Iran's little puppet regime, has the same stated goal as does Hamas - the destruction of the State of Israel. It never ceases to amaze me how otherwise intelligent diplomats and leaders of democratic nations fail to understand that you cannot negotiate with somebody who wants to kill you as their primary objective:

Terrorists: We are going to kill you. Death to XXX!
Country: Look, let's negotiate.
Terrorists: You will die, infidel! And I will go to heaven and meet Allah!
Country: Come on, let's sit down and talk about some incentives.
Terrorists: BLAM! BOOM! (Smoke....)

This leaves pretty few options, doesn't it? Yet, we're still carrying on the conversation, as if it really has a chance of going somewhere. It doesn't.

I talked about this Iran thing six months ago in another post here. My opinion hasn't changed, in fact it has hardened considerably. I also warned about $4.00 gallon gas this summer back in April.

The way you stand up to a bully, once again, is that you cannot negotiate with or appease them. To put it in the vernacular, you cut their nuts off and neutralize them permanently so that they can no longer be a threat. The sooner you do it, the better - because this interminable waiting and delusional playing of the appeasement game simply gives them that much more time to consolidate power and become ever more dangerous.

It's not about the rules of engagement. It's not about the Geneva Conventions. It's not about what is morally right or who started it, or who is right and who is wrong, you idiots! What it is about is learning the lessons of history and having the guts to take care of business!

This is precisely what happened with Hitler prior to World War II. U.S. tried to stay out of it and finally had no choice but to declare war. Great Britain, our closest ally, was nearly obliterated because we took so long to "get the message". Had we jumped in earlier, we could have neutralized Hitler (and possibly the Japanese) and six million Jews, 20 million Russians, and countless hundreds of thousands of American and European lives could have been spared. And, it looks to me that we haven't yet learned the lesson.

Gingrich says the reluctance to put all the pieces together and see one global conflict is hurting America's interests. He says people, including some in the Bush Administration, who urge a restrained response from Israel are wrong "because they haven't crossed the bridge of realizing this is a war."

An historian, Gingrich said he has been studying recently how Abraham Lincoln talked to Americans about the Civil War, and what turned out to be a much longer and deadlier war than Lincoln expected. In other words, he thinks that the President isn't presenting the real conflict to the Congress and to Americans by "connecting all the dots".

This is an American issue, we are in the middle of it and it's up to us to have the balls to take care of business. Because if we don't it is going to hurt us a lot more later. Think about it: We are flying men into space to a space station, and meanwhile, back here on earth, people are killing each other over a bunch of land. America has the ability to put a stop to it, but it appears that it doesn't have the guts it takes to do so.


Sets of "101 Code Samples" For Visual Studio.Net And SQL Server

This details links to some of the better code samples for Visual Studio.NET (2003 and also 2005) as well as SQL Server 2005. While targeted at beginners, even expert programmers will find these useful.

read more | digg story


Logical Fallacy, and Code Monkey.

If you follow any discussion topic or newsgroup thread where a debate of sorts ensues, you are just as likely to see examples of logical fallacy.

Wikipedia has a pretty good write-up on it here.

The most common examples, and a few short illustrations:

  • Ad baculum

  • Ad hominem

  • Affirming the consequent

  • Appeal to authority

  • Appeal to fear

  • Appeal to pity

  • Appeal to tradition

  • Appeal to probability

  • Appeal to the majority

  • Argument from ignorance

  • Begging the question

  • Biased sample

  • Correlation implies causation

  • Equivocation

  • Hasty generalization

  • Post hoc ergo propter hoc

  • Straw man

Ad baculum:
If x does not accept that P, then Q.
Q is a threat or attack on x.
Therefore, P is true.
In other words, "This is right because if you do not believe it, you will be beaten up."

Ad hominem:

A (fallacious) ad hominem argument has the basic form:
A makes claim X.
There is something objectionable about A.
Therefore claim X is false.

"Only right-wing nutjobs believe that homosexuals account for one to two percent of the population."

Affirming the consequent:
This fallacy has the following argument form:
If P, then Q.
Therefore, P.

If someone is human (P), then she is mortal (Q).
Anna is mortal (Q).
Therefore Anna is human (P).
But in fact Anna can be a cat; very much a mortal, but not a human one.

Appeal to authority:

A (fallacious) appeal to authority argument has the basic form:
A makes claim B;
there is something positive about A,
therefore claim B is true.

"The Bible says 'Thou shalt not lie with mankind, as with womankind: it is abomination. -- Leviticus 18:22' , therefore homosexuality should be condemned."

They go on, you can read up on this at Wikipedia. The more familiar you are with these forms, the better off you will be, as there are a lot of very uninformed souls who like to prognosticate and have their utterances accepted as truth in life.

Confucius said, "Real knowledge is to know the extent of one's ignorance."

Now, if none of the above interests you, and you are still a programmer -type, then you might like listening to Jonathan Coulton's Code Monkey. Not a bad tune, for being 100% self-produced from his apartment in Brooklyn (though I prefer Bach, and just finished listening to Rimsky-Korsakoff's Scheherazade today).


Who says Game Developers don't use .NET?

Recently I took my kid to a local bowling alley that has a nice game room where he likes to play racing car type-videogames. The first pic below, which I snapped with my camera phone, shows the front of "Need for Speed Underground" by EA. But, what's that whitish looking thing in the middle of the screen?

Well, as can be seen in the following close-up, it's the Common Language Runtime Debugging Services dialog for an unhandled exception!

Looks like our EA lead developer didn't finish his last debugging session, heh? Of course, I must admit this is somewhat familiar -- where I work, the QA Department consists of "push it into production"!

Kudos to EA for some cool game programming with .NET and DirectX. But - BADDD on the developer who didn't put in an unhandled exception logger that would restart the app and let the poor user who just dropped three quarters in there get a free game... the high road is "oops - we screwed up - the next game is free." Let's take the high road, guys - it's those kids' quarters that are paying your salary, no? (not to mention the fact that Dad was the guy who just funded your little unhandled exception experiment!)

Team Development Note:

If you are an ASP.NET developer who works in a team environment, I'd highly recommend Omar Khan's Blog post (with screen caps) of how to create sub-projects in IIS with the Web Application Project feature of Visual Studio 2005. Omar is a master presenter with a very outgoing personality and great communications skills, and those skills shine in this first of a series. View it here!.


Loss of Keyboard functionality in Visual Studio 2005 -- and a FIX!

Its funny but last night I installed IE 7, BETA 3 on my AMD x64 system running Windows Enterprise Server 2003 x64 Edition and just this morning I noticed an issue that had been reported back during BETA 2 of Visual Studio 2005 - all of a sudden in a Web Application project, the enter key, the F11 key (continue step through breakpoint), backspace and a couple others quit working. CTRL-V (Paste) and CTRL-C (Copy) etc. also don't work.

This has been described by Developers as "The Haunted Keyboard" bug, and was supposedly fixed after BETA 2. The only problem is, I'm getting to see the re-runs.

[NOTE: There is a FIX for this at the bottom of this post]

In fact, at first I thought it was my keyboard because it has a short cord and I've got it snaked behind the monitor, over the back of my desk, and then back up front under the desk to plug in the back of the CPU on the floor, and several times I"ve booted up in the past with no keyboard (probably from pulling on the stretched cord). So I went out and picked up a nice Microsoft USB keyboard and extender cord so there is no tension on the cord at all now.

But even after switching back to the original "supposedly broken" keyboard, I still have the same issues. Now - outside of Visual Studio 2005, both keyboards work great. I checked the Product Feedback Site on this and there are a whole group of issues along these lines, but they all seem to be fairly old. I'm posting this in the hopes that somebody else notices this and can definitively state that it's not "just a fluke" but a real issue that should be reported.

Incidentally, this issue has cropped up numerous times before- its been reported by Scott Hanselman, and Sean Laberee reports it - along with a fix - on his blog. Unfortunately, all the "fixes" don't work for me, yet...

NOTE: 7/6/2006: This is now FIXED. Thanks to the "What I Learnt at Work Today" MSDN blog.


The key to the fix is simple, and twofold:

  • Delete the contents of C:\Documents and Settings\<* user *>\Application Data\Microsoft\VisualStudio\8.0

  • In VS2005, go to the Tools -> Import and Export settings... menu and Reset all settings

That's it! Don't ask me "why" this happens. Obviously, it probably has little to do with Internet Explorer-any version. Somehow the application configuration data in that folder is either getting corrupted, or the settings contain something that was never caught during the development cycle for Visual Studio.NET 2005. I just wish the communications in terms of having potential fixes or workarounds was better - will all the information found by anybody in one central place so developers and users can look it up. The product feedback site is a good start (yes, I *did* put the workaround in there), but not everybody uses it.