October 2008 - Posts

November's Toolbox Column Now Online
29 October 08 07:44 PM | Scott Mitchell

My Toolbox column in the November 2008 issue of MSDN Magazine is avaiable online. The November issue examines:

  • DayPilot - DayPilot is an AJAX-enabled calendar and scheduling ASP.NET Web control that offers functionality not unlike what you find in Outlook and other desktop-based calendar applications. Plus there's a free, open-source Lite version.
  • Blogs of Note - Jeff Smith - Jeff's blog contains great posts on T-SQL syntax, queries, and tips and tricks for getting the most out of Microsoft SQL Server.
  • RegexBuddy - with its terse syntax and mix of special characters, regular expressions are usually hard to read, understand, and enhance when using the naked eye. However, with a tool like RegexBuddy, regular expressions are much easier to grok. RegexBuddy is a desktop application with features that assist in building, testing, and editing regular expressions. RegexBuddy includes a regular expression debugger and wizards for turning your regular expressions into C# or VB code.

For The Bookshelf section I reviewed The Productive Programmer, by Neal Ford. An excerpt from the review follows:

In the Productive Programmer (O'Reilly, 2008), Neal Ford shares proven techniques that will help any developer improve his or her productivity. The first part of the book explores behaviors and tools for boosting developer productivity; the second part looks at software development practices that help contribute to a more streamlined development process. He espouses the Don't Repeat Yourself tenet for improving productivity and provides examples of how to avoid needless repetition in areas from version control to technical documentation. Poor software development practices can quickly swallow up those productivity gains, Neal notes. Adding unnecessary features, insufficiently testing your code, and failing to correctly encapsulate your objects are all practices that lead to bugs and unmaintainable code. The willingness to question the status quo is another important aspect in developer productivity. Too often developers get into a rut and use a particular design pattern or coding technique because that's the way it's always been done, overlooking or turning down alternatives that may be more efficient.

Enjoy! - http://msdn.microsoft.com/en-us/magazine/dd148647.aspx

As always, if you have any suggestions for products, blogs, or books to review for the Toolbox column, please send them to toolsmm@microsoft.com.

Visual Studio's Property Window Not Refreshing in the Designer
28 October 08 07:50 AM | Scott Mitchell

Rick Strahl recently posted about some his frustrations with the Visual Studio 2008 Designer - HTML Mangling with Literal Controls in the <head>. While I've not had Visual Studio mangle my pages' markup when switching between the Design and Source views like Rich has, I have had one especially nagging issue since Visual Studio 2005: when I'm in the Designer and I select a control on the page very often the properties for the selected control are not loaded in the Properties window. This problem has been particularly accute in Visual Studio 2008. Does this happen to anyone else?

Here are things I resort to when this behavior starts:

  • Say au revoir to the Designer and do your development from the Source view. This is fine if you are comfortable with HTML and Web control and data binding markup, but this option is less palatable if you are training or teaching a class or helping a coworker who is most familiar with the Designer.
  • Try loading the properties by selecting another control on the page and then re-selecting the initial control whose properties I wanted to view. Sometimes this works.
  • Right-click on the control and select Properties from the context menu. This technique worked 100% of the time in Visual Studio 2005 but rarely works for me in 2008.
  • Selecting a control in the declarative markup seems to 'wake up' the Properties window. To load a control's properties, then, go to Split view, click up in the declarative markup to 'wake up' the Properties window and then select the control from the Designer.

This Designer behavior is especially frustrating when teaching a class. Each quarter I teach a class that introduces ASP.NET to students and it's a triffle embarassing to be standing at the front of the class showing them how to perform a certain task and fighting with Visual Studio's Designer to get a control's properties loaded in the Properties window.

It could be worse, I guess. I have one client who uses Visual Studio 2005 and he cannot set controls' ID properties from the Designer. If he adds a TextBox Web control to the page from the Designer its properties load in the Properties window and the ID displays as TextBox1. Now, if he goes to the Properties window and types in, FirstName, for instance, the Properties window shows FirstName but once he clicks off that control and returns to it the ID value has reverted to TextBox1. The only way he can change a control's ID property is to go to the Source view and change it from the declarative markup.

Filed under:
October's Toolbox Column Online
13 October 08 10:28 AM | Scott Mitchell

My Toolbox column in the October 2008 issue of MSDN Magazine is avaiable online. The October issue examines:

  • SQL Data Generator - Quickly generate unbounded amounts of real-world test data for your database with a few points and clicks of the mouse.
  • Blogs of Note - Dare Obasanjo - Dare is a Program Manager at Microsoft and writes about social networks and the transport and data exchange standards common used in such sites. Dare is also the creator of RssBandit, a popular (and free) desktop-based RSS reader.
  • Displaying Color-Coded Syntax in a Web Page - There are a bevy of tools that you can use to format source code into lively markup on a web page. I look at three:
    • Quick Highlighter, a web-based tool where you enter code into a textbox and the page generates corresponding HTML and CSS.
    • CopySourceAsHtml, a Visual Studio Add-In that lets you select code (or markup) from Visual Studio and right-click and copy the source code to HTML and CSS markup for display.
    • squishySyntaxHighlighter (which appears to be offline right now), which is a .NET component for programmatically converting a string of Visual Basic or C# code into display markup.

For The Bookshelf section I reviewed ADO.NET 3.5 Cookbook, by Bill Hamilton. An excerpt from the review follows:

When I write or maintain ADO.NET code, I like to keep a copy of Bill Hamilton's book ADO.NET 3.5 Cookbook (O'Reilly, 2008) within arm's reach. ADO.NET 3.5 Cookbook offers more than 200 recipes for common ADO.NET problems—everything from where to store database connection strings to how to execute a SQL statement asynchronously. When I get stuck trying to recall how to perform a certain action, I reach for this book, flip to the Table of Contents, find the recipe, and am off and running. Each recipe starts with a problem statement, such as: "You want to access an output parameter returned by a stored procedure." Next is the solution, and then the discussion. This problem/solution/discussion format results in self-contained recipes that are easy to understand.

Enjoy! - http://msdn.microsoft.com/en-us/magazine/cc947918.aspx

As always, if you have any suggestions for products, blogs, or books to review for the Toolbox column, please send them to toolsmm@microsoft.com.

Filed under:
OUTPUTing Data from the Just-Inserted, Updated, or Deleted Row(s)
11 October 08 12:00 PM | Scott Mitchell

Between work and diaper changes I've been reading Michael Coles's book Pro T-SQL 2008 Programmer's Guide, and found this little gem (pg. 527-528):

The OUTPUT Clause
You can use the OUTPUT clause with the the INSERT, UPDATE, DELETE and MERGE DML statements. ... The OUTPUT clause returns information about the rows affected by the DML statements that can be useful in comparing preupdate and postupdate data, or for troubleshooting and logging purposes. ... You can use the OUTPUT clause to output a SQL result set like that returned by a SELECT statement, or you can combine OUTPUT with the INTO clause to output rows to a table or a table variable.

This feature is supported in T-SQL 2008, but was initially added to Microsoft SQL Server 2005. And here it is three years later and I'm just learning about it!

One use of the OUTPUT clause is to grab the just-inserted IDENTITY column value:

INSERT INTO TableName(ColumnList)
OUTPUT inserted.IdentityColumnName
VALUES(Values)

The above will return the just-inserted IDENTITY value as a result set, just as if you had followed an OUTPUT-less INSERT statement with the statement:

SELECT SCOPE_IDENTITY()

You could use the OUTPUT statement to return information about the rows affected by an UPDATE. For example, in these tough economic times you might need to increase prices by 20% for all products that cost less than $10.00. The following statement performs the described update and returns those products whose prices were increased, showing both their old price and their new price:

UPDATE Products SET
Price = Price * 1.20
OUTPUT inserted.ProductID, deleted.Price AS OldPrice, inserted.Price AS NewPrice
WHERE Price < 10.00

This UPDATE statement will modify the data and return a three-column result set with a row for each modified product along with its preupdate price (deleted.Price) and its post-update price (inserted.Price).

Pretty neat, eh?

In fact, You can string these DML statements together, so you do an UPDATE with an OUTPUT whose results are then automatically INSERTed into another table (such as an audit table). The OUTPUT statement feels like in-place triggers (kind of like how Common Table Expressions are akin to in-place views).

I'll have to write an article on the OUTPUT statement on 4Guys one of these days...

Further Reading....

Filed under:
Going Independent: When Do You Bill Your Clients and What Are The Payment Terms?
09 October 08 08:11 PM | Scott Mitchell

A decision all independent software developers must make early on in their career is when to bill a client and under what terms. This decision, of course, is not the developer's alone to make - it must be discussed and agreed upon by the client, as well. Similarly, a developer must decide how to charge: by hour or by project. Over the years I have received numerous e-mails from fellow developers who are contemplating striking it out on their own, and wonder what suggestions or advice I have for billing.

My general policy is as follows:

Software Development:
For software development I charge per hour. I have never taken on a client and billed per project, and likely never will. My primary concern with billing per project is that my estimation or the client's estimation may be off base, which hurts one of us. Also, when billing by the hour there is no concern about scope creep or other things tacked on by the client late in the game in an attempt to get more bang for his buck. Billing per hour is ideal for the software developer, but customers often prefer a fixed price for the project because it puts a cap on the amount it will cost. A new customer does not know what kind of work they can expect from a developer per unit time. To ameliorate this concern, I usually propose a very simple, short feature or milestone for new clients, so that they can get a good gauge of how long it takes me to complete a task, and what level of quality they can expect. I have also given price caps for customers on tight budgets, but this is more the exception than the rule.

Another reason that I propose a very short and simple first project for new clients is because I require payment in full and up-front for new customers. This sours some customers and I've certainly lost some business because of this policy. The way I see it, this requirement serves as a vetting process. It shakes out customers who may have shaky cash flow or who are going to later nickel and dime me for the work performed or, worst yet, not pay at all. Once I've had some time to work with a client and have established a good working relationship, I will relax these conditions and bill on a monthly basis (or more often, if requested). If I have not yet established a relationship and do not fully trust the client, I continue requiring payment up front and in full. When I finally end up billing on a monthly basis, my terms are Net 15 (that is, I require payment within 15 days of invoice), but I have some customers who much prefer Net 30 and once that relationship and trust is established I'm willing to agree to those terms.

I find this process of establishing trust by requiring payment up front at first, and then billing monthly with Net 15 terms to be a surefire approach to ending up with solid clients. To ensure prompt payment, some independent software developers use tactics like hosting the application on their server and not sending the code to the client until payment is received in full. Another, more questionable approach, is to put a backdoor into the application so that if the client does not pay the software developer can "break into" the application and "turn it off" until payment is received. I dislike both of these techniques as it frames the working relationship in adversarial terms.

I have waived or relaxed these requirements - payment up front for new clients, Net 15 terms, etc. - for very large or very established customers, such as regional businesses with thousands of employees, or Fortune 500 companies. These types of clients are more the exception than the rule, though, as the vast majority of my clientele are small businesses. And some companies or industries have Net 60 terms and won't make any exceptions.

Training
Like with software development, I require payment up front or on delivery of services for new clients. I will make exceptions for very large and established clients, but only sparingly. My hesitancy here in due in part to a negative experience with a local training company that was very late with payment. I ended up taking the client to small claims court, but was paid in between the time they were served and when the court date was set. (My decision to go to small claims court and the resulting process is summarized in My Small Claims Court Experience.)

While I always charge by the hour for software development, I charged for training services using a variety of models. For personal training I usually charge hourly, as it makes the most sense. In this way the customer has direct control over the costs and knows the precise charge for another hour or day's worth of training. For classroom events I usually charge a per-day rate, which depends on a number of factors, including:

  • Class size
  • Number of days of instruction
  • The location relative to my home - is the classroom setting five miles away, or across the country?
  • The material used and the topics covered - am I given the course-wear to teach or do I need to create it?

When a potential customer asks for a training quote, I use the above criteria to judge how long it will take me to create the course-wear (if needed) and to prepare for the class, how much travel time there will be (if any) and the total hours of instruction. I then multiple that number by my usual hourly rate for software development, then multiply that by a number between 1.0 and 2.0. This coefficient depends on the size of the class (the more students, the higher the number) and based on how excited I am to teach the class. If I'm teaching a two-day class to 5 smart devs who work in a fun company that's headquartered on the beach, and we're having a luau at the end of the second day, then that number will be a lot closer to 1.0 than if it's a class of 25 devs at a stuffy corporate office and I have to wear a suit each day. The figure derived from that equation, plus any travel and entertainment costs, are what I quote the client.

Writing
Unlike training and software development, it's hard to get a client to pay you by the hour for an article, tutorial, or book. Also, in my experience, it's rare to be paid by the word. Usually publishers have a pre-determined rate they pay for a written piece with a minimum word count. For print media - books and magazines - there is also a maximum word count. The pre-determined rate for magazines and websites is usually a dollar amount; for books it's a royalty rate and advance. (For a breakdown of compensation on writing a book, see The Economics of Writing a Computer Trade Book.)

Also unlike training and software development, it's virtually impossible to get a client to pay you anything up front. Book publishers offer advances, sure, but they don't start rolling in until you have completed a significant portion of the work. (This is true for computer trade authors; I'm sure Stephen King gets his advance whenever he wants.) As a result, as a write you have to be willing to get paid after the article or tutorial or book is written and published. As a result, I take a bit of a gamble if I write for a small publisher, small magazine, or small website. Having been bitten in the past, these days I rarely write for small operations unless I know the people running them and trust that I'll be compensated. But if a small publisher contacts me out of the blue and wants me to write five chapters for a book, I'll pass.

In Summary...
What's infinitely more important than the decision you make as when to you bill your clients and what terms to use, is to have very frank and clear communication before any work begins. It is imperative that you discuss with your client when you will bill and when you expect payment. They may agree, or they may want to change the terms. But what's vital is that there is a clear understanding. I've talked with many independent software developers who were too uncomfortable bringing the subject up or just assumed that the client understood and agreed with implicit payment terms, and as a result there was no communication prior to the work. This can lead to an unhappy client if his expectations of the payment terms were different than yours.

Also, if you have sent an invoice to a client and he has not paid by the time the invoice is due, do not hesitate to contact the client and politely inquire about payment. And, lastly, if a client becomes severely overdue, do not hesitate to stop working for him. You are not obligated to work for free.

Filed under:
More Posts

Archives

My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.