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.- 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.- 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.- 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.- 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.- 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.- 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.- 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.

del.icio.us tags: Windows Live Writer, Technorati, Digg, Del.icio.us

Technorati tags: Windows Live Writer, Technorati, Digg, Del.icio.us

LiveJournal tags: Windows Live Writer, Technorati, Digg, Del.icio.us