In the DSS world at Intel we have tried several ways for doing logging and program progress reporting - most of the solutions involve writing log records to a table in the DB.  This article doesn’t resolve all those problems, but presents an interesting idea for tracking application progress as well as tracking progress of long operations - Oracle even has a facility for attempting to estimate based on the performance of long running operations how long those operations will take to finish (note that this will not work for estimating when a single SQL statement will return but more for when you are processing data in loops etc…

http://oracleandy.blogspot.com/2006/09/if-only.html

http://www.slowleadership.org - The name of the site may give the wrong impression initially, but I love the stuff that is showing up here - there is a constant stream of good practices to use, keep in mind, etc… - my blog queue has grown huge and this site is one of the reasons - every time I read an article - I’m like - this would be handy for us to remember at Intel.  So this will be my blog purge of the Slow Leadership articles that I have run across lately

• Work Life Balance - http://www.slowleadership.org/2006/09/fads-fashions-and-worklife-balance.html - work/life balance is about who we really are (our values) and less about programs etc…
• Work is not the end simply a means, but the world is rapidly losing sight of that - http://www.slowleadership.org/2006/09/leisure-is-meaning-of-work.html
• Adrenaline Junkies - http://www.slowleadership.org/2006/09/adrenaline-junkies.html - the basic premise is that those who believe they thrive on pressure and work best when under pressure are lying to you - the truth behind them is that they like the rush and so they consciously or unconsciously plan for the rush to have to happen.  A personal comment here would be that adrenaline junkies inherently have a huge variance in their output.
• Short-termism - http://www.slowleadership.org/2006/09/short-termism.html - I have often criticized both in word and print actions at Intel as being short-termish.  The current Efficiency effort would contend that it is decidely not short-termish and at this point I would say it is still up in the air as what it truly is - simply because it is not over and all the results are not known. - But for whatever is said the headcount actions in my mind have little bearing on the overall future results - sure it will save us money and lots of money if you believe the numbers (which I don’t - because I have talked to way too many Finance guys who talk about the reality of those kinds of numbers) - but you could have done that in a layoff  really quick and been mostly right about where and what to cut.  The key to whether the Efficiency effort is short termist or not is if they truly fix the decision making problems that Intel suffers from.  Because let’s be honest - headcount cuts save money and will keep the financials looking good a little while longer - but if we don’t quit making the mistakes that have plagued us for the last 3 years we will find a way to eat up the extra savings (maybe by lost MSS) and be back to the same point.
• Whew - still more to go - here are several more without so much commentary from me
• http://www.slowleadership.org/2006/08/short-term-myopia.html
• http://www.slowleadership.org/2006/08/seeing-in-black-and-white.html
• http://www.slowleadership.org/2006/08/bertrand-russell-on-competition.html
• http://www.slowleadership.org/2006/08/speed-simplicity-and-bad-choices.html

It has been about a month now since this happened and I am only now getting to it which is a shame.  We were fortunate enough to have Randy Miller come down to our Intel Aloha campus in the Hillsboro, OR area and talk about Agile development principles, MSF, and Visual Studio Team System.  We had about 50 developers from different software development groups at Intel attend.  I worked with a fellow Inteler on putting it together and being my first time doing something like that I wanted it to go off well for all involved.  I was pleased with how it turned out.  The feedback I got back was also overwhelmingly positive.  The little “negative” feedback I got also turned out good because it gave me a chance to ask why and understand expectations and have a discussion about the various concepts that Randy presented on. 

        I won’t attempt to document all that Randy talked on – I just wanted to hit the points that stuck out to me

Cadence/Flow
Randy showed how the reports in Team System are set up for you to understand the Flow or Cadence that your project has (Remaining Work report and Project Velocity are two examples of TFS reports that portray this).  Sam Guckenheimer speaks to the importance of Flow in his book “Software Engineering with Microsoft Visual Studio Team System”.  As you reach the sweet spot on your agile projects with iterations, automated builds, etc… you get into a flow and establish a cadence.  This starts to work for you – the whole momentum concept of objects in motion tend to stay in motion. 
I found myself feeling that way with the project that I am currently working on.  Obviously there is variance in our project’s progress, but we are in the habit of producing value regularly at a fairly steady rate.  I find that regular cadence helps me to stay focused and lack of focus is one of the natural variances that comes into play in any software project.  High Quality is implied in Flow since having to go back and rework stuff that was previously believed completed disrupts the Flow. 
Processes can also be major Flow disrupters.  While varying degrees of processes are required depending on the type of business you develop software for - the goal should be to make them as transparent as possible – as much of the process as possible should be automated and happen as granularly as possible.
That is why I believe in Pair Programming – big code reviews don’t work – they just don’t.  Does that mean though that I want developers to just be able to check in changes without another pair of eyes looking at them – no – so Pair Programming among other things helps in this process – you are code reviewing all the time.  It also forces you to overcome those attitude/personality conflicts because you have to deal with them daily.  I think most of us have had the experience of being in a review meeting where someone takes the stand that it is my way or the highway right at the end of a long and arduous release – you sit there thinking – “is this for real! Why didn’t this get brought up weeks ago?”  At that point consider your Flow gone (and perhaps your hair too!).
Well – that is long enough for today – tomorrow I’ll try to cover my thoughts on Personas which was another topic that Randy covered.