Tag Archives: Project Management

Checkin’ Out By Generation

Unlike some others, I don’t get excited about source code management (SCM) systems, a.k.a, version control systems (VCS).  Unless it’s your job to build such things, they’re a means to an end, not an end in themselves.  For me, they’re much like circular saws: I’d better have one when I need it, and it had better work and work well.

I was reminded of that during some merging madness today.  Nearly all of our team’s work is done in source code managed by a very good VCS, but a few files are outside that.  We clashed on those files, so merging and managing them caused far more trouble than it should have.

So it brought source control out of my subconsciousness, and I thought about how different SCM approaches seem to have tracked right along with society’s philosophical trends.  Consider:

– 70s – The Me Decade.  The move from punch cards and shared readers to private online storage with checkout systems allowed each to “do his own thing” and “discover himself.”  Folks started digging groovy things like SCCS and IDSS.

– 80s – The Mine Decade.  Materialism rules, and he who dies owning the most files wins.  The “personal computer decade” had folks keeping their files to themselves and brought us things like PVCS (“lock early, lock often, unlock never”), and ENVY (“that’s my class, you can’t release it!”).  Gag me with a spoon!

– 90s – The Jam Decade.  By the late 80s (even before Pearl Jam hit it big), this pessimistic locking thing started getting really old, and the collaborative “web decade” saw SCCS revived as RCS and then CVS.  This had optimistic checkout as the default, and sharing and merging was expected.  Continuous integration became cool, as developers could know wassup with their homeys.  Word, dat’s phat!

– 00s – The Whatever Decade.  Early in the decade, Subversion began to loosen things further.  And soon, in postmodern fashion, everyone wanted his own version of the truth.  New distributed version control systems (DVCS) like Git, Mercurial, and Monticello followed, elevating the old idea of a change set to a legitimate stream of development.  This “truth depends on who you ask” approach was fast and flexible.  That is, until integration/build time, when only one right way must prevail, and everyone must merge onto the narrow path.  Often it would come down to trust: use the code from your sweet peeps, and ignore the n00bs.

So what will the 10s be known for in source control?  I suspect DVCSes will continue to grow, led by ever more open source projects using them.  Since this is becoming the “borrow and bailout decade”, perhaps we’ll see seamless integration with shared repositories of common code fragments.  Check back in 2020 and I may write about it.  That is, if I’m not so busy sawing away that I don’t really notice.

Starters and Finishers

Mariano Rivera is arguably the best closer of all time, with credentials that include a 0.77 ERA across 76 post-season games.  Yet with a 5.94 ERA as a starter during his ML rookie season, he was only allowed to open ten games.  Mo can’t start, but he can most definitely finish.  Even this Braves fan must acknowledge that.

Starters and finishers also clearly exist in the world of software development.  I was reminded of that this week when a developer proposed changing a few accelerator keys (shortcuts) on menu picks, and a detailed dialog and email chain followed.  Since I originally designed and built this system, I often either specify or review proposed changes.  But in this case, I honestly didn’t care, and refrained from commenting.  Yet, I’m eternally grateful for those who do care about such details.

I’ve had the pleasure of working with many developers who excel as finishers.  They’re not plagued by the “not invented here” attitude that often tugs at starters like me.  Rather, they’ll take something over, make it their own, and tirelessly extend and support it.

Understanding “starter” and “finisher” personalities can help when staffing a well-balanced team.  Martin Fowler describes starters as having the enabling attitude, while finishers possess the directing attitude.  Starters make good architects, business analysts, designers, and trailblazers.  Finishers make good project managers, maintainers, and support engineers.  Nearly all software organizations need a good mix of both.

But we should avoid caricatures.  This certainly doesn’t mean that starters never finish anything and finishers never start anything.  These labels shouldn’t excuse procrastination (by finishers) and incomplete work (by starters).  Starters should be required to stay with a system until it reaches maturity, and finishers should brought on early enough to understand its design and rationale.  I’ve started about a dozen new large systems (and a few dozen smaller systems and feature packages), and have enjoyed staying with the products through GA of versions 1.x, 2.x, and 3.x.  But my fondest memories are usually of early milestones (internal and alpha versions like 0.1 through 0.8), although these required a lot of round-the-clock hard work.

These personalities should also not be confused with quality measures.  It is simply wrong to excuse poor quality from a starter because, “a finisher will clean it up.”  Saves are exciting in baseball, but are poor process in software.  Yet many finishers do have extra perseverance to help close the final details.  For example, I’ve known finishers who code more bugs than the starters.  But even if it takes ten tries to get it right, they’ll doggedly clean them up.

The symbiotic benefits between starters and finishers are a good thing in software development, and should be encouraged, along with a healthy respect for each other.  Just ask Mo.

Agilefall

The decision came down yesterday: our latest Agile/Scrum project will have to produce some rigid waterfall SDLC artifacts.  We’ve enjoyed a “bureaucracy break” for awhile, choosing things like simple wiki pages and working code to manage and communicate designs, test plans, sprint backlogs, and the like.  But now we’ll have to use some (verbose and redundant) standardized Word document templates for requirements/SRS, designs, code reviews, test plans, test cases, etc.

It isn’t the case that waterfall is “all bad” and agile is “all good”; rather, it’s easy to forget the motivation for each.  First, keep the paying customer happy, then place the emphasis on elegance and “the simplest thing that could possibly work”, and then let form follow function.  Whether the deliverable is a wiki page, Word document, Visio graph, UML diagram, EA model, xUnit, script, or code, pick the best tool for the job.  But don’t, for example, use outdated templates simply for standardization’s sake.  The mindset that emphasizes style over substance is the same one that measures lines of code rather than capability: increasing bulk without adding value.

I sometimes have to combine waterfall and Agile techniques to keep multiple stakeholders and competing interests satisfied.  And it doesn’t have to degrade to “agilefall” or “wagile”; there are ways to successfully blend the two.  For example, go ahead and develop a high level multi-sprint plan and stuff it in Microsoft Project if forced to.  But only define sprint goals and high level content in advance.  Don’t pretend you can predict detailed tasks six months in advance; rather, plan each sprint as you get to it and fluidly adjust the backlog as needed.   Go ahead and write that big spec and design document (to satisfy a contract or pre-paying customer) before starting your first sprint; just use a lightweight change control process to quickly include new discoveries.

I suppose “agiley waterfalling” is like running a chute: you plot out your course and pretend you know exactly how you’ll do it.  But the details of the run will be a wild blend of surprises and adjustments, with some boofs along the way.