Saturday, January 27, 2007

My Professional Articles To Date

Last month I received a request for a compendium of all of my professional articles to date, so this seems as good a place as any to list them. I'm not sure if I should update this post when a new article comes out or if I should just repost everything so it's all in once place, but I'm open to comments or suggestions. Anyway here goes. The list is chronological.

Seven Signs

Publisher:, a popular project management portal, readership 1.5 million project managers a month

Date: 11/2006

Abstract: Headed for trouble? Here are some ways out of the mess. This article will revisit seven of the most common causes for project failure, consider their solutions and provide some techniques you might have missed such as developing an ERD from Day One, and driving the user interface based on the structure of your data.

Nine ASP.Net Site Navigation Problems and Solutions Part 2

Date: 8/2006

Publisher:, a popular software development portal, readership 1.2 Million developers a month

Abstract: Discover how to grant or deny users access to pages in your sites, automatically reflect that in your navigation, and how to create dynamic site maps using database-driven data. The article covers extending ASP.Net 2.0's provider model and using the SqlCacheDependency to have SQL Server 2005 notify your application when data changes.

Nine ASP.Net Site Navigation Problems and Solutions Part 1

Date: 7/2006


Abstract: Find out how to use ASP.NET 2.0's site navigation controls to not only make building site navigation displays simple, but also solve real-world problems, such as hiding selected pages, or displaying "breadcrumbs."

Hierarchical Data and Nested DataGrids

Date: 5/2006


Abstract: Learn how to use nested DataGrids to display hierarchical data and avoid the maintenance nightmare of dynamically-created HTML tables.

Cracking the Code

Date: 10/2005


Abstract: Developers have been slow to adopt it, but code generation is coming into its own. This article will examine improvements which make this technology a better bet than ever before and discuss which projects can benefit most from code generation.

Rapid Application Development

Date: 10/2005

Publisher:, readership 130,000 subscribers

Note: Since requires a login you might as well just read it on the Blue Ink website at

Abstract: Rapid Application Development is a software development methodology that involves iterative development cycles, the construction of prototypes, and the use of CASE Tools.

Parameter passing in C#

So there I was, merrily browsing the Internet when I came across this fantastic site on topics such as:
  • Implementing a singleton pattern in C#,
  • Type initializers,
  • Static constructors,
  • Delegates and events,
  • And as my title suggests: Parameter passing in C#.
In short, all those things you rarely need to know to get your job done, but that separate mediocre developers from good ones. The site is by Jon Skeet and the articles are informative, well researched, well explained, well written. Here's the C# part of his site:

The article that caught my attention made sense to me, but being a very visual person I couldn't help but think that some pictures could really help illustrate the points. So without further ado, I illustrated the article. You probably don't need to read the article to understand this post - but you should:

Note: you can click the images to get a clearer view.

1. Value Types

Notice that the values live inside the box which will not be the case for reference types. Also, the assignment operation copies the value inside of the box, this is important to compare with reference types.

Quiz: What is the result of the WriteLine statement?
Answer: 5

2. Reference Types

Variables that hold reference types actually hold a reference to a location in memory (on the heap). So assignment operations copy the address. Notice this is still consistent with diagram #1, the copy operation copies the value inside of the box.

Quiz: What is the result of the WriteLine statement?
Answer: hello world

3. Immutable Reference Types

Immutable reference types like strings behave just like regular reference types except they don't provide a way to change their value.

Quiz: What is the result of the WriteLine statement?
Answer: hello

4. Value Types Passed by Value

Passing a variable to a function by value is equivilant to instantiating a new variable and assigning it to the first (well, ignoring scope issues and such). Notice that the diagram below is nearly identical to diagram #1.

Quiz: What is the result of the WriteLine statement?
Answer: 5, same as #1

5. Reference Types Passed by Value

In #4 I said passing a variable to a function by value is equivilant to instantiating a new variable and assigning it to the first. Is that still true of reference types? Yup. And did you notice there's an implicit assignment statement when passing by value? As you'll see shortly there won't be when passing by reference.

Quiz: What is the result of the WriteLine statement?
Answer: hello world

6. Value Types Passed by Reference

Passing by reference doesn't involve an implicity copy, instead it instantiates the inner variable to the address in memory of the outer variable. Then all references to the inner variable are implicitly dereferenced for you and voila, magically you're changing the value of the outer variable.

Quiz: What is the result of the WriteLine statement?
Answer: 10, and notice how different the diagram and results are than #1 and #4.

7. Reference Types Passed by Reference

Really this is no different than value types passed by reference (#6), except calling sb.Append() from an inner variable is dereferenced once to get to the outer variable and again because the outer variable is itself a pointer.

By the way, when you get to the section in Jon's article called:

"Sidenote: what is the difference between passing a value object by reference and a reference object by value?"

Please read it carefully, it's an extremely good point. It can be sumed up by comparing the final assignment statement above (Reference Types Passed by Reference) to the final assignment statement in in diagram #5 (Reference Types Passed by Value). It's a subtle, but important difference.

Oh and the quiz, what is the value of the Console.WriteLine in #7?
Answer: NullReferenceExceptinon – Object reference not set to an instance of an object

Still confused? Then I didn't do my job right, since this is the point in the article when I thought pictures would help. So please post your thoughts whether it makes sense or not.

Update: February 19, 2015
If you like this article check out An illustrated Gude to Parameter Passing in JavaScript. I demonstrated the same diagram style and examples, but for JavaScript.

The Importance of a Logical Data Model

As this is my first post I wanted to start with an explanation of the theme of this blog. The title: Rapid Application Development, refers to the software development methodology started by James Martin in the 1980's, not to some vague marketing concept as the term is more frequently used (for details see my article:

My specific spin will be designing, architecting, and implementing Microsoft .Net n-tier web applications since that is my career and my passion. That's the idea anyway, let's see how it looks after more than one post. ;)

Appropriately I wanted to start with with a discussion of the importance of developing a Logical Data Model, which should represent a vital step in the building of all software development projects, and is a core part of the rapid application development methodology.

Previously I'd thought logical data models were a crutch for people who were unable to model physically. I mean, why use some rough approximation of a real data model when you could use Micorosft Visio to develop something that will actually turn into a real database in order to start your actual software development?

Recently, however, I've had the pleasure of working with Steve Dempsey, a man who worked with James Martin and knows the RAD process inside and out. More specifically he is someone who believes a project will not suceed without a logical data model.

The more we've discussed our differences of opinion, the more I've come to concede my point. It hit home for me when I considered a recent project where using it would have drastically shortened the length of the project.

It comes down to how you apply the logical data model. For instance it's not just a starting point for the database, think of it as a starting point for the object's in an object oriented world as well. The strength of the logical data model is realized for instance when you build UML sequence diagrams based on the entities in your entity relationship diagram - and more specifically when that doesn't mirror your actual database structure!

My recent project used objects that didn't mirror the logical data model and the consiquence was non-intuitive code, a degredation of maintainability, and designing in complexities that could have been avoided.

Conclusion? Logical data models rock. Use them. They're not a crutch, they're a launching point for development.

And in case you're visually oriented consider the contrived example below where employees are denormalized into their company in the physical model, but are used in the logical model and sequence diagram (click the image to enlarge):

If this thought make sense then this is a BLOG is for you. Not sure? Please comment. I will post more concrete how-to's, .Net code samples, my favorite web resources, and undoubtedly random thoughts that may still interest you ... some other day.

- Lee