More for me than others, but I’ve done a few of these things, and this is a good read.

The new word of the day is “FeatureSpam”

FeatureSpam:   n

A variation of Feature Creep,  FeatureSpam is the rapid addition of (seemingly random) features, capabilities and content to a software project deliverable, without regard to deadlines, existing project objectives or (in the worst cases) common sense.

For example:  A Project Management software project where one of the developers, not content with actually doing the work related to scheduling and resource conflicts, instead decides to add graphical 3-d rendering of the tasking landscape, or decides to re-engineer the underlying event framework because it “looks ugly”.  This is most particularly notable when 3d rendering or event framework re-engineering are not part of the release objectives.

Another form of FeatureSpam is from a customer - where each time the customer sees the project advance, delivers a significant number of changes, reworkings and new features based on ideas she or he has had since the last demo or deliverable.   In some cases, especially on billable work, this is just “work”  However, in more product-oriented organizations, the  introduction of a mass of uncoordinated, non-complimentary random changes can be devestating to the morale and productivity of the development organization.

• Scrum - the bright light of scrutiny on your organization’s processes and methods
• Pitfalls when trying to adopt agile development
  
• An interesting technique for refactoring convoluted legacy code (hat tip: Kevin Rutherford)

Another recent article (which I can’t find right now) talked about how problems with adopting agile suggest problems with the organizational structure more than with agile development.  That is, of course, a variation on the “No True Scotsman” argument, but even so, I can say that in my experience, it is true - the two organizations where agile has failed has done so because of deep organizational flaws.   I can say this because these experiences were several years ago, and both of these organizations have failed to deliver the software they promised, or even an acceptable subset.

This is the epitaph to my old artile: How Agile Software Development Ruined My Career (Sort of)

Seth wonders if ‘Good enough will be the next big idea‘.   This aligns well with Kathy Sierra’s writings on featuritis, and the general agile principle of “Good Enough” software.

I would say that this will only be true if “good enough” sells to the general public, and they buy “good enough” merchandise on a satisfyingly regular basis.  Because one of the ways that salespeople make money is by convincing potential buyers that what they have is not “good enough”.

• The latest Carnival of the Agilists is up, and very well done too, I might add.
• Happy birthday to my friend Bob Forsman.

One of the things I’ve noticed about the most complex systems out there is that they are all Event-driven.  Operating systems, Windowing systems - at the end of the day, anything that’s trying to be a generalized platform for general purpose work ends up behaving as an event-driven system.     That’s the point at which the bugs become insidious - race conditions, deadlock and other problems related to the fact that the developers have no way of knowing what is going to happen next at any given time.

This further has the consequence of creating layer upon layer of management, monitoring, resource management and error handling code, not to mention debugging, tracing, security and other tangential systems.  You have to have them as you grow more “general purpose” because without them, you’re DOA everytime anyone uses the system. There’s just too many ways to fail.

So when I see things like ‘Corporate EDA’, I shudder a little.  I wonder if they realize the can of worms they’re opening by trying to handle “anything”.   Especially given that, as far as I can tell, each enterprise will require its own custom approach to it’s “Corporate Operating System”.   And that COS will have to be maintained, evolved, improved, debugged and taught for years and years to come.   And, worst of all, it will be viewed as a cost center, not a profit center, and will always have to fight for resources with the other auxiliary functions.
So who wants to be the next Microsoft?  Apparently, everyone.

From Seth Godin:

It’s awkward to talk to your boss (who has way more experience than you do) about teaching her agile programming.

It’s awkward to call a religious or political leader on their intolerant comments.

It’s awkward to bring up pre-need burial services with an older person. (What a great oxymoron, by the way).

It’s awkward to challenge a co-worker who has a negative attitude, or is constantly surfing myspace.

It’s awkward to ask a new lifeguard recruit at the beach to prove she can actually swim.

It’s awkward to ask the owner of the restaurant to turn off the TV behind the bar.

It’s awkward to create a product that changes the status quo.

It’s awkward to demonstrate your amazing insights when it might threaten those that are looking for stability instead.

The reason we need to be in search of awkward is that awkward is the barrier between us and excellence, between where we are and the remarkable. If it were easy, everyone would have done it already, and it wouldn’t be worth the effort.

So what, you might say.  It’s still awkward.

Imagine that you’re in a situation where the only thing between a loved one and death is that you have to ask someone an awkward question.  You would do it, wouldn’t you - the health and welfare of your loved one is far more important than the momentary awkwardness, no?

The key to overcoming the awkwardness is to accept/recognize the importance of what you need.  IF what you need is important, awkwardness is irrelevant.  So what is important to you?  Are you one awkward question away from getting it?

So does George Harrison.

Napster should have used this for their theme song.

I’m likely to be doing more Flex programming in the relatively near future, so I’m gathering interesting posts.

http://www.zeuslabs.us/archives/87/separating-layout-from-style-and-functionality/

My only problem with this example (and it is primarily because it is just an example) is that it makes it much harder to see the direct consequence of an action - you have to go hunting for it - the button and its clickAction are loosely coupled, which is a good thing in many cases, but harder to understand when you’re trying to support or maintain.

I suspect that better naming strategies would help here.  And certainly I’m not blaming the author of the post - he was focused on demonstrating separation, not maintainability.

http://www.infoq.com/articles/Agile–The-SOA-Hangover-Cure

Did I mention that I finally, finally have a chance to do for-pay Rails work?    Nothing fancy, but its a great start.

Scott Bronson reviews the various Ruby debuggers. Winners:

• Free:  ruby-debug
• Pro: Arachno Ruby

And then a guy named ‘rabble’ is, or has written a book on Testing Rails (woo hoo!).  Here is the companion blog.

This is the best Internet video ever!

Starring a bunch of ‘Net wierdo legends, including the Peter Pan guy, the Tron guy, the Burger King Subservient Chicken, the two chinese guys who performed ‘N-Sync on Google Idol, the Dancing Baby from Allie McBeal fame and at least one more person.

If you only see one video on the Internet in your life, it will probably be this one.

Everyone gets together, and agrees on a rough portion of the country.  Then, everyone names a popular song that’s likely to get played on the radio.

Then, someone surfs over to yes.com, and everyone watches the real-time song start announcements to see when their song shows up in the specified region.

Whoever’s song is the first one to pop up wins!

I posted this on the wrong blog.  Sorry about that - you can find it here.  Great job, Pete!