Something that has work very well for me is a brown bag learning session.  You can start this in your own workplace.

What material to use:

• A book
• Read articles
• Bring a video

Youtube.com and many other sites have technical videos available.  A video is nice because there is minimal preparation required.  You will need a screen or projector for showing the video.

As with videos, articles require you to find a new one each session.  They have the added expectation that participants read it before hand.

A book is nice because you can go through a topic together, building as you go.  Let the participants choose the book if possible.  I usually select a wide variety of topics and choose books for each topic.  Give a link out to a good book store site so they can check the overviews and reviews.  That way they will have more “buy in” to the session.  Be open to choosing something that you might not normally choose as well.  If the majority wants to learn Perl and that is not your main interest, go with the Perl.  You’re topics will come soon enough.  The “learning culture” is more important then the individual topics.

When to do it:

Some companies will give work time to this sort of activity, some may not.  If your company gives you work time, fantastic.  Personally, I think that brown bag lunch sessions work just as well.  People should be willing to give up some personally time for enhancing their own learning.  Doing it during work time may make it something you “have” to do versus something you “want” to do.

Who buys the material:

If you want to go through a book, get with your manager.  Propose that you will lead the sessions and the company buys the book.  Explain that it is low cost training.  Some book stores may give a discount if you purchase all the books at once.  If management won’t approve the purchase of the books, explain to everyone that books are fairly inexpensive and their new skills will be far greater then the price of the book.  Then, try to stay away from $70 books, unless they want them of course.  There are lots of books in the $25-$35 range.

What if no one shows?

Don’t get discouraged if there is limited participation.  Commit yourself to keeping it going.  It will grow.  Keep it at the same time, the same place.  Show that you are willing to stick to the learning process even though participation may be a bit slow.

When, how often:

I prefer once a week.  If that is too much for everyone however, make it twice a month.

You don’t have to know the material cold.  However, you should be able to research and help find answers to questions.  After all, you are learning together.

Some technical books may present some challenges.  It helps if you have some people in the sessions that can generally learn the material.  If everyone struggles with it, or they don’t have enough extra time to really understand the material, you may have to move it to more of a teaching situation.  Of course, teaching means that you need to understand the material enough to teach it.  For one session I did, we went through a book on COM (yes, quite a few years ago…).  The sessions went well until about Chapter 5.  Then the blank stares started.  We muddled through, but it was tough at times.  Which brings up another point, don’t be afraid to stop a session if the book is too difficult to understand, too boring, or just too far outside the sphere of relevance.  You can start another one.

When that session is done, start a new one.   It’s ok to take a small break in between, but keep them going.  Your goal is at the end of a session, to have folks ask “Hey, when is the next session?”. 

Be a good facilitator.  Be prepared to keep the conversation going.  Have some questions ready.  Ask them questions about statements they make.  Try to get the more quiet ones involved by asking their opinion.

As you get steady participants, try switching off.  Ask others to lead a chapter or an article.

If you want to change to a “learning culture”, it has to start with you.  As Mahatma Gandi said, “Be the change you want to see in the world”.

May the bugs in your code be few,

Scott

Jason Dean and the ALPN group is leading a series of workshops on Agile practices.  They are designed to proceed from entry level discussions to more advanced.  Look for more information on further workshops.

For more information, checkout:

The website: www.agileboise.org

The ALPN Boise Google group: http://groups.google.com/group/apln-boise?hl=en&pli=1

Originally titled, “Dr. Dobb’s Journal of Tiny BASIC Calisthenics & Orthodontia“, I have been an avid reader of the magazine for many years.  I believe I first subscribed around 1992.  (I still have the old copies.

I’ve seen other magazines come and go as well.  Software Development was a favorite, as was C++ (formerly C) Users Journal, Windows Programming Journal and a few others.  All have all gone away.  Some were merged into Dr. Dobbs.  Additionally, over the past few years, the print version of Dr. Dobb’s Journal has gotten smaller and smaller.  For the time being, at least MSDN Magazine and Communications of the ACM are still available in print.

I suppose this is the way things are going.  With so much on the Web these days.  Newspapers, magazines and other hard media are having difficulties competing with the cheaper web publishing.  I may be a little old school, but I really enjoy a magazine.  You can take it anywhere.  You can read it over and over again.  I can sit in the easy chair with a cup of tea and enjoy an article or two by my favorite authors.  Reading it on a computer screen never seems quite the same.

While there is lots of information out there, many times the web seems a lot like cable TV, there are lots and lots of channels but very little on.

Maybe it’s time to reconsider that Kindle. 

I do hope you all have a wonderful 2009.  May you all enjoy life and what you do in it.  May you grow and learn lots of new things. And may your software have few bugs!

Scott

Well, I too enjoy my job and the company I work for.  I’m not talking about finding a new job, I’m talking about managing your career.  In this day and age, individuals need to take responsibility for career management.

A good time to review your resume is once a year, around review time.  I know not all companies do yearly reviews.  Maybe the review you get is not as valuable as it could be.  Regardless, set up your own time to review your career progress.

In the book, Debugging the Development Process, author Steve Maguire talks about a person with five years experience.  He makes a distinction between a developer with five years of experience vs “one year of experience five times over”.  Even though a developer has five years of experience, he may have done the same basic tasks for five years without increases his skills.  Another developer that has 2 years experience that has grown her skills each year may have more “real” experience then the person with 5 years.

Start now.  Dig up that resume.  Update it so it reflects your current experiences.  Take a good look at the what you have done in the past year.  How have you progressed over the last couple years?

Next, set up some goals for yourself in the next year.  I like to focus on four general areas:

Technology:  What technologies should I make improvements on?  What new technologies are coming up?  How can I better use current technologies?

Processes:  Learn about new agile methods?  Learn about how others are using the methods and improving them.  Learn a process you may be less familiar with like configuration management techniques.

People skills:  Don’t forget the soft skills.  I’m not necessarily talking management here (unless that is your goal).  Leadership can come from anywhere.  Unless you are a “one programmer team” you work with others.  Whenever you are attempting to influence someone, you are using leadership skills.

Business:  We don’t work in a vacuum.  What business is my company in?  What areas of that business can I get a greater understanding?

Once you have a list of general topics you want to focus on, make then concrete.  Pick enough that pushes you to grow in the next year, but not more then you can effectively commit to.

Next, make each goal measurable.  Write down something that you can do in the next year.  Write the goal such that it is obvious when you done.

Put a date with the goal.  If the goal has multiple parts, put dates to the sub goals as well.  For example:

Technology goal: Attain a greater understanding of Multi-threading in .NET.

• Research and choose a good book on Multi-threading by <some date>
• Read the book by <some date>
• Choose an application in which to use your new skills by <some date>
• etc…

People skills goal: Improve communication skills.

• Choose a topic you can present on by <some date>
• Prepare a presentation by <some date>
• Present to your peers at a lunch-n-learn by <some date>
• etc..

Next year, you can review the goals you accomplished and add them to your resume. 

These goals don’t all have to be specific to the company you work for.  It makes sense that they are so you can improve your career opportunities there.  However, add some personal goals as well.  I might want to learn a new language like Ruby or Python even though my company is a primarily a Microsoft shop or learn the.NET framework if your company is a Java shop.

You have to take charge of your career.  Your company may or may not take an active role in this.  Like many things in life, if you don’t manage it, it will most certainly manage you.

An Open Spaces session is a discussion where the attendees generate the topics ( http://en.wikipedia.org/wiki/Open_Space_Technology).  There will be no presentation, no lecture, no Powerpoint slides, etc.  The main point of this is a discussion were all can grow and learn from each other.

The topics for discussion will be created by the group. The discussion will be facilitated, but just to keep the conversation going, not to drive it in any direction.

It will be held at the same place as last time, Casa Mexico Restaurant in the Hyde Park section of Boise.  There is a banquet room in the back.  They offer beer and wine in addition to the great “South of the Border” food.

Location:

Casa Mexico Restaurant

1605 N. 13th St. (Hyde Park) (Downstairs in the brick building)

Boise, Idaho ( casamexicoidaho.com )

http://maps.google.com/maps?f=q&hl=en&geocode=&q=casa+mexico+boise,+id&jsv=112&sll=37.0625,-95.677068&sspn=47.838189,80.068359&ie=UTF8&latlng=43630254,-116203330,16920108175405857923&ei=BHo0SM6PEZv2iwOctrWxCg&cd=4

When:

Tuesday evening, December 9th, 6:30-8:30.

We would like to get a headcount. If you would like to attend, please RSVP at scott.schimanski@gmail.com.

Bring your great ideas and a willingness to share.

Scott

One of the most powerful aspects of agile development is iterative development.  The idea of taking a large development effort and breaking it into distinct smaller efforts.  Those efforts are then planned, committed to, worked on and completed.  You know the drill.  But it’s not just the coding that’s done, but all the work, including testing, documentation, install packages, whatever it would take to make it usable in its final destination.  It may not be feature complete.  In fact, most iterations won’t release something that is feature complete.  But, the features that are there work as they are expected to.

A large problem with large development efforts (think waterfall) is they take so long between starting and when something is “done”.  That long schedule greatly increases the risk that things will go wrong.  And much worse, you don’t know it went wrong until such time as it is much too late to mitigate the problem.

Johanna Rothman, project management consultant, uses the ides of inch-pebbles.  If you can not estimate to milestones, go to inch-pebbles.  Meaning, take smaller pieces of work until you get to an effort/time combination that you can estimate with a feature set you can commit to.  And then, make it happen.  Get the work done, not just done but “Done”.  If you are still seeing challenges in meeting the commitments, break things up into even smaller chunks with smaller measures of time.

“Done” allows you to see exactly where you are. Many things may appear to tell you where you are in the project including status meetings, reports, hallway discussions and morning scrum meetings.  But there is nothing like having something “Done” that tells you where you are.  You can see what is done, look at what was expected and then make decisions as to future expectations.   I remember an old joke where the comic talks about the typical weather man that says “How’s the weather?, lets go the map”.  The weather man brings up the map and talks about barometric pressure, temperature and dew points.  The comic says, “Go to the map??, Let’s go to the window”.  Many metrics can be helpful, but there is nothing like knowing where the actual product is at that time.  And that is the power of “Done”.  You can see what is done and what is not.

When the terrain and the map to not agree, trust the terrain.  Knowing what is done, is like seeing the terrain.  It is reality.  Scrum meetings, reports, etc are maps.  They have some information, but it could be wrong.  Knowing what is “Done” and what is not is realty.

If is not “Done”, that is not bad, it is information.  If you treat something not “Done” as bad information, you risk alienating the messenger.  In fact, be glad you got the information.  You have something you can use to improve the outcome.  You can regroup, understand what happened and make course corrections for the future.  Without the information, you have nothing to act on.

Don’t just be kind-of-done, or sort-a-done with that task or story.  Be Done!!

Thanks to all who attended the open spaces session last Tuesday evening.  There were a few less folks there then the previous session, but it was great discussion non the less.

Our topics included:

• Challenges with team acceptance of Unit Tests/TDD
• Unit test coverage tools
• Poor mans adding architecture with IOC
• How to make sure you definition of “done” is adequate?
• Plus many, many others we did not get to…

There was lots of great information passed around and good food as well.

Seeing that we had less participation then before, I’ll try something else for next time.  I’ll create an email list of those interested in addition to the blog post.

I look forward to seeing everyone at the next Elegant Code Open Spaces session, December 2nd. 

An Open Spaces session is a discussion where the attendees generate the topics ( http://en.wikipedia.org/wiki/Open_Space_Technology).  There will be no presentation, no lecture, no Powerpoint slides, etc.  The main point of this is a discussion were all can grow and learn from each other.  We plan on holding these once a quarter.

The topics for discussion will be created by the group. The discussion will be facilitated, but just to keep the conversation going, not to drive it in any direction.

It will be held at the same place as last time, Casa Mexico Restaurant in the Hyde Park section of Boise.  They offer beer and wine in addition to the great “South of the Border” food.

Location:

Casa Mexico Restaurant

1605 N. 13th St. (Hyde Park) (Downstairs in the brick building)

Boise, Idaho ( casamexicoidaho.com )

http://maps.google.com/maps?f=q&hl=en&geocode=&q=casa+mexico+boise,+id&jsv=112&sll=37.0625,-95.677068&sspn=47.838189,80.068359&ie=UTF8&latlng=43630254,-116203330,16920108175405857923&ei=BHo0SM6PEZv2iwOctrWxCg&cd=4

When:

Tuesday evening, September 9th, 6:30-8:30.

We would like to get a headcount. If you would like to attend, please RSVP at scott.schimanski@gmail.com.

Bring your great ideas and a willingness to share.

Scott

Mr. Jeffries said “If there is a QA interval planned in the project, we believe it causes programmers to do bad work, because it makes it too tempting to skimp a little bit on doing the job right so as to get things done”. 

If there is a test phase or iteration, in the project, will the developers will cut corners because they know a testing phase will find the issues?  Will they will focus on getting the development part of the work done and less on a fully tested product?

Even if you don’t have a distinct QA phase after the iteration, this can still happen if you have testing members on the team.  The developers may not pay attention to the quality as heavily, because they know a tester will look at the product.

Does this mean that we should remove the testing phase?  You might think it would shed light on the problem.  I would think carefully before doing that.  You might pull the rug out from under the team.

Mr. Jeffries goes on to advocate the importance of completing work at the end of the iteration.  The entire story should be complete and ready to ship.  The end product of the iteration must be checked.  Every project manager knows that at the end of the milestone you need to have a way of knowing that the milestone is complete.  If the milestone is less complete then you believe it to be, that will make more difficult to determine the completeness of further milestones.

The team members must take responsibility for their output.  In my first job as a programmer, I was the only programmer on the team.  There was also a single tester and a team of support people.  The support people did some testing on the programs as well.  Incidentally, this is the only team I have ever been on where there were more testers on a team then developers.  If something went wrong, no-one questioned the testers ability to find the mistake.  However, I did get some feedback on my development skills.  Giving me the responsibility for correctness made me test the application even more.

I’ve been in other settings where the developer’s attitude was “software has bugs, that’s the way it is”.  That makes it hard to improve, because you believe no improvement will help.

If you don’t get what you expected, communication can be to blame.  The expectation must be set that at the end of the iteration, the work is done, development, testing, everything.  If at a later date, it is found that there are defects or the story is not complete in some other way, that feedback has to be brought back into the team.  The team must take responsibility for making the improvements in the product and the process.   The team should also look out for competing expectations.  “Get the quality perfect and take on 10 more points per iteration” is a recipe for failure.  The team should make tradeoffs are clearly understood.

There were many great topics suggested for discussion.  Unfortunately, there was not enough time to take them all.  We voted and ones discussed included:

• ORMs
• Teaching ORM
• Which ones (other then .net)
• Roles on a team
• Non-coding architects.  What to do when you are pulled farther from the code?
• The problem of the distant product owner.  How to deal with it?
• Testing
• How to get an organization to do TDD?
• Unit tests.  How to do on legacy code base?
• Testing in an agile environment.  Techniques, tools, etc
• Domain Driven Design

Those that we were unable to get to, but still great topics, included:

• Dynamic Language Features.  Duck typing, ext methods, etc  Good, bad?
• Error handling techniques
• Model/View/ViewModel

Again, many thanks to all who participated.  There were great discussions.

We will set these up once a quarter.  If you have any feedback on the session, venue, discussion, etc please send it my way. 

See you next quarter (first Tuesday in September timeframe)!!!