So I've started documenting a super simple application I'm going to create.  The application simply keeps track of the mileage one records when travelling.  Certain facets can be used and I intend to implement some standard data entry apps via web and windows, reporting, and a schema & architecture diagram.

So far I've created these initial documents outlining what I am going to create.

• Visio UML Use Case Diagram
• Word Document Application Description and Features

With that I've started creating the application and will at the same time create supporting documents for the application so that others can download the code and build onto it if they would like to.

As I got these files uploaded I also setup a few Team Foundation Server Work Items to keep track of the tasks.  Of course there are all of the default tasks that are listed as soon as you create the Team Foundation Server Project and I've just left them there with the intention of using them for further documentation and tracking purposes too.  Mainly to make sure I finish all the pertinent documentation.

So I started with Centerstance on the 27th of this year.  We're really getting into crunching some code at this point of the project and I'm still having a blast.  Tacoma even has its plusses, mostly just the fact that the crew I work with is awesome and great fun to chill with "post code hours".  This last week has been rather spectacular with a few wines, a port, some custom built scotch, and some great conversation ranging from code to the "P" word I've got to say WOW, amazing gathering of senior talent and like minds.

We've made it through our first iteration, Eric Peterson and myself leading the spearhead in the assault to take the application beach head.  Reid held up the rear with the heavy artillary cranking out the final DAL implementation and search integration.  We now have increased our force by two more great developers; Aendenne and Shilander (spelling?).  We're all rounding out a few rough corners we all have with various pieces of technology (namely that ole' CAB/SCSF/MVC/MVP Pattern stuff).  By the end of this month though we'll be one o' the 31337 teams of the north west without doubt.  Cheers to our further successes and a hearty welcome to all new team members.

"P" == Politics

Back after a few weeks of not touching Team Foundation Server my fellow techie and I went geek this weekend to figure out how to remove, update, and replace the exiting "test" projects.  Needless to say, this was no cakewalk.  Microsoft, did you hear that?  It wasn't a cakewalk, it was confusing, frustrating, and somewhat annoying.  Now I'm sure 80% of the confusion was from us just arbritrarily setting up the server and trying to toss stuff into it and not really following any particular method.  But we did that because most of the time this is the exact process that a dev group will take with a new product.  Thus it just gets thrown together with no real reason beyond a proof of concept.  So the following is the list of trials and tribulations we had to go through to get this puppy running with the big dogs.

• First lesson.  Team Foundation Server shouldn't be installed on a Microsoft Virtual PC Server unless you have serious hardware.  Don't ask me why, I don't know, but the server gets really slow when it is on a Virtual PC.
• Second Lesson.  Don't just haphazardly add projects and solutions into the source control repository.  This is a bad practice.  All developers, repeat this, there must be a project/solution plan for adding source to source control.  There must be a project/solution plan for adding source to source control.  There must be a project/solution plan for adding source to source control.  The number of ways one can add to source control, from the number of ways one can set their native paths, to the number of places the projects and solutions are saved into source control are so numerous that if everyone takes a different approach a dev team runs a very high risk of ending up with the "It runs fine on my machine" scenario.  Besides that, everyone on the team then knows where everything is.
• Third Lesson.  If you need to remove a project or solution from a Team Foundation Server "Project" it is often times no easy matter.  First you must make sure your mappings are correct and in place for the project or solution to be deleted from Source Control.  When you right click the delete option will then show properly.  For some reason we had to learn this the hard way because our solutions/projects we added where never mapped appropriately.  Once a project/solution is deleted you must then "check in" these changes so that the project/solution actually goes bye bye.

At this point these are our primary lessons we've learned.  Next on the to do list is to create task lists, prepare reporting, and figure out the various queueing mechanisms and build process.

So as I churned through a conference call for our daily SCRUM I thought to myself, "What really makes a good developer?"

So here is my list:

1. A good developer must at least know about multiple ways of doing things.  Whether it is top down scripting, object oriented development, or another method.  Multiple paths to solutions are very important.
2. Calm nerves and a good sense of humor.  Along with these two things a massive allowance and tolerance for people that are NOT going to be as quick thinking as they are.  The ability to NEVER mention or imply one's superiority, humbleness is the key to success.
3. Never act like you own the business process unless you monetarily "own" the business.  Even then, you might not want to act like you do if you're doing development.  It's better to step away from such a lead role when breaking down problems.
4. A good developer knows that coding is only about 10-20% of what they actually do.  This is also probably the proper amount.  A good developer must know the business better than anyone else, must know the ups and downs and changes of almost every department and involvement with their application, and most importantly this must be done calmly, organized, and without stress.
5. For really good developers, it is key to understand and know how to break down problems.  In the same vein, one should additionally know how to break down business problems and what design patterns should or should not be applied to a situation.
6. Code reuse isn't a dream, it should be the practice and standard operation of any good developer.  Copy and paste does not equate to code reuse.
7. A good developer MUST have people skills.  A good developer must be able to communicate effectively, quickly, and accurately to business stake holders.  If a developer can't communicate well, they are not a good developer.  Every design pattern in the world doesn't replace good communication.
8. A good developer must have a good sense of humor.  Must be able to read people and act accordingly to manage their surrounding environment in a way that is best for the continued success of the developers development.

That's about it.  At least for core items.  Got any others to add?  Please comment.

So I decided I was going to write a plugin that would tag stuff based on Technorati, Digg, and other such things.  Well about 2 hours into figuring the whole plugin thing out for Live Writer I stumble onto the latest version.  Needless to say it made my entire effort rather useless as someone had written an add in that does just what I wanted it to do.

So humbug.  I won't be writing a tag adder plugin.

So as I sit here pecking away at generating some readership on my various blogs I stumble upon the idea to write some plug ins for the Windows Live Writer Application.  So keep your eyes peeled as I might just have some linked on this site soon!

My first goal is to get the SDK downloaded and installed.  First features should be technorati link generation and digg submission.  :)

Of all the segments of layers and designs for software one of the most common is the Data Access Layer, often referred to as the DAL.  For well over 5 years I've used dedicated DALs to segment the business logic and user interface from the actual database.  The data access layer serving the purpose to seperate the intricacies of the referential integrity and other such important necessities of the database from the programmer dealing with the business logic and flow from the user perspective.

Often times I've used DALs simply to describe my data objects, which are related directly to the tables and schema of the database itself.  When doing so I've been able to use the DAL that is generated from Codesmith by the default business object templates or other items that are included.  I've been able to grab some really great add ons to Codesmith such as .NET Tiers.  Following Microsoft's Patterns and Practices this "extra" for Codesmith rocks.  It enables one to develop the DAL, deep fills, WCF bases, and other features.  A very nice set of generated procs are included along with that.

I'm still amazed how many groups still churn out their own "custom" and very proprietary data access layers.  The amount of time, money, and proprietary knowledge investment in such a layer is extensive.  I've always thought the effort, time, and money could be spent more specifically on the business logic and processing layers instead.  DALs are usually simple, no matter the complexity or chores performed by such a layer, the generated DALs that are provided via Codesmith and especially .NET Tiers are well worth the swap.  Dedicating human resources to write up this layer manually seems counter intuitive.  Of course, there are always reasons to hand code parts if need be, just rarely does this opportunity arise.

I wonder though, what other purposes should a data access layer serve?

So I had a miniture epiphany today while coding away on a multi-tier application I'm building for interactions with one of my other blogs and with a database driven website application.

That epiphany is that I have two books, the have basically outlined the difference between a $70,000 developer and a $105,000 developer or architect.

The first book is Pro ASP.NET 2.0 in C# 2005 from Apress.  If a developer knows all the ins and outs of each piece of technology in this book they are easily worth 65-75k.  Probably a little bit more depending on their location, but definately NOT less.

The second book is Head First Design Patterns from O'Reilly Press.  This book is not for the beginning developer really as the design patterns, any design patterns, aren't really of any use until after one understand object oriented programming, basic project management, and various other topics at different levels of software development.  A developer that knows at least 1/2 of what this book offers up is easily worth $105,000 or more depending on position as developer or architect.  A developer with this knowledge would probably top out at about $90-95,000 with this knowledge, but tag Senior Developer, Architect, or Senior Architect and that range is easily somewhere in the $100-125,000 yearly range.

So to those budding developers, if you want a gauge of where you are, hit up these two books and you'll have a good idea of where you stand.  If you're under that bracket and you live somewhere out on the left coast (LA, San Fran, Portland, or Seattle) you REALLY better renegotiate or find a new job.  You're bringing the rate down for the rest of us.  Even India has brought it's rate up that the flow of offshoring has slowed to a trickle as of late.

As for developers out in the midwest or southern US, I'd estimate these ranges accordingly with cost of living, usually about 15-30% less than what is above... but then of course you guys in those areas can buy 3,000 square foot houses on 2 acres of land for the price of a 700 square foot condo out on the left.  :(

anyway... enough of my rambling off topic discussions.