If you take the approach to clean up after yourself as you progress through whatever maybe your daily routine, and create this good habit for everything you do, you’ll end up avoiding what is almost unavoidably natural for most of us: procrastination.

Whether it is while you cook, write code/implement software solutions, do the laundry or go though things on your desk at the office, if you let things pile up… well, you’ll end up with a pile of <insert appropriate noun here>.

Why not keep your projects, solutions, classes, layers, frameworks, third party components et.al. in an organized manner right off the bat?  Regardless of the size and scope of the project, platform or technology…  Why wait until it becomes a tangled mess of bad historic legacy waiting… clamoring for someone to come in, criticize, refactor and “waste time” cleaning up your mess?

Why wait until your roommate, spouse, parent or sibling comes around and has to deal with piles of dirty dishes, filthy counters or messy bathroom?

I believe it is one of the easiest forms of procrastination to avoid with the highest payback in quantity, quality and immediacy of satisfaction.

Be it with the proverbial or actual dirty dishes, don’t be a slob, love yourself and those around you and Clean as you go… whatever that may end up being.

There is no other way to put this before I delve into the details: You (as a professional developer, product owner, product manager, software practitioner in any ability) owe it to yourself to read this book… that is, if you are anything like me and reading about all of these tidbits of software development history while getting a degree of insight into the process of an "organized" open source project, in any way call to you.

There is a little bit of everything here, presented in a narrative that is pleasant to read, and with the right amount of abstraction to keep you at the right interested at the right level without too much detail making the reading terse.  I almost [ALMOST] gave it to my wife to read, only until I was deeper into the book itself I reluctantly admitted it would have not have appeared as appealing to her as it was to me.

The [story] follows a team assembled and funded by Mitch Kapor, in its quest to create the open source product that would Chandler.  In the process, the OSAF is founded as the backbone supporting and governing the efforts.

Their trials and tribulations make up the narrative's main thread, but the vision, the lessons learned, the passion that one can feel jumping off the pages from those involved in the project and who wanted it so badly, was what made this a page turner for me.

Needless to say, the stories, the citations, the anecdotes surrounding all of those who end up intertwined in the process, as well as all of those that emerge from the story itself, and some of what otherwise would be considered useless footnotes in the history of software development, spoke to me, enticed my curiosity for wanting to know more about them and motivated more than a few searches and articles to be read parallel to and after finishing the story.

The book was published in January of 2007, and covers the project time (including vision and conception) spanning 2001 to late 2005, where the book sort of trails off and never quite has what one could call a "written form of closure". 

The author, Scott Rosenberg, sort of ends the book with a couple of chapters that are full of historical (albeit somewhat relevant) notes and an observer's retrospective analysis which are probably more subjective than actual factual conclusions.  I don't mean and certainly don't intend this to be criticism to the book itself or to the way he (and his editors) chose to conclude the book, but I would have liked a cap on the story more fitting to the initial heart beat of the book, one that would give the story it own identity, a beginning and an end.

The project itself is still alive, the product is available but beyond knowing that I would suggest that if you intend to read the book that you don't spoil the whole experience of reading the book by "catching up" on where the project is at currently.  I can share with you that the many players in the story and the project are interesting and up until the end they "all" came and went.  An interesting note worth mentioning is that a good number of the people involved in this project are the same "core" that brought us Firefox.

You can read it as a story, you can read it as a use case, you can read it as a diary of a software development project, you can read it as a text book that is 100% pragmatic, but nonetheless I recommend you read it.

You can find other reviews here, here, and here.  More opinions will for sure confuse the heck out of you, so go right ahead and read them all!

The book's main site is kept by the author at Dreaming in Code, available on Amazon or you can just let me know you want to borrow it!

In our current project we've been averaging about 7 minutes for our daily scrum standup. 

We kicked of this project Mid April, and are currently in our 2nd sprint.  So far the length of the standup has remained consistent, and this speaks volume on how the department, the team, the individuals have "gotten" what the standup is all about.

Standup meetings for our previous project took a long time, several times it went over 30 minutes and up to 45 minutes, for reasons I can chalk off to:

1. The size of the team:  We'd have at times upwards of 20+ attending the standup.
2. The team members interpretation of the purpose and value of the daily standup.
3. The overall lack of experience with agile practices and internal process immaturity.

I was often a violator of the "rules" that govern the dynamics of the standup.  Keep it short and to the point turned into discussions on implementation approach, use of technology and discovery and issue resolution on the spot.  Big no-nos.

Still, out of these sweet and short 7 minute standup, I know I am the big mouth.  Those of you that work with me or have in the past, know that I can talk anyone's head off when I get into it, so I am diligently working on keeping my status short, relevant and meaningful to the other participants, which means very little tech talk, acronyms or developer specific content.  Remembering the standup is about the project team progress update and not about the development team update is something I need to remind myself daily.

I want to summarize my lessons learned into the simple bullet point advise as I'd like to share it:

• Keep teams small.  This should be guided by the projects needs, common sense and some "best practices". I'd say an "ideal" team size would be between 2 and 4 developers a QA resource, one or two BA, one or two sponsors/product owners and the PM... a total of 6 to 10 total team members sounds about right.  We currently have 8 out of the 9 team members participate consistently in the standup.
• Remind everyone about the 3 points each member should be talking about:
  • What did you do/accomplish yesterday
  • What will you be doing today
  • Do you have any impediments that the PM or the Lead need to be aware of so that they can do their best to remove it for you.
• Be patient: Give yourself and your team the time you need to work out your own kinks.  Don't give up on the standup.  Find your own pace, your own style and your own way of doing it but by all means keep the spirit of the practice in mind at all times.   It is about communication in its best and most effective form, the face to face.

I like the goal and benefit stated in this definition of a standup according to the Extreme Programming (XP) site:

The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length

A good read to get the gist of what the standup should be is this article by Martin Fowler.

I am not taking about managers managing a team of OO developers here, I am talking about managers that think that practices and tenets of OO apply and benefit the process of managing a team of smart developer... things like encapsulation (secrecy, mysteries, a lot of closed door meeting), loose coupling (I don't really care about how or what you do, just do it), and lets not bring up Polymorphism.

In the interest of full disclosure, I currently work for an organization that is 90% (roughly?) "there"... we do keep a very open channel of communication, and open door policy does not mean "wood plank at office threshold is ajar".  There is still a little bit of mystery around some initiatives and decisions, but that is almost understandable given history and culture.  This post is NOT about my current experience, it is an outlet from accounts elsewhere that are not foreign to me by both direct and indirect experience and exposure.  Luckily most of this BS does not have a current effect on me, but because it HAS and because I feel for those who have to put up with this idiotic approach, I feel inspired if not obligated to express my opinion about it.

In all seriousness, there just isn't room in a team you want to make cohesive for unnecessary bullshit, mysteries or the dreaded "on a need to know basis" line.  If we want to work together as a team, and we are striving to foster open lines of communication with the introduction of Agile practices, there just isn't room for private meetings or delivery of information in a delayed and layered fashion. 

What is it that is feared?  Are we in a world that is THAT paranoid that we think we have to "protect" ourselves from the people we let into our own "home turf"?  If you don't trust them, then why did you hire them in the first place? 

When smart people get fed crap, the immediate reaction is anger.  There is the sense of being insulted and then devalued and then unappreciated and then ... you get the point.  When they feel this way, the natural tendency is to seek this information out, generating an environment of gossip and conspiracy theorist.  You'd want to know what the heck is going on, period, whether it affects you in any way.  Your first and perhaps more natural reaction is defensive and then perhaps proactive: What can we do about it?  How can I contribute, help, be a force acting to obtain value through change.  But most of these reactions go "unnoticed" or in the best (worst) scenario only viewed as negative/punishable/unnaceptable behavior on the part of the developer.

The context to which this opinion applies or better put is intended for, is that of the professional applications/software development world.  Developers, Architects, Database Administrators, IT guys and gals.

I would like to see the day organizations hire people they can trust.  You should be hiring Professionals, not monkeys.  Professional in my book is not defined by how old you are or how many years of experience you have.  If you are an unprofessional loser right out of college, or in the absence of formal education, during your 1st year at your 1st job in the trait, then nothing will change 10, 15 or 20 years later.  You'll just be the same loser with less hair or more gray hair, or more wrinkles and a pot belly.

If as a manager you have an opinion about a team member that is relevant to your environment, the business or the project, just say it, splat! flat out, not PC, no sugar coating the negative or adorning the positive.   I am not foreign to seeing managers calendar's full of private meetings & "checkpoints" on people.  How insulting is that?  Of course you "have" to make it private because its idiotic to have checkpoints on anyone to begin with!

My pet peeve extends to include common "controlling" type activities such as "web content filtering" or super strict PC usage policies.  If someone is dumb enough to look at inappropriate material (porn, warez, take your pick) while at work (because what they do in the privacy of their own home is their business) or is prone to click on dancing bunnies, you'd probably want to find out sooner rather than later wouldn't you?  Or would you just rather have a false sense of control of a wondering mind by administering smaller and continuous shocks?  I won't fear repeating myself here: If you hire true passionate professionals, this is a non issue.

Hire with confidence and trust.  Assume the best, not the worst.  Measure, keep an eye out for red flags, sure you just can't turn your back on it just like that, but don't bring forth paranoia a the de facto management style, bring, seed Trust and you'll harvest good will, productivity, sense of belonging.  If a person betrays that trust, then act accordingly. This brings home the very important sense of accountability.  I am not advocating be a push over or a tyrant, find your own style, your comfort zone for dealing out consequences.  Each person, each organization should have a defined threshold for tolerance to *these* issues we are talking about here.

Good 'ole "boys" clubs don't work, they segregate, they devalue, they demean.  It is very much Binary.  It sends the signal that if you are not "in" then you are "out", and so, what are you to expect from those that are "out"?  Do you think you can expect, let alone demand loyalty?