There's been a big industry focus on test driven development over the past few years.  Many advocates of TDD make it a point to say that TDD is not really about testing, it's about design.  Writing tests before application code forces you to think about the goal(s) of the application code.  For example, what should the input to a certain method be, and what output should it supply?  TDD forces you to think in terms of inputs/outputs and code interaction.  What input should be provided to the callee, what output should be provided to the caller - essentially, how will multiple objects (e.g. classes, methods, etc) interface.  

I've recently started practicing TDD a bit, and have found that instead of always writing unit tests with some type of testing framework (e.g. nUnit), I sometimes create a console application that calls certain methods and reveals the output.  Granted, these are perhaps more "integration" tests than unit tests, as I'm using them to view database contents.  None-the-less, it got me thinking about TDD, and the notion that "Test"-Driven development isn't really about tests.  In my opinion, a more appropriate name might be "Client"-Driven Development.  I'm not referring to the clients that pay your bills, but the client portions of your application (e.g. the UI which calls another application layer).  There are clients at every layer of your app - the UI calls one layer, that layer calls another layer.  Each caller is a client, and when writing tests first, we need to think in terms of the "client", what it should input, and what the result should be.

Isn't CDD essentially the goal of TDD?

Over the past several years, I've heard many arguments for the benefits of using CSS over Html tables for page layout.  Having been abstracted away into the land of server controls via my usage of ASP.NET, I had not taken much time to fully utilize css.  I've recently been involved in a project that benefited significantly from the usage of CSS over table layouts.  This is not to say that the same output could not have been accomplished using tables, but the ease of maintenance and elegance of css blows away the table competition (or lack thereof).  

The following are my recommendations in relation to CSS:

1) Take the time to learn it
Some web developers (my old self included) think of CSS as something that falls into the land of designers.  While designers may have a more natural interest in CSS, developers should be just as interested, if not more so than designers.  As a web developer, adding CSS to your toolbelt is one of the most effective uses of your self-training time.  As developers, we often get caught up in the latest feature of a language or some "cool" technology, that, in practicality, we seldom use.  If you learn CSS and use it correctly, you will use it on 100% of your web projects.

2) Layout your content logically before thinking about style
This separation of concerns is really the foundation of implementing CSS.  CSS is only intended to affect the look of your pages.  When you add your content and try to style it at the same time, you often end up with a lot of junk that you don't really need, creating more of a maintenance headache.  Laying out content first, using the correct logical tags (e.g. a menu is simply a bunch of list items with links <li><a>Item</a></li>) will save you time now and in the future.

3) "Cascade"
Object-oriented developers are already familiar with the concept of inheritance.  We know its effectiveness in programming, and that same effectiveness applies in CSS.  Want to style every item in a list?  Put the class (or id) on the list header tag (e.g. <ul>), not on every individual list item.  Learn how to use inheritance and how to override styles correctly, and your stylesheet will shrink and be easier to maintain.

Every developer that has worked with SQL for any length of time has most likely been there...  You are running an ad-hoc DML (data manipulation language) SQL statement against a database.  Depending on the security processes in place at your company/client, you may be executing this statement against a development database, staging database, or (gasp) a production database.  You've written an update statement and are thoroughly convinced it will update only the select few rows that you would like changed.  However, you execute the statement and see the message "30072 row(s) affected".  Depending on the environment you executed this in, you are either mildly frustrated (development environment) or your heart is in your throat (production environment).

So, how do you avoid this?  Test against data you don't care about?  Run a select statement that mimics the update or delete statement before you actually execute it?  These are both a step in the right direction, but another way to verify that your SQL will do what you intend is to utilize transactions.

Instead of:

(Which will cause the price of your nerf footballs to be 10.99, however the Football stadium that you happen to have for sale will also be quite the bargain.)

Why not use:


Utilizing a transaction and then rolling it back allows you to see the number of rows affected and, if you choose, the "before" and "after" state of the database without actually committing the changes.

The concept is simple, but re-using it as a best practice will save you time, headaches, and perhaps even disaster.

Abstraction is a powerful concept in software development.  Abstracting away certain parts of an application can heavily reduce develop time and make for a maintainable solution.  One shining example of this is the multitude of Object-Relational Mappers on the market, which abstract away a large amount of details about database interaction.  However, as with most things in life, abstraction's highest value is realized when used in moderation.  

While picking up ASP.NET MVC, I've started to realize the significant abstraction that asp.net server controls provide.  ASP.NET MVC doesn't have the parallel (at this point) to the server controls of web forms.  There are html helpers, but those are a very minor abstraction in comparison.  

Whether using web forms or ASP.NET MVC, one could argue that there are always abstractions that don't pull their weight.  For example, it's not unheard of for developers to use label controls for every message they put on a page.  The label abstraction doesn't provide anything that an html span tag wouldn't.  As another example, html helpers in ASP.NET MVC don't always provide much bang for the buck.  In some cases, it's harder to learn the syntax of the html helper than to simply write the html itself.  Learning how to write the html always applies to web development, the helpers only apply to ASP.NET MVC.

Abstractions can make us lose sight of how something actually works.  I will certainly admit that asp.net server controls have prevented me from learning the inner workings of some html tags over the years.  At the same time, they have sped up my development in many cases.  Whether you use abstractions or not, you should first understand what each is doing under the covers.  This allows you to determine if it is adding value or just tacking on an extra maintenance burden.

I recently encountered a case where I needed a sql result set to account for the value of an "Include inactive" checkbox in the UI.  The business requirements were: 1) If the user doesn't check the box, display only active records, 2) If the user checks the box, display both active and inactive records.  The active field was a bit in the database table, so all records were either active or inactive.  My first thought was that for case 2, no WHERE criteria would be necessary for the sql statement, whereas case 1 would require "Active = 1" criteria.  This seemed to point to the need to dynamically construct a sql statement based on the inclusion/exclusion of that where clause.

I was working with an existing parameterized sql statement, so really didn't want to switch over to a stored procedure and start dynamically building the sql within the sproc (not to mention building the sql dynamically isn't the cleanest approach to begin with).  After a little thought, I realized that I could solve the problem within the same parameterized sql statement simply using IN criteria. 

Here's a stripped down version of the sql. The @IncludeInactive parameter comes from the checkbox value

Case 1: Checkbox not checked, don't include inactive users

Case 2: Checkbox checked, include inactive users

Nothing ground-breaking here, but much less code to maintain and a lot cleaner than dynamic sql.