Finally got the new blog engine and design up and running for the blog, as one can see.  If anyone has two cents on the matter let me know what you think.

I've sort of put my ETL and process together as a post, it still needs some work, and I intend to post it soon.   So as always, stay tuned. 

I’m back on the market these days, searching for that next perfect gig.  Contract, permanent, etc.  I’m by no means desparate but I definitely do want to make sure it is a prime fit, whatever I head back to do.  If it is BI & OLAP, DBA Architect, Software Architect, Team Lead, or whatever I want to assure that the company and I get the most bang for our buck.  I’m all about the “win-win” vs. the Sun Tzu “winner and loser” scenario.

On that note I’m using some downtime to specifically get my blog engine transferred over.  So in the next week I’ll have my new shiny blog engines up and running!

Stay tuned.

Daily Habits and attitudes of an Agileish Developer

1. Always talk to the other developers around you about what is going on, what you're doing, what they're doing, and know what is going to affect your work.
2. Pair up often to develop parts that you are both respectively working on.
3. If you need a break from social existence, do some mindless work, don't work on intricate parts of code.  If you can't verbalize and discuss what is going on, you don't need to be poking around in that particular code.
4. Get user stories, if questions about the story arise, ask questions, if the story doesn't make sense, get the story changed.
5. Make sure you can figure out a way to test your code, if you can't you're most likely designing something poorly.  If you can't test it in isolation you probably haven't thought it through all the way.  Sometimes though some code just has to be badly written.  🙁
6. If you find yourself getting lost in code, refactor.  If you find you've written this piece of code before and deja vu is setting in refactor.  If you have more than 2-3 questions every few minutes about a piece of code, refactor.
7. If you can't read a story from the code and the code tests, refactor.

About 4 years ago I started using Gmail extensively.  I kept using up until about 6 months ago.  I moved everything to Outlook.  It took hours and hours to move that many years of e-mail to Outlook.  What I got was slower searching, slower response, bad system performance and other such notable catastrophes.

The main reason I did this was to move to a Windows Mobile Phone.  I did that, and now I feel as though I have even less of a reason to be using Outlook.  The Outlook client on the phone isn't all that great, and synchronizes just fine with pop3.

So I've decided, instead of continuing to spend the money on the plan that I needed to really utilize Outlook and the Windows Mobile Phone I'm going to turn all of it back in.  It just is not efficient.  Gmail is faster, synchronizes just fine with Outlook clients that I have to interact with, and is much easier to get to.  On top of that I don't have to have the Office Outlook monster installed on my machine.

So with that, I bid farewell to Outlook, probably for the last time ever.  There just really is not reason.

Vista, Ubuntu

I'm also starting to lean toward dropping heavy Vista usage and moving to Ubuntu and Linux in general.  It has always been a more stable OS than Windows in many ways.  With the heavy usage in the Portland area, I'm never short of fellow cohorts that use Ubuntu.

So with that, I'm preparing to bid farewell to Vista and XP as my host OSs over the next few weeks.

Technology Stacks

Next, I'm going to start checking out some of the other technology stacks besides just .NET.  I've been focused for the last 6-7 years and I know it is a good idea to branch out a bit in this arena, especially as I head toward some of the more high level business intelligence, architectural, and enterprise level projects.  Microsoft also, for some reason or another, seems to be waning under the pressure of Google and other entities nipping at the edges.  For instance Microsoft still has not garnered even a small percentage of the Internet market in search engine usage, social sites, or anything along those lines.

Microsoft is lining up to be another company, probably a good one, but no longer the behemoth on the block in the next 5-10 years.  Google is however lining up to be just that.

So unless Silverlight really takes off, and Microsoft really lights the fire of interest, I'm spreading my wings and may just fly away.

Not sure how many people do or don't get into a good flow at work.  I wonder how many do versus how many don't.  Currently I imagine that not many places have a good development flow.  Instead they have more of the wait, talk, wait, wait, wait, now develop really fast type flows.

I was just brainstorming and attempting to think of a good flow.  So far this is what I've come up with.  Starting in the morning, going through the day of a normal week long or maybe 2 week long iteration.

An agreed arrival time is met, let's say 9:00am is promised by the team.  A quick stand up begins at this time.

Stand up should consist of NOTHING more than this is what I did yesterday (that the group needs to know), what I'm doing today (regardless of what one might think affects someone else), and what I'll plan to get to tomorrow.  Then, after those three quick items, mention the road blocks & concern for roadblocks that are anticipated for the day.

9:15 am IF needed, otherwise don't do this step.  Review burn down chart, priorities, and what other elements of the project will need reviewed for the day.  Identify members external to the development teams and break off for those meetings.

9:20 am Begin individual dev efforts.  I'd prefer TDD style with a pair partner, maybe not to sit side by side, but each do respective work and either swap or mix up each others assignments on a frequent basis.

During the course of this morning work session if user stories are needed, clarification is needed, or any questions come up they should be asked immediately to whoever the primary stakeholder of that information is.

…contextual notes:

In no way should user story meetings need to go over 10-15 minutes.  Long design sessions just mean that information will be lost and these elements will need returned to.  It is better to have working code and product in hand of users than it is to have some fancy design.  At the same time however, in stark contrast to this is the need to keep in mind the architecture.  Depending on were, and in what way, the working code touches other parts of the architecture the design might need to be discussed separately than a user story design session.  Either which way, the overall meeting should NOT go over for extended periods of time.  Design sessions and user story clarification should be quick, and foster communication that is to the point, fact finding, and then production of working code for that user story should ensue.

sarcasm alert:  unless of course you DON'T want a fast moving development effort.

…end of contextual notes:

Noonish – lunch – foodz – sustain life – etc.

Last minute events should be:

30 minutes before departure for the day one wraps up by making sure there are no incomplete work stories in progress and commits all code.  Anything that actually needs to continue the next day needs to be noted for the following day at stand up.  If all tasks are completed the same should be done.

The first and last days of the iteration.

The only exception to the above work flow for the day should be on the first and last day of an iteration.  The biggest difference is user story meetings, clarifications, discussions, architectural planning, and burn down chart maintenance should be done at the beginning of the iteration.  This should be when bug fixes, architectural changes, and other big picture items should be discussed and planned for the ensuing iteration.

At the close of the iteration a clean, building, operable drop of the application needs to be made.  A test deployment and initial regression test should be performed by end of day on iteration end.  The quality assurance process then continues testing for x days and begins immediate bug and issue tracking that will feed back in to the next iteration.

This, is as I see a smooth flow for reaching fast, sustainable, and got morale based throughput.  If anyone has any thoughts on this I'd love to hear were this breaks down.  I've made a an effort to keep this description relatively simple, but would love more input.  Anybody from the peanut gallery?