When to put data into the data base vs. into a config file

It all depends? some of my rules of thumb are

for going into a config/resource file

1. it's the same for every user, like the path to an image directory
2. the data is only needed at the UI level and will not change very often, like a list of US States
3. it may vary from server to server, like a resource URL for production vs testing

for going into a DB

1. It changes per user or is user specific data
2. it may need to be maintained by someone out side your development group
3. It's going to be used outside of the UI layer
4. it's going to be updated regularly

what ever you do

DON'T HARD CODE STRING INTO YOUR CODE, I don't care how positive you are that the bug report notify Email address will not change, DO NOT HARD CODE IT!!!! or 3 years down the road what would have been a 2 sec config change will result in 2 weeks of work to get an out dated legacy piece of crap application to compile!! or another fun one was an xml-schema hard coded into an application with

stringname += "Schema data";
stringname += "Schema data";
stringname += "Schema data";

Oddly enough same guy, go figure.

Is pair programing worth it?

Another Blog entry based off a question on Stack overflow, Is pair programing worth it? are the Gains of Pair programing worth loosing the productivity of a developer by pair programing? VS just hiring more QA people (who are generally cheaper).

Thinking about this it reminded me about back when Extreme programing came out and you had developers saying it was the end of QA testing. the Funny thing is the more agile your development process becomes the more integrated and more interaction the developers have with the QA people. Basically the sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more QA people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.

Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc.

If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a Bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.

If your developers can't pair program don't force them into it, all your going to do is waist time and money.

Inflating estimated project completion dates

There was a question on stack overflow about inflating estimated project completion dates, after thinking about it I came up with some rules of thumb that I have been trying to follow

Estimate how long it will take and add 1/2 again as much time to cover the following problems:

1. The requirements will change
2. You will get pulled onto another project for a quick fix
3. The New guy at the next desk will need help with something
4. The time needed to refactor parts of the project because you found a better way to do things

and I don't I'm far off, if anything I think this is a rather conservative approach, most guild lines I found on line where estimate your time then double it.

The value of N-Tier Design

I was answering a question on stackoverflow.com about N-Tier Design and when I was done I realized I had a great Blog post. so here is the value and reason for doing n-tier design

The data access (sql server, mysql, flat xml files, etc.) all of this should be abstracted away nothing else in your application should care or know how you are getting your data, only that it dose, if anything else knows how you are getting your data you have a layer violation. if the DAL dose anything other then get data you have a layer violation. Next you implement a data access interface something like IDAL that your business layer uses, this is very important for making your code testable by forcing you to separate your layers.

The data entities can be placed in the DAL name space or give them there own, giving them there own forces separation. Data entities are dumb objects and should contain very little to no logic and are only aware of themselves and the data they have, THEY DO NOT CONTAIN BUSINESS LOGIC!, DATA ACCESS LOCIC, OR UI LOGIC. if they do you have a layer violation. The only function of a data entity is to hold data and be passed from one layer to the next.

The Biz layer implements a data access interface like the IDAL we talked about before you can instantiate this with a factory, an IOC container, or all else failing a concrete type, but add a setter property so this can be changed for testing. The Biz Layer Only handles Business logic, it doesn't know or care where the data came from or where it's going, it only cares about manipulating the data to comply with business rules, this would include date validation, filtering (part of this is telling the DAL what data it needs, let the DAL figure out how to get it). Basically the BIZ handles all logic that isn't UI related or Data retrieval related. Just like the DAL the Biz should implement an Interface for the same reason.

The UI layer Accesses the Biz layer the same way the Biz layer accesses the DAL for the same reason. All the UI layer cares about is displaying data and getting data from the user. The IU Layer should not know anything about the business rules, with the possible exception of data validation required to populate the Data Entities.

The advantage of this architecture is it forces separation of concern making it easier to test, more flexible, and easier to maintain. Today you are building a web site but tomorrow you want to allow others to integrate vi a web service, all you have to do is create a web service that implements the IBIZ interface and your done, when you have to fix a bug in the BIZ layer, it's already fixed in both your website and web service.

Taking this to the next step, lets say you are doing a lot of heavy number crunching and you need more powerful servers to handle this so all you have to do is implement an IDal and IBIZ interface are really wrappers to WCF that handles the communication between your servers, now your application is distributed between multiple server and you didn't have to change your code to do it.

I'm not addicted to pod casts I can stop listing any time I want to, I just don't want to

The all to common words of the junkie "I can stop any time I want to". I have been on the mp3 bandwagon since the late 90's, ripping all my CD, and a few that weren't, to my computer, I have always loved books on tape, but I never really got into pod cast until just over a year ago.

Lets face it the early pod casts were really horrible with bad audio quality production quality that sounded like they here done by guys living in there parents basement or schizophrenic nut jobs randomly ranting with out any ability to stay on topic and where generally a wast of time.

Then I met the candy man, ..er woman. at Netdug, the local .Net developers group, Kathleen Dollard did a presentation on linq and some other new .net 3.5 features, and during her presentation she mentioned being on DNRTV.com, and how they had a lot of good videos out there for learning new things about .net. I checked it out, watched a few videos and was really impressed, the production quality was good, the audio and video quality was great, these guys knew what they where doing and talking to people who knew what they where talking about and then the mentioned the Podcast, so i checked it out, I had some grunt work to do so I pulled a few episodes down and started to listen and so began the slows spiral down into addiction. Some of the guests talked about there blogs and some had there own pod casts.

What started with DotNetRocks quickly added hanselminutes, Elegant Code Cast and the dirty pleasure of Mondays, but I was still in control I had to be at a computer to listen to them I didn't have a portable mp3 player, I never felt the need to own one and then woot had two 1G san disk mp3 players for $15 and I couldn't say no.

Now I could get a fix any time and any where! the 30 min drive to work was now filled with the wisdom of the guru & rock stars of the development community, and juvenile geek humor, until today, I didn't get a chance to update my player last night after I ran out of shows last night on my way home. I had to drive for 60+ min with only the radio to listen to, with the lame humor of the morning DJs, the 5 Commercials for every 3 songs with most of them in the suck category, the detox was horrable, how did I live before?

Am I a junkie? Probably, but it's a lot better then listing to the radio!