Table or Booth?

Flow Control

"We spend between 15% - 30% of our time dealing with customer or support issues, so we have no concept of uninterrupted development time."

I was told this in a recent email plea from a former developer-colleague-turned manager.  He wanted suggestions on how to role out Scrum in a such a scenario.  My answer, below.
...

Sacrifice a developer to hire two or three Support folks.  You'll be far better off.

This assumes, of course, that you actually have a developer to sacrifice.

For a typical development project, you only really need three to six developers, anyway.  Sure, you'll slow down your rate a bit but you'll be able to do things with Scrum and you'll be way more efficient in the long run.   It's best to let folks be focus on what they do best.

This was one of the biggest challenges I faced in a recent consulting engagement.  The customer simply did not understand the mutually exclusive nature of Application Creation and Application Support.  In mingling these, creation always got sacrificed.  Other than not getting things built, it's really bad for all-round morale.

With Application Creation, tasks are long-running (three to six weeks) and require extended periods of coordinated concentration.  This is what is needed to create a working application.  In a free economy, the salaries of those that are capable of doing this prove that it's no easy thing.

With Application Support, tasks need emergency response.  Turn around time is of essence.  Otherwise, things in Application Support Land may be slow - even a bit boring.  But that's the price of high availability. 

Application Support folks are like firemen or infantrymen.  When issues come in things get hot in a hurry.  And they'd better be ready.  In the end, the customer must be given a fast, satisfactory answer, above all else.

Why not merge Application Creation into the 'slow' times of Application Support, you ask?  Good question.

First off, there's the immediate problem of context switching.  A considerable amount of ramp up time is needed for a developer to reach optimal 'flow', where: their Application Creation tools have the right windows open, the right file in the code base is in view, and the control-flow for a particular area of the code base is in mind.  

By 'area of the code base,' I mean variable names, APIs they're using, the chapter in a technical book that has examples of the kind of problem they're solving and more.  They must remember application framework conventions, team coding conventions, check-in procedures, etc, etc.

I could go on.  In general, the more things a developer can bring into their working context, the more productive they'll be.  For development, there are a seemingly infinite number of things that need to be loaded into short term memory.

Only when all these details are recalled and then fade into their collective contextual background can the developer create new features at maximal efficiency.  When this happens, time begins to fade away.  A new feature emerges.  Then another. This is flow. 

Flow is invaluable to a developer and the best ones know how to block things out to get it established.  Except...

But, then, their phone rings.  It's their manager.  Perhaps, an application support call.  Or, even worse - a manager needing support.

It's as if someone pulled the lever on the developer's flow grid. Click. Baooouump.  Show over.

And we shouldn't forget that ramping-up to an Application Support context has it's own set of challenges! 

Bottom line: throwing the context-switch is enormously expensive.  If I haven't explained it well enough, Jeff Atwood of Coding Horror does a great job in his post, The Multi-Tasking Myth.

Mixing Application Creation and Support is also a tragically inefficient waste of talent.  The Two-Bridges metaphor illustrates this...

Imagine a bridge project.  Like a software application, each bridge is a little bit different due to geographic and demographic variability.  Also like a software application, in the course of a bridge's life it will be designed, built, tested, operated, and fixed.  

Now, suppose a civil engineer has successfully built Bridge A and is now in the middle of building Bridge B.  Note that Bridge A has an automated lane flow-control mechanism for shifting traffic during rush hour.

Who repairs Bridge A's automated lane-control mechanism that has suddenly failed at 4:30 PM due to a power surge?

Right answer: A repair tech.

Wrong answer: The civil engineer who is currently building Bridge B.

If no one else is available, could you pull the civil engineer off the Bridge B construction project for a few hours to fix Bridge A lane changer?  Probably.  He's a smart guy.  Heck, he *builds* bridges!

He wouldn't be the best to make the fix.  He'd need some help from people in other areas of bridge maintenance and may need to scramble to find the right tools.  The repair might not be timely and traffic would still back up.  But one way or another, he'd probably be able to get it done.

Now, imagine that this engineer gets similar, 'urgent fix needed' calls several times a week during Bridge B construction.

The problems with this should be obvious.  Bridge B may never get built.  If it did, it would be impossibly delayed.  This is a staggeringly wasteful and demoralizing use of the civil engineer's time.

The civil engineer is the only one who can make key decisions during Bridge B construction.  He's the only one who can interpret engineering drawings and make on-the-fly calculations for life-and-death structural concerns.  With his frequent absence, Bridge B construction would either grind to a halt or get built with inadequate supervision, thus posing a deathly risk for untold numbers of future bridge goers.

The real result of management policy that uses Application Creation talent to do Application Support is that the Creation talent leaves.  For the organization, it means the end of their ability to build significant, reliable applications. 

In the software industry, for a developer to lose their proficiency due to lack of practice quickly makes them obsolete and non competitive.  This is a risk few, if any, good developers should ever be expected to take.

No 'Team' in 'I': Going Solo with WACD

To continue from an earlier post on the WACD methodology, here are some tips for keeping the pesky 'team' concept from eroding your development sovereignty.

First off, developing applications in teams runs the risk of contaminating your line of thinking with inferior logic.  The fewer people on your team (ideally, just you), the more freedom you'll have to solve problems the right way. 

Sure, developing in isolation may lead to duplication of efforts in your IT organization but that's OK - IT organizations are full of redundant waist and it's not your job to fix it.  Besides your solution will undoubtedly be superior to your look-a-likes.  Everyone will benefit by learning from your example.

Development teams like to second guess each other by doing code reviews.  This is just a crutch for weak developers with no guts.  Be smart and write the code perfectly to begin with.  As you already know, writing near-perfect code eliminates the supposed benefit of second-guessing weasels. 

In the rare case where factors beyond your control caused you to write a bug, you'll be the only one who'll understand it.  Not only is this is great for your job security but it ensures a peaceful debugging process where you're not constantly being asked questions that begin with "Why did you... blah, blah, blah."  So friggin annoying.

Last but not least, teams often talk of 'camaraderie' and 'morale.'  My advice here is simple:  Camaraderie is for commies, morale for pussies.  Don't be either.  Clint Eastwood didn't ride into town with a Cowboy Support Group and neither should you.

Solution to Windows Bug: "The file name is too long"

I couldn't delete a set of files on an old Windows OS because "The file name is too long". After fruitless Google searching, I found the solution and so, am posting here for posterity.

1. Remove any files you don't want to delete (and whose name is short enough to allow this!).
2. Ensure recursive write access in the containing file directory and all parent directories.
3. Starting at the root directory, rename it to a single character, for example 'a'.
4. Do this for each successive sub-directory, marching towards the one containing the files you want to delete. So you might go from a path like this:

C:\some\long\windows\path\to\files\you\cannot\delete

to a new path like this:

C:\a\a\a\a\a\a\a\a\a

5. Now, try deleting the files. If it still doesn't work trying renaming the files themselves and then deleting.

This ended up working for me when nothing else would. Good luck!

Introducing the WACD Methodology

Pronounced 'whacked', WACD is short for:

• W - Wild
• A - Ass
• C - Cowboy
• D - Development

Key WACD Tenets

• Use IDD (Instinct Driven Development). After all, you’re the one who has to build it.
• Always code alone. Other opinions rarely help, so, in the end, they just slow you down.
• Always don’t test. You know what you're doing. Like opinions, this is just more drag.
• Document when asked but never again. You’re not a writer. Who’s going to read it anyway?
• Keep information to yourself. Anything else just risks you losing your job.
• CM with zip. You're stuff is archived. You know where it is – that’s all that really matters.

Benefits of a WACD Team

• Overdue projects
• Low levels of usability
• Lots of application bugs
• Costly O&M
• High staff turnover

Google Mail Up

It's back.  At least, for now.

Google Mail Down

Lately, no matter where you look, the unthinkable is being thought of.

Google Mail has been down for last 40 minutes.  Sitting here at downtown Reston's Panera, I have connectivity to any other site to which whim takes me.  Just not Google Mail.  

Sites like this don't have scheduled outages.  At least this used to be the case.

Generally, I recommend Google.  This most recent email outage is starting to put dents in my trust.  After their Feb 09 outage, you'd think they would've pulled out all the stops to make sure mail service wouldn't die only a few days later.

Earnings-Based Consumption

We cannot spend our way to good economic health, even in the short run.  We have to produce.

John Stiglitz, Chief Economist of the World Bank from 1997 - 2002 took callers on CSPAN this morning, one of which was a democrat who suggested (paraphrasing), "With the economic downturn and the tax payers being the problem, with the bad mortgages and such, why not just give every American one million dollars? Then people would spend money, helping businesses, and letting people keep their houses and jobs."

Why stop at one million?? Why not 10? How about 100 million? We'd all be set for life.

I'm all for consumption as a important part of market health. However, the problem with consumption based on money given versus money earned is that, when given, you have no skin in the game. No risk taken. This changes everything. If you lose it all because of a bad decision, oh well. 

With money earned, you have a vested interest in not seeing it disappear. With money earned, you do your best to get the maximum value you can for every penny. This kind of incentive works.  Money-given based consumption eventually reduces productivity to point of total dependency.  This is socialism and, as history shows, has a strong track record for destroying markets.

RIAs - The New Web UI

SproutCore is slick; has a RoR + Apple pedigree & leverages Javascript very nicely.  MobileMe integrates it.  Apple contributes heavily to the project.  Silverlight, AIR, and Google Gears compete.  Silverlight and GG require browser plug-ins.  Only GGs is open-source.  Here's a good overview: http://rapidappsgroup.com/content/desktop-web-applications-using-sproutcore/

Groovy 1.5: No Private for You!

Considering Groovy for your next big project?  We did.  All things considered, it figured to be a safe choice given its Java pedigree. From the limited exposure I'd had to Groovy up until that point, it looked and felt remarkably familiar to Ruby (a good thing).  I had even heard you could cut & paste any amount of Java into a .groovy file and it would just work.  Depending on what 'work' actually means, this is mostly true. 

One of the small untruths about Groovy behaving 'just like Java' is worth serious consideration - especially if you want your .groovy code to become API-ready.

RailsConf 2008 Saturday Night Key Note: Kent Beck

I got lazy and didn't blog about DHH's key note last night.  So, before I get on with Kent's salient story-style wisdom, I'll quickly catch up with DHH's.

Continue reading "RailsConf 2008 Saturday Night Key Note: Kent Beck" »

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

In SOA and Agile: Friends or Foes?,  Amr Elssamadisy opens a discussion on the perceived disconnect between what should be the mutual admiration societies of SOA and Agile developers.  Most of the comments to Amr's article are also informative and and well-written.  However, in the discussion, not mentioned are the non-technical forces in play which, hopefully, this response can illuminate.

Like my development environments, things change.  Since my next project is to extend a product written in Java and, since I used to develop Eclipse rich clients in my webMethods days, I figured I'd install Eclipse on my MacBook Pro.

We use SVN so, I also installed the most excellent Subclipse Eclipse plug-in.  All was going well until, I tried to synchronize to the repository.  When I did, I got the following error:

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Introducing Ruby refactoring pattern called "Forward with Default Params."  This applies to any language that supports parameter defaulting, actually.  And, this pattern may already be documented somewhere for all I know - I haven't looked into it.  If someone can point this out, I'll be happy to defer all credit.  In the meantime...

Problem: You keep creating new methods, each calling the same helper or 'core' method (we'll call it 'method_a'), but with different params.  You can't change the required params of the core method because spagetti-legacy code relies on method_a, without params, such as with Rails controllers.  You should fix the spagetti code but time dictates otherwise.  However, you feel dirty violating DRY in your controller.  What to do?

Summary: Dialogue Concerning the Two Chief Modeling Systems

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

In SOA and Agile: Friends or Foes?,  Amr Elssamadisy opens a discussion on the perceived disconnect between what should be the mutual admiration societies of SOA and Agile developers.  Most of the comments to Amr's article are also informative and and well-written.  However, in the discussion, not mentioned are the non-technical forces in play which, hopefully, this response can illuminate.

Like my development environments, things change.  Since my next project is to extend a product written in Java and, since I used to develop Eclipse rich clients in my webMethods days, I figured I'd install Eclipse on my MacBook Pro.

We use SVN so, I also installed the most excellent Subclipse Eclipse plug-in.  All was going well until, I tried to synchronize to the repository.  When I did, I got the following error:

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Introducing Ruby refactoring pattern called "Forward with Default Params."  This applies to any language that supports parameter defaulting, actually.  And, this pattern may already be documented somewhere for all I know - I haven't looked into it.  If someone can point this out, I'll be happy to defer all credit.  In the meantime...

Problem: You keep creating new methods, each calling the same helper or 'core' method (we'll call it 'method_a'), but with different params.  You can't change the required params of the core method because spagetti-legacy code relies on method_a, without params, such as with Rails controllers.  You should fix the spagetti code but time dictates otherwise.  However, you feel dirty violating DRY in your controller.  What to do?

Yellow Pages.com Rewrite

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

RailsConf 2008

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Book Review: Sketching User Experiences by Bill Buxton

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

The SOA and Agile Culture Clash

In SOA and Agile: Friends or Foes?,  Amr Elssamadisy opens a discussion on the perceived disconnect between what should be the mutual admiration societies of SOA and Agile developers.  Most of the comments to Amr's article are also informative and and well-written.  However, in the discussion, not mentioned are the non-technical forces in play which, hopefully, this response can illuminate.

Subclipse Installation Problem on Mac OS X

Like my development environments, things change.  Since my next project is to extend a product written in Java and, since I used to develop Eclipse rich clients in my webMethods days, I figured I'd install Eclipse on my MacBook Pro.

We use SVN so, I also installed the most excellent Subclipse Eclipse plug-in.  All was going well until, I tried to synchronize to the repository.  When I did, I got the following error:

Ruby Snippet: Shortening Long Strings For Display

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

Resolving Files with TextMate, Subversion, and FileMerge

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

Ruby Arrays: select(), collect(), and map()

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Ruby Refactoring Pattern: "Forward with Default Params"

Introducing Ruby refactoring pattern called "Forward with Default Params."  This applies to any language that supports parameter defaulting, actually.  And, this pattern may already be documented somewhere for all I know - I haven't looked into it.  If someone can point this out, I'll be happy to defer all credit.  In the meantime...

Problem: You keep creating new methods, each calling the same helper or 'core' method (we'll call it 'method_a'), but with different params.  You can't change the required params of the core method because spagetti-legacy code relies on method_a, without params, such as with Rails controllers.  You should fix the spagetti code but time dictates otherwise.  However, you feel dirty violating DRY in your controller.  What to do?