Apr 14 2008

Enum Tables in the Database

Category: Database, Programming — lomaxx @ 12:12 pm

I was talking a while back with a colleague about the Enums and Reference tables in databases and how it would be cool if you could somehow bridge the gap between the two in code.

To demonstrate the problem, here’s a simple scenario:
Suppose I have two tables,

Order
-----
OrderId
OrderStatusId (FK)

and

OrderStatus
------------
OrderStatusId (PK)
OrderStatusDescription

Now this is a pretty normal table structure. I can enter in order statuses into my table as

1 – Open
2 – Shipped
3 – Closed

The good thing about this is that I can use a foreign key to enforce referential integrity and I can easily use joins to get the OrderStatusDescription for displaying to the user.

The disadvantage is that there is no guarantee that the PK values of these statuses will always be the same unless I deploy the table data using a script or something. Even then it doesn’t stop someone from manually going in and changing the data, which doesn’t matter so much I gues, but sometimes in code I’d really like to be able to guarantee the safety of something like a select case statement that looks like this:

int orderStatus = MyGetOrderStatusFunction();
switch(i)
{
    case 1:
    case 2:
}

etc.

I don’t like to do this because there’s no strong typing between the primary key values of the order status table and the values I’ve coded for in my switch statement. Really the only thing I can do is perform the switch on the status description string, but even then, there’s no safety. So you’re probably thinking use an Enum already. Well I would, except then you lose the benefits of being able to enforce referential integrity and displaying the description to the users is overly complicated.

What would be nice is if you define a new type of table in SQL called an "EnumTable" which could be used as a table in your SQL, but also referenced as an enum in code. When you define an EnumTable you’d also have to specify key value pairs for the data and that would then form part of the table definition so that every deploy of the database that you do has an identical copy of the table data so that in your code you get the type safety of an Enum whilst having the database flexibility to join on the Enum values.

Apr 01 2008

Preparing for new hires

Category: Programming — lomaxx @ 12:51 pm

If you are hiring new people to come work for your firm, the most important thing you can do after you have agreed to the terms of their employment is to prepare for their arrival.

Software developers are usually pretty excited when they start a new job. They want to know about the projects they’re working on, they want to know about the team they’re working with and what cool ways the new company does things compared to how their old company used to work. In short, they’re enthusiastic, keen and ready to go.

If you aren’t prepared for the arrival of your new developers, you’ll kill any enthusiasm they had for starting the role. In just about every job I’ve ever started, the preparation has been the same… none.

The thing that gets me most is that if you’re hiring someone, your current workload is obviously exceeding your production capacity, or you’re preparing for an excessive workload, so how can you afford to have your new hire sitting around doing nothing because you haven’t prepared for their arrival?

Jeff Atwood suggests that a day is all it should take to get a new developer contributing productively to a team:

This points us to one of the most important health metrics on a software development project. How long does it take for you to get a new team member working productively on your project? If the answer is more than one day, you have a problem.

I absolutely agree. Not only should they be setup and ready to go after the first day, they should be contributing productively to your team, but the only way you can ensure this happens is to prepare in advance.

If you’re hiring new developers, here are some things you can do to help them transition into their role a whole lot sooner:

  • 1) Give them a computer to use.
    As ludicrous as this sounds, I’ve started at companies before where you arrive and they say “you won’t be able to start working on the project till your computer arrives” or “your computer hasn’t arrived yet, but we’ve dug this old Pentium 2 machine out with 64MB ram for you to use until it does”.

    Seriously, if you’ve got new developers starting, they’re going to need a computer so get them one, and not some dinosaur, get them something (preferably new) that they’ll be able to use for the next 3 years.

  • 2) Set the machine up for your new team member
    Often part of the “First Day Ritual” is setting up the computer you’ve been given. If you’ve gone to the trouble of hiring a developer, don’t waste their first couple of days “setting up the development environment”. I’m not talking about things like email or network access. If you haven’t got those basics setup then you have a whole lot more work to do.

    If you want your developers to be productive from day one, you should have all the tools they need to do their job already installed. You should have the projects and solutions setup in visual studio, you’ll have a local install of the database server setup with dev databases, you will have given them access to the source code repository and anything else they need to hit the ground running.

    Pretty much all they should need to do when they arrive is be given an overview of how the team works, what their task is and to get latest. This leads us to the next part of preparing for your new team member

  • 3) Give them something to do
    There is nothing that will kill new team member enthusiasm quicker than having nothing for them to do. Telling them to “read doco” for their first day is a sign of poor preparation and that you have nothing for them to do. Writing doco is also an indication that you have nothing for them to do, or that they’re working with lazy team members.

    If they’re not doing something related to development that is productively contributing to the team after the first day then you haven’t prepared properly and they are doing nothing. The guys over at critical path suggest getting new developers to do code reviews to help bring them up to speed. This is a fantastic suggestion as it gets them interacting with team members, understanding the code, improving the code base and most of all, productively contributing to the team.

    It doesn’t really matter what the task is, remember, you hired these guys to develop things, not to sit around reading and writing doco or posting to blogs, so don’t waste your time and money by not giving them something to do.

    • It really does amaze me how many companies will hire people and then waste their first week or more by not preparing for their arrival to have them contributing to their teams. Next time you hire a new developer, or in fact hire anyone new, make sure you prepare for your arrival so you can make the most of your new team member from day one.