I recently watched a video presentation of Alistair Cockburn, who is a fairly major name in the Agile Development Community.  It pushed me to put this entry together for future discussion that I intend to kick off (at least on this blog & the few readers I have).  I have worked on the following Agile Projects:

• My most recent project utilizing Agile Processes was at Webtrends for my stint in Engineering late 08 and earlier 09.  I worked on a team to build web services for Webtrends data access for customers.
  • The team consisted of three people, one being a team lead.  Our primary use of Agile was somewhat limited as it was a new process for the team.  We performed continuous builds via Team Foundation Server and test driven development when feasible.  We were limited in using TDD to some degree as a large part of the work was configuration based for server configuration and required a large degree of integration tests more than isolated unit tests.  In addition to TDD we also utilized user stories, burn down charts, and to some degree kanban style prioritization.  The project was a rocking success, and is now offered as a Webtrends offering and documented, discussed, blogged and continuously maintained and advanced.  Even though I am on a different team now working directly with customers to implement integrations with these REST based web services, the engineering team continues forward with more Agile practices being used daily, including paper prototyping, furthering the unit testing majority of the teams, and more.
• After* and before* the Webtrends engagement I helped to initiate Agile in a development group of 4 people at Axiom Group (now Axiom EPM) to build a Excel UI to SQL Server for accounting data storage, manipulation, analysis, trending, and retrieval.  I helped get the group kick started, and the software that was released is now called Axiom Planning.
  • The team of 4, split into two pairs, and we did pairing & individual development.  Other agile software methods used were rapid learning, extensive test driven development, continuous integration (w/ TeamCity), unit tests in builds w/ good coverage (the logical kind), mocking (for databases), self organizing team, paper prototyping, and direct daily communication with customer representatives.  We also as pairs and as a team used refactoring heavily.  In addition heavy utilization of design patterns and domain driven-design was used in close collaboration with the customer.
• In 06 & 07' I worked with Centerstance Consulting on a project which started Waterfall and moved to Agile during the course of the engagement.  We started off a team of 5 developers, grew to about 16 at one point, and shrunk down toward the completion of the overarching architectural design to about 8-12 again.
  • The teams ranged from 4-5 people per team with a team lead, to two teams with two sub-teams split with a team lead each doing their own respective stand ups (SCRUM style), a continuous integration was setup, unit & integration testing was eventually put into place across a wide spectrum of the code base.  Mocking, faking where appropriate, and general unit testing took place, with business analysts acting as customers.
• For Ghallt Enterprises I served as CTO with a business partner, leading efforts among remote teams, utilizing Agile practices (yeah, remotely, I know, it seems crazy) to develop social media software.  Methods included continuous integration, build management, pair development, code review & refactoring on a regular basis, and other practices.  Even though this is a company that a friend and I started, it served to provide a catalyst for me to push forward extensively into Agile Processes.  The level of progress, quality of code, and other characteristics that are inherent to effective Agile Processes were of a level that left no reason to endeavor toward traditional style project planning or Waterfall style approaches.

I?ve worked with others to mentor and experiment with pair development, continuous integration, unit testing, and other processes to enhance and streamline the software development life cycle.

* I write after and before Webtrends because I left Webtrends in 08' to work the Axiom effort, upon kicking that off, I then headed back to Webtrends to work on the then new Web Services with REST Architecture Project.

I have been working for Centerstance almost a year and 4 months and made a lot of good friends.  It has been a great ride and I've learned a lot, and forgotten a lot (not really), had tons of great beers (Vodkas, Wines, tasting sessions etc.) with a bunch of great guys and gals!  I'll definitely miss many of them and I'm sure in the future I'll be dropping by for a visit every now and then.  Shux, Portland is a small town, I might get to work with any number of my fellow coworkers again, and would enjoy the experience!

• Eric P. - Thanks for the comments, the continuous badgering to do better, and the insight and support in everything we worked on together.  Maybe we can work one of those elusive bank jobs one o' these days.  Those first iterations where crazy, hectic, and actually fun contrary to our delirious and sometimes delusional state after 14 hr days!  Thanks also for realizing that I'm working on my "task switching", and for helping me rock through some stuff even amid that.  You make a great lead, a truly great lead, and I wish you the best in those efforts.
• Jim M. - Thanks for the drinks, thanks for the support, thanks for not killing me a few times.  Your leadership enabled me to implement that whole crazy business rules engine (NxBRE), and the sanity to start rewriting the effort when the rules engine was tossed from the design.  Who knew!?  Also - thanks for the grand sounds of the Harley during the summer months as I walked into the office.  I always like the sounds of a good set of two wheels rolling along the road.
• Harv F. - Thanks for showing me the awesome barbecue places!  They rocked.  Also thank you for the calm leadership demeanor and many conversations we had about all sorts of business matters!  I hated to see you leave and hope you're taking care of business in whatever you're doing, I'm sure you are.
• Billie O. - Thanks for being the courageous CTO that the project needs!  Your determination you display has been positive throughout my tenure on project, I've enjoyed working with your teams very much.
• Ben - Thanks for keeping the lights on.  Thanks for making sure things stayed hooked up too!
• Annais - Thanks for the friendly hellos in the mornings during the cold winter months of late 06' and early 07'.  Your smiling face was always nice to see.
• Aendenne A. - Thanks for the conversations, hilarious irreverence, and completely non-PC conversations.  Enjoyed discussing cars, music, and the random political diatribe with you too.  Have fun down in Phoenix!
• John - Thanks for the conversations, the slight off bit insanity spurts as we questioned the logic and complete idiocy of the tax code all the way through to the best way to arm soldiers to citizens to home defenders.  Dot five oh desert eagle baby!
• Jay W. - Excellent photo tips, great work on that "custom domain (CDM)" you had to work on!  I actually dug through some of it... so I'm not just saying that. 
• Shane T. - You are an architect, the weirdo astronaut type!  You got drive and determination like I have never seen!  Keep up the good work.   It's been great and I'm sure I'll see ya every few days for that proverbial after work beer!  Please don't kajukenbo my butt for rolling off!  argh!
• Dan S. - You be architect too, TT lovin' architect.  Awesome work, good humor, and also an amazing work ethic (maybe slightly crazy?)  Dan - you need to drag yourself out after work too, I got a lot of conversations I never had with ya that I wanted to!  Awesome work fortress in the mountains... btw - when are we doing a startup project so we can get richer and richer?  
• Pete S. - Thanks for the peace accords.  You're good at that style of operation.  
• Kirk M. - Semper Fi Marine!  Good work, great demeanor, respectful, and honorable.  You are a rather rare developer.  Have a good day, week, year, life, etc, I'll be happy to run into you sometime again and hash through some code!  Maybe even some more WCF one day?  Yeah!
• C*** *. (top secret first name letters and last initial) - Thanks for the DB Schema discussions, the transit conversations, the home made, custom, turbo, awesome, kick ass, alcohol!  I'm waiting on the Vodka release!  I'm sure I'll be running into you around these Portland parts in the future.
• Greg L. - Thanks for being a great leader, tactically and strategically I felt confident in your leadership of Centerstance.  It is nice to go to work each day and have that feeling.
• Lisa S. - Thanks for that process & firm kick in the butt when things where a bit rough.  I definitely appreciated the efforts in clearing the path for development.
• B. Cassis - Thanks for those supercharger fast DB changes!  You rock!  btw - thanks for allowing me to confuse you, and then beating me into logical-ness when I stumbled!
• Jagdish - Jag, thanks for those random coffee trips and the stories of India!  Relating with you about those and about my own area I grew up in where very interesting.  Noting similarities on opposite ends of the planet is intriguing!  Oh yeah, and thanks for those ripping fast database requests!
• James G. - Thanks for the comments, camaraderie, and random troubleshooting help.  If you ever have questions - I'll probably answer em', maybe.  
• James S. - Where did ya go?  Awesome hanging with ya man!  Anytime I'm rolling through the Tac I'll give u a ring.  How goes the current job hunting and/or work?
• David K. - I hope you enjoyed A Confederacy of Dunces.  Good book, true to the city.  Enjoyed working with you the short times we where teamed on some things.
• Bob W. - Are you a citizen yet?  When are you coming to Portland to have a brew?  How goes the work?  It was excellent working with you, good ranting with you, and most excellent having a non-American accent besides by southern babbling.
• Anish G. - Keep up the good work, you have some good skills!  Enjoyed working with ya, you are definitely a top notch developer!
• Sameer - Didn't get to work with you much, but had fun when I did!  Maybe we'll stumble into each other on some more work efforts!?
• Raghu S. - Keep that build under control!  Good job, good humor, enjoyed working and grabbing that rare lunch with you.
• Abhihjeet T. - Yo Abhi!  Excellent working with ya.  You're gonna be one o' those elite guys I can tell, Peterson and I believe so - but you didn't hear that from me.  Hopefully I'll run into you around Portland sometime.  Gimme a ring when you're in town!
• Steve W. - Thanks for the awesome, often times educational, and entertaining conversations.  We'll definitely have to chat & have dinner on one of my frequent future trips to Seattle.
• Trentin - Thanks for the e-mail info, random support, helping kick the VMs, and numerous hardware conversations.  Enjoy that sys admin job!  Take it easy.
• Reid R. - Thanks for the conversations, metal music, and guitar disccussions.  Keep up the work on the game servers, blogs, and other zillion things u are working on!
• Jeff L. - Prozac.  You'll get there, just one step at a time.    Have a good trip and keep up the patterns study, but make sure to get the Martin Fowler book, it's way better than the one with the hot girl on it you have.  

For anyone I forgot, my apologies, my fingers started cramping up.  Best of fortunes to all, and I'll see everyone around I'm sure.

...and if I don't have your contact info (or you want your name and my 2 cents added to the list), shoot me an e-mail! 

One of the things I really got ingrained in my habit while working at Bank of America was the respect of other people's time.  Especially in fast moving projects this is a very important thing to practice.  While working at BoA one could literally be let go if they did not respect other people's time when scheduling meetings and other such time consuming, yet much needed, work related events.  I was digging around some material I had found in storage a few weeks ago and it got me thinking about this.  The core facet of this trait is simply, "respect other people's time".  Everything about one's work habit within a team should encompass this.  The core idea behind this trait is, "empowering the individual" and is simply part of a "meritocracy" based environment.

• Don't be late to a meeting.  Not even a few seconds.  The only acceptable arrival times is at the scheduled time or before.
• If you're going to be late notify well before the meeting and be sure to give an ETA so an accurate rescheduling decision can occur.
• Make sure to send any notices for a meeting well in advance of a meeting.  (2-4 hours minimum)  Otherwise expect nothing more than a quick conversation of 5 minutes or less.
• Take into account other people's meeting schedules.  Don't double, triple, or otherwise book people.  Even if you're the boss, don't do this without notifying the person of their priority, or asking what their priorities are for the day.
• Make sure to have clearly defined topics and understand the objectives and goals of the meeting.  Do NOT go to a meeting and just start conversation on a "cloudy" or unclear topic.
• Do not surpass the scheduled meeting time.  If you think you need time, schedule as much of it as you believe will be needed to cover the topics.
• Preferably take meeting minutes and designate a specific individual to meeting minutes.
• Make every attempt to stay on topic during a meeting.  If one leaves topic, have a designated topic watcher to maintain the flow of the meeting (the meeting minutes person usually is good at this).

Those are the summarized meeting points for the material I found.  I've blogged because I think this is a highly underrated trait, often unnoticed these days, and even more so unnoticed on the west coast for some reason.  However the amount of productivity lost to non-punctual, unscheduled, off topic meetings is massive.

Ok, I've been using CAB, the SCSF, in "pseudo kinda sort of" Model View Presenter Pattern usage.  The application that is being developed definitely uses the core of the mentioned products.  Recently as I read some techno babble by Glenn Block who works directly on the factories and tools themselves I came to a scary conclusion.  Several of the prospective issues of our CAB/MVP implementation and to help further a solution for others out there using the CAB/MVP Patterns I figured I'd relate some non-business specific solutions.  The bullet list below is from Glenn's blog entry.

• Ability to support multiple teams developing different parts (modules) in isolation.
• Ability to extend existing and add new modules to the application without recompilation.
• Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars) 
• Standardized and extensible layouts.
• Pluggable UI components.
• Pluggable application services that can be globally accessible such as Authorization and Authentication.
• Separation of UI, Business and Infrastructure concerns.
• UI Testability.
• Reduction of repetitive coding tasks.
• Simplified deployment.

 My fears, the short list, is appended to the respective bullet point listed below.

• Ability to support multiple teams developing different parts (modules) in isolation. 

[Problem][Developers, management, and other powers often push for vertical development either purposefully or accidentally.]

[Solution][When developing against CAB/MVC foundations and patterns the various layers should always be broken out to the specific teams that can best handle and develop against the specific layers.]

• Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars)

[Problem][Often groups tend to accidentally tightly couple things when development is hurried.  When this occurs a major benefit becomes moot.]

[Solution][A person or persons should be delegated to refactor the code regularly to insure that the pattern stays loosely coupled.  This can also be done during code reviews and turned into a great session of to-do and not to-do items.  The key of staying loosely coupled is code reviews and refactoring the code on a very regular basis (weekly) to stay on top of what is going on.]

• Pluggable application services that can be globally accessible such as Authorization and Authentication.

[Problem][If the CAB/MVC is used with an architecture that does not directly allow clear modularized usage of authorization and authentication the CAB/MVC also becomes unwieldy and difficult to manage.]

[Solution][Integrate and create an LDAP based (AD if need be) security integration that can be globally accessible via the plug-able application services.  Either way this scenario is always specific to the particular architecture and pattern implementation of the particular business.  It is very difficult to clearly use modularized authorization and authentication when the application is many layered and complex.  However, when an application is many layered and complex it is even more important that the authorization and authentication ARE modularized.]

Each of these prospective problems is easily overcome with a little development effort and acuity to code reviews and refactoring, but as always should be brought to focus right away to alleviate any magnifying schedule time and costs to a project.

So I just realized the latest SCSF has been released.  This is a software package that we've been using for the entire project that I've been on for almost a year now.  The SCSF has saved us tons of time, even though it is somewhat cumbersome and if one is unfamiliar with CAB/MVP/MVC there is no reason to really dig through it.

There are a few points that I've noted from the various blog entries at Mariano Scklanny's Entry,  Miguel Saez's WPF post, Blaine's entry, and the respective link to getting started with the Smart Client Software Factory.  An install helper is on the Codeplex site also.  Also a bit o' Technobabble is a cool and quick walk through of the WPF & SCSF features.

Major Cool Points That I know of so far:

• Better ClickOnce Deployment Capabilities.
• WPF Support & Interoperability.
• Code Generation Support for VS 2005.
• A better dependency checker (for installation)
• The "Disconnected Service Agent Application Block".  Yeah!
• Less mess during implementation.

Now the biggest problem with all of these cool changes is that they aren't particularly backwards compatible (from what I've read) so these cool new features won't be implemented in the project I'm on.

  Needless to say though, I'm looking into the changes a bit further. 

On the last note I'm gonna throw into this post is that the SCSF is going open source.  Yeah, that's right, open source.  The SCSF Contrib is available with infoz on the CodePlex site also.

Catch the SCSF May 07 download.

Competition is a key factor of the software industry.  It's why the industry can get the talent, people, and entrepeneurial spirit that it has.  A problem has come back that is a familiar beast in the indusrty, everybody is short of 100% on staffing.  The key factors are still there in the staffing needs;  competancy, experience, education, determination, discipline, and of course attitude.  The problem I've noticed however is not the number of available people but the attitude and even the competancy and experience are just lacking.  Lately many candidates that I'm known to come onto projects are billed and sold by recruiters as far more advanced than they are or even sold to positions that the candidate isn't even particularly looking for.

Currently the project I am on has been fortunate to find some great people that are of high competancy, senior level, and also have a great work ethic and attitude.  Our people have been some of the best I've seen in the industry too, no pressure selling here or urging candidates into positions they wouldn't or shouldn't be in.

We're, in addition to having a little trouble finding enough of the perfect cadidates, rocking and rolling with the power team that we currently have.  Patterns and architectural work have been put into place that is allowing us to really start pushing forward, and sooner than later, we'll be providing some real progress on the massive project I'm currently on.  I'll be really happy though when ROI is realized by the company we're working for.  I'll know then that we've done far more than merely build a massive scalable and capable enterprise application, but we've helped improve the world for a few hundred thousand extra people in the world.

If anyone out there is looking for work, and you're a senior level code person that cherishes good code, well written, with patterns, practices, and a good happy hour after work, I think my company is still looking so lets here from you if you're interested in working in downtown Portland, Oregon (the coolest urban environment in the entire western United States).

- Yeah, yeah, Seattle and San Francisco are ok too. 

Martin Fowler hit on some keen topics over the last few months.  I say they are keen topics because they are things that need worked on at the current project I am on.  I must add, we have all gotten much better, but it seems a quick read over of these entries of Fowler's would do us all a little bit of good, reduce stress, solve world hunger, etc.

First Article

The first entry topic is It's Not Just Standing Up: Patterns of Daily Stand-up Meetings (and note, it's not actually by Martin Fowler, but Jason Yip).  This article brings up some obvious points.

Some of the points I think are of important concern are what differentiates the stand up / SCRUM from a regular status meeting.  A stand up is supposed to be short.  Above all it assists developers which are often in ridiculously hectic and multi-task oriented positions, to refocus and prepare for their specific tasks each day.  Without these meetings most developers will get side tracked and lose focus.  Daily scrums prevent this by allowing a clear focus to be maintained.  As quoted in the entry by Mr. Yip, "We want everyone to be moving in the same direction. The stand-up is used to continually remind the team what that direction is."

The other point that is brought up that I feel we all need to work on, that could help out the team substantially is brought up in the particular "feel" of what a SCRUM should provide. 

As quoted, "Quickness and high energy support the goal of setting focus. Long, low-energy meetings tend to distract and mute the day."  We all need to work on our energy an supportiveness in these meetings.  Every person involved in a SCRUM should know that what they are contributing is a vital to the success of the project.  With that they should bring good motivation and a strong positive attitude about what they've competed.  This should be brought up with enthusiasm and any blockages should be discussed without pointing fingers.  The later focus our team has mastered.  Our problem resolution has finally gotten a strong process and is starting to work smoother and faster than at any time before.

This brings up the second point, "Good stand-ups will feel supportive."  Offers of assistance, parallel pair programming, and other efforts should be mentioned whenever applicable during the stand up.  Pointing out the strong players for pieces of technology.  The team at current is fairly decent at doing this, but a little more could be done at some points.  Maybe a little more attention could be brought to this so that strong players could be identified and used better to ramp up new developers?

Also, be sure to click on the link to Yip's write up and read all the way through it.  The "Pig and Chickens" section is priceless!

With that I'll just say, our teams are starting to really kick some code ass.  Our leads, Mr Jim and Mr Eric are doing excellent jobs leading the team SCRUMs.  Some streamlining of teams is still left, but the massive tasks at hand are finally within a reasonable grasp.  We just need to do that Nike thing now and "Just do it!"  (Hopefully they won't sue me for usage of that)

The Other Article

The other article I don't have read 100%.  But is directly related to unit tests and how we're doing testing against our objects and business layers.  I need to finish up the article and then I might have 2 cents to share, otherwise I think I'm familiar with the difference between mocks and stubs so I'm going to read the article and see if I am clear on the topic.

  Weeeehoooo!  Off I go to onto other topics.

Several times on my current project there has been push back and push forward on architecture decisions.  For instance the NxBRE solution, which I was stoked about working on, has gone away.  I am now creating a row based database result set processor instead.  It wouldn't be my first choice in management of unknown rules but sometimes you take the tasks and just run.

With that I will continue my future writings on topics pertaining to my personal project of a Transit Engine.  What I mean by a Transit Engine I will ellaborate.  I am breaking down the technology, politics, economics, and function of transit services, including single occupancy vehicle modes such as automobiles, and building an object model, prospectively an API/SDK, application, and other pieces that will be able to work together to model logistics and transportation around various areas of the world.

So stay tuned and I WILL have some model objects, diagrams, and other cool info related to my ongoing project.

So after a far longer process than I originally had planned on (fortunately I had saved a ton of time by using a prebuilt solution such as NxBRE) I acheived a building integration of the NxBRE Project into the primary Visual Studio Solution.  No particular fault of NxBREs it is just that some of the references and other items got fubared when moved across.  That leads me to...

...Visual Studio Team Server's Source Control would NOT let me just add the project.  I'm not sure what the deal was with that, but it was determined.  What I had to do in the end was literally do a manual creation of a project and name it the same, then add all the files as one would existing code files.  After working out the bugs everything seems hunky dory.  Gracious though it was a bit of excessive work that I didn't really need to focus on at this time.

Now that this is done I intend to in the next few days create some examples and stick them up on the site in relation to utilizing NxBRE.

The NxBRE Application is available at the owner Agile Partner's Website.  It is located in a sub path at http://www.agilepartner.net/oss/nxbre/.  To the left of the page one can download the software package via the download link.  The download is provided along with source control by SourceForge.Net.

There are three primary packages to download.  Click the NxBRE download button and you will find the IE-Console, Miscellaneous (Extra Documentation), and NxBRE Packages available for download.  Personally I'd put each download into one directly.  Unzip each respective file into a respective directly within the single directory the files are placed into.

Once everything was downloaded, unzipped, and placed in their proper order I began opening each project/solution to organize them the way I wanted.  The first Visual Studio Solution I opened is 'RuleEngine' Solution.  This solution has an "Examples" solutions folder with a "SpeedTest" project in it and a "RuleEngine" and "UnitTests" project in the primary root of the solution.  Once these projects are opened do the ole' standard "build without errors" routine.  If you don't have NUnit installed the build will break so make sure to get it downloaded and installed.

One thing that is a pet peeve of mine is to have Visual Studio based unit tests for use against projects.  So with the inclusion of unit tests under the NUnit testing framework included, I started working on converting those to Visual Studio based tests.  These I'll post up in my file share section after I complete it.

For now, with the unit tests needing converted, I'm going to get the project building first.  What I did was remove any links to the NUnit testing framework so the solution could build.  I setup a second project that would store untouched, unedited, NxBRE Solution files.  I renamed the solution file specifcally to RuleEngineU.sln just to make sure that I didn't get confused.

After downloading and installing NUnit I set about making sure the project would build.  I wanted to get it to build to assure that I had a good working model to re-write the unit tests in VS against and also as reference for when I create the actual rules engine that I will be putting into production for the project.

At this point I got everything running, created a second solution copy of NxBRE and started converting the unit tests to Microsoft's Framework.  My progress in altering those will be in a follow up entry, for now, lunch calls out to me!  Grub time.