A Wikipedia One Up Isn’t Sufficient For Your Resume

November 13 2009 by B-Drive in Workplace |No Comments

It’s not in the nature of most people, developers even more so with our huge egos, to admit we don’t know something.  But if you have a life outside of your compiler, you know that some things can’t be read about; they have to be experienced.

For a while recently at a place called Ingenix (United Health Group) I was a development manager dropping in Scrum and Agile practices.  I came to a few realizations:

  • Many say they know how to do Agile, but they do not.  They have not experienced it, and they have read to little about it and reinterpreted what they read into their own understanding (thus learning nothing).
  • The struggle at most organizations is to get the correct tooling to support doing Agile.  This can be CI servers or even the availability of freakin’ meeting rooms.  Without these basic simple things the modern practices of Agile, or any new way of doing things, will fail.  Again it ties back to the simple pattern of learning just enough to be dangerous, but not enough to really understand.

Simple as that.

This stuff is difficult too.  If you want to use Maven on a project, it can take months.  Try telling a VP you want to drop his investment in CVS to switch to Mercurial.  Sit in a scrum with scrum-inexperienced team and watch the waste of time add up.  At my first United gig the scrum master made us report to the business in non technical terms for 45 minutes each day.  We were not allowed to talk to each other as developers . . . we had to do it after, another 15-30 minutes.  Yeah . . a big WTF … One hour everyday of meetings versus the old waterfall one hour every week?  And this person was certified!  (Maybe sometime I’ll discuss the “spirit” of all this, which seems to be more dangerous than just plain ignorance of methodology.)

I am currently working a gig trying to assist a bit in adding Agile practices to their structure, but it has been near impossible.  People get all pissy if you try to “coach” them as to simple meanings of things.  And then, they say the processes fail.

Examples:

  • One developer started listing things like “gather requirements for migration” and “code daos” as spikes.  Spikes are proof of concepts, not actual tasks.  Spikes are like “see if Mercurial will offer something that CVS can’t.”  Etc.  I got my head bit off.
  • TDD.  Oh how I hate it for fuzzy logic workflow/user gesture driven software.  But you ask any of the developers around my current place and they are “experts” on TDD.  “Yeah we’re writing unit tests.”  That’s not TDD!  If they have not done it for real, just read a one-up wikipedia page, then nothing is brought to the table.  TDD is a design methodology – you write a test, then write code that breaks it, then fix the test with the code.  Its not by any means the same thing test-after-development; and it has to actually be experienced day in and day out to fully appreciate its pro’s and cons.
  • Same with pairing.  Pair all day for a few weeks, see what that’s like.  Pair when you do not want to pair, pair with someone you do not like . . . until you do, its just something you read.

My advice is this: remain open minded about these until you’ve actually experienced these things. If you lie about it you are damaging the project and the relationships around you at your gig.    After all, we are supposed to be the modern day rationalists, right?

Darcs Distributed Version Control

November 6 2009 by B-Drive in Tools |No Comments

In my search for easy to use technology I decided to use the darcs distributed revision control code repository to maintain some of my work-usbstick-website–home files.

What darcs is:

  • It’s an easy to use, distributed, code repository.  It falls into the same category as Mercurial,GIT or Bazaar.
  • Distributed?  Yes, patches are exchanged between repositories and there is no one single “mother”repository.
  • Super lightweight; runs locally, super portable, cross platform, and easy to learn. The download is 4 megs.
  • A great introduction to the world of distributed reversion control.
  • Doesn’t do anything to your existing folder and file structures (non-invasive).

What is a distributed respository?

Hmmm . . .this definition is different depending on where you look.  Even as of this date (nov 6 2009) Wikipedia doesn’t have a good definition.

Here is my definition:

  • Not tied to a central repository.
  • It’s faster.
  • Easier to branch.
  • Work offline and still create commits.
  • Distributed backups — everything is a working copy.
  • Collaboration between developers without checking into central copy.
  • It can run locally, easily (especially darcs).
  • Useful if you are working on a module with a small team within a larger team, and want to revision/track changes with each other but not the full build.

I think subversion is a rock solid repository, and quite honestly, I am not a proponent of using technology for its own sake.  The simpler the better. But the future seems to be distributed repositories and maybe with teams working remotely from each other, the advance of SOA, etc. these types of tools will make more sense.  I suggest trying out darcs just because it gives you an idea very quickly what these are all about.

Repository Workflow

  1. Clone a repository to your own repository.
  2. Work in the clone — which is now your working copy.
  3. Check in and out of your working copy from your IDE/cmd line.
  4. When you are ready, commit those changes to another (or original) repository.

One way to look at this is, the “central” repository is the build server’s repository, and you have your own.  But just remember, the only thing central about that repository is that everyone agrees its the place where production bound code must end up.

Maybe this sounds disturbing.

In the “old” days the shops were so used to having copies of everything out of fear of a developer “getting hit by a bus” (which is code for: corporate culture does not trust anyone at all).    Honestly, I have yet to see that scenario. But it does lead us to something I haven’t seen discussed too much:

Best Practices Using Distributed Reversion Control

I haven’t thought about this much until now, but here are some of the guidelines I use for a distributed system.

  • Refresh/rebuild in the morning.
  • Check in when you get a meaningful amount of work done.
  • Physically back up your directories
  • Exchange your patches with your team (distributed backups).

Sometime when working in a continuous build environments, I will check things in with my feature sets turned off . . . but usually not, if they are not ready.  Also, you can keep a backup of workin progress in another of your own distributed repositories on a network drive (in addition to your local).

Back to Darcs
The scenario I describe here would be using darcs to sync files from an html blog between your local machine and a usb stick. Let’s assume you have some files at x:\usb\blog and locally, you want to work on them at c:\local\blog. (I actually use this method for a tiddlywiki “getting things done” piece.)

Download darcs and decompress to a desired location.  Add the directory to your path.

Create your first repository.  Navigate to x:\usb\blog and type:

darcs init

Next, recursively add all the files and folders from there:

darcs add -r *

Notice that it skipped all the _darcs files created from the init command!

Run this:

darcs whatsnew

And you can see all the new files and folders you added. But we haven’t saved yet, we have to do this:

darcs record -a

You get asked a few questions (which can be set on the command line as you get better with the tool) and its all checked in!

Time to get a copy of this repo to the local.

Navigate to c:\local\blog (which should be empty) and type:

darcs get x:\usb\blog

You have a local copy! Make changes in your existing files there (on c:\local\blog) and when you are ready, check in your changes:

darcs record -a

And then run this to propogate those changes to your usb stick — first change directories to x:\usb\blog and run:

darcs pull c:\local\blog

And both repositories are sync’d up.  I wrote a little batch file in my case to automate this.

You are probably wondering why in the world I would want to do such a thing.  Well, I can access the files in my tiddlywiki from several spots, and I don’t want a brute force copy over of the file least I lose information.  I need the granular capability  Also I also use it to branch — for instance at year end — very easy!!!

Of course there are a whole slew of other functions but that’ll do.  Darcs is the simplest tool to get your feet wet in the world of distributed version control.

Scrum Schedule In Practice

August 29 2009 by B-Drive in Agile |No Comments

The scrum meeting schedule I set up for my teams at one place I gigged at was as follows, and based on the basic sprint/release cycle.  Our sprints varied from 2-3 weeks; releases usually after two sprints.  After doing 2 week, 3 week, and one month sprints I kinda like the 3 week cycle;  at another place we did two week sprints BUT our team was cranking out code nonstop; we had none of the issues present in the giant health care corporate  IT system (for instance, just to get a DEV server took almost three months).

Of course there were other meetings such as reviews of QA test plans, long term infrastructure meetings and pieces beyond the boundaries of the sprint.

SM = Scrum Master, BA = Business Analyst, the rest should be self explanatory.

Meeting Name Who Occurance Objective
Release Planning Required: SM,BA’s
Optional: Lead Dev,Lead QA		 1-2 weeks before start of Sprint Review and update release/project backlog.
Business Story Planning Required: SM,BA’s,Lead Dev,Lead QA 1 week before start of Sprint Review all stories for presentation at the Story Review, update backlog and sprint story list. Initial estimates.
Tech Story Planning Required: SM,Lead Dev
Optional: Dev Team		 < 1 week before start of Sprint Identify any refactors/pattern breakouts/upgrades/etc. that need a tech story, initial estimate.
Story Review Required: SM,BA’s,Dev Team,QA Team First Day of Sprint BA’s present story documents to team, all details are discussed. Meeting is at least two hours long.
Story Tasking Required: SM,Dev Team First Day of Sprint All stories are initially tasked out, initial task responsibilities are taken by team members the rest are left on the queue.
Daily Scrums Required: SM,Dev Team,QA Team Optional: BA’s Everyday in Sprint, except major meeting days Scrum. The three questions: Yesterday, today, impediments.
Code Review Required: SM,Dev Team Last day of Sprint. Dev team members present to each other their code (Note: these may informally occur as stories emerge during a sprint as well).
Release Demo Required: SM,BA’s
Optional: Dev Team,QA Team		 End of Release BA’s/Team members present application features to usually high level stakeholders.
Retrospective Required: SM,Dev Team,QA Team
Optional: BA’s,		 End of Release Review the process, improve if needed.

The Code Review

August 15 2009 by B-Drive in Agile |No Comments

I like code reviews now days, done right.

Code reviews help to:

  • Add to the support base of the code.
  • Normalize the development techniques on the codebase.
  • Add to team cohesiveness.
  • Help developers develop presentation and communication skills.
  • Force that last 5% execution of the writing of the code.
  • Improve code quality and developer skillsets.

I’ve been and hosted in several different types of reviews:

  • Scheduled weekly meeting.
  • Present-as-it-emerges.
  • Sprint-end code reviews (in Agile).

For these reviews to be successful, I find that these rules of thumb are essential:

  • Developers only.
  • DEVELOPERS ONLY.
  • A place to present; such as a meeting room or a quiet bullpen.
  • Projects rule!
  • Master of Ceremonies: Let the architect MC, a lead dev MC, or rotate through MC duties.
  • Everyone should try to present at some time. Many times there are pairs where a stonger personality will always present.  Hogwash.  This doesn’t help the other developer at all.
  • Food is a good thing to have there.
  • This meeting can last a long time, hours, depending on which review style you use.

Some may disagree with the developers only rule.   But it is essential; this is not functional review its code review and its all about the developers.  Other points of view will create a conflict of interest, especially management, and the goal of the meeting will fail.

« Previous Page