Table or Booth?

WACD Anti-Pattern: Putting Your Development Approach on Wiki

I saw something on a team wiki the other day.  Btw, why I was reading a wiki is still a mystery me. 

People who use wikis share knowledge to their professional detriment.  You should strive to collect as much tacit knowledge about your project in your head (and no where else) as possible.  That way, everyone will be forced to rely on you, the one with all the keys.  Wikis are for the birds.  But I digress. 

As a strict student of WACD, I was horrified to see this:

In case you can’t already tell, we are a seriously team-oriented group. As such, we strongly encourage collaborative development and high levels of communication. To achieve this as well as high levels of accountability, we use Scrum. Since Scrum is our management and development methodology, ideally, you’ve taken or you will take a Scrum Master certification course. Otherwise, our mad methods may leave bewildered, daily.

To manage the minimum requirement docs we need, we use Thoughtworks’ Mingle.  If you’re reading this page, go ahead and add it to your resume now (I’ll wait…).

We use a concept called Personas to identify with our users. Personas are those will primarily benefit from anything we build or fix. In Scrum, we pay close attention to the reason why our Personas need anything. In User Story parlance, this is the ”, so that …”.

Eventually, we will become a test-focused development organization. At the time of this writing, sadly for this author, testing is still mostly a manual, herculean effort.

Continuous Integration is another core discipline on our program.  Our codebase will be automatically built and any associated tests executed each time Subversion detects a change.

For details about how this project's development is done, see our handy <link to> Developer Guide.

These guys are clearly headed in the wrong direction.  With so much collaboration, how can any good WACD developer go off in isolation for a week or two to get work done??

And this accountability stuff is for Nazis.  I need anonymity.  Anonymity lets me maximize my 'flex' time by focusing most of my heroic effort on the day or two just prior to hand-off.  Most of the time prior to this wasted slack time anyway.

Oh, and the fact that they're not test-focused, to true WACD disciples, isn't a bad thing - it's a great thing!  Why change this??  Testing is superfluous and inefficient when you have a cowboy or two like me on your staff.

Once in awhile you run across anti-WACD stuff like this.  It's worth pointing out so that the rest of us aren't misled and can all learn from others' over-hyped forays into agile foolishness.

SOA, May You REST in Pieces.

Save your valuable time and don't watch this attempt to pump blood into a cadaver: http://www.infoq.com/presentations/Reincarnation-SOA-Anne-Thomas-Manes.  This presentation was so staggeringly ineffective and useless that I felt moved to write yet another SOA epitaph.

I believed in SOA at first.  That was until I had to get small web-based applications built, quickly.  That was until I tried to integrate one of them with Amazon Web Services and went with Amazon's RESTful version (as did an overwhelming majority of all other mash-up developers).

On planet earth, SOA was a vendor-driven monster the best of us eventually ran from.  To survive it, we protected our sanity with a bit of HTTP armor and plenty of REST.

It was about this time that I fell in love with Ruby and eventually, Rails.  Rails, in case you've been living in a SOA catacomb, is a RESTful framework from the smallest brick, on up.

But hang on, buzzword vultures.  Even Rails, at the time of this writing, isn't even cutting hype-edge anymore.  'Cloud', whatever that really means, is all the rage.

And yet, technology hype cycles, no matter how overblown, do have real value.  Planted in the compost pile of rotting buzz are vibrant seeds of truth.

If nothing else, hype cycles force us to take sides.  Sometimes these sides form around the best way to grow a seed of truth.

In fairness to SOA, we were confronted with the idea that standardized system to system interaction over HTTP (with XML and XML Schema) could be an effective building block for highly interoperable systems. 

Fair enough.  So where did it go wrong?

As I see it, SOA architect-astronauts described the wrong environment for growth of standardized system to system interaction over HTTP.  Specifically:

• In reality, there were too many non-standard vendor implementations of WS-* (WS-Death*) which led to ...
• WS-* required wholesale vendor buy-in to expensive tools and software infrastructure.  Startups not welcome!
• SOAP didn't effectively reuse aspects of HTTP.  It ignored three other useful HTTP verbs completely, missing a huge opportunity to make web services really simple.
• SOA required massive up-front thinking to be even partially useful.  Despite SOA evangelists' insistance in top-down/bottom-up agnosticism, SOA was not a bottom-up/organic way of thinking.  And, more than we'd like, 'organically' is typically how we must go about building systems.

Sometimes you see a presentation that is so vapid and useless that you're moved to do something about it.  Or, just moved to throw up.  This was one of those for me.

OK, OK.  Being positive ... 

A little reminiscing from time to time does help you think about how you got to where you are and the little disasters that, with God's grace, you navigated along the way.   For that I'll be forever grateful.

*Organs play ...*

Ruby 1.9.1 RDoc No Memory Error

When running:

gem install wxruby-ruby19

I got the following RDoc error:

Successfully installed wxruby-ruby19-2.0.1-x86-mingw32
1 gem installed
Installing ri documentation for wxruby-ruby19-2.0.1-x86-mingw32...
Updating class cache with 1663 classes...
Installing RDoc documentation for wxruby-ruby19-2.0.1-x86-mingw32...
c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `each': failed to allocate memory (NoMemoryError)
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `grep'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `binary?'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:90:in `can_parse'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:157:in `block in normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `each'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:185:in `list_files_in_directory'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:166:in `block in normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `each'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:197:in `parse_files'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:257:in `document'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:177:in `run_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:137:in `install_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:123:in `generate_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:152:in `block in execute'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:151:in `each'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:151:in `execute'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command.rb:257:in `invoke'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:132:in `process_args'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:102:in `run'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/gem_runner.rb:58:in `run'
        from c:/ruby19/bin/gem:21:in `<main>'

For a large gem, RDoc has a loop that begins to chew up available memory.  Ruby's garbage collection utility (GC) can be used to fix this.  To do so edit Ruby's rdoc.rb by inserting:

GC.start

somewhere in the "when directory" switch (see my hacked rdoc.rb).  This will force garbage collection before calling a memory intensive step in the loop.  I was able to install the wxruby plug-in successfully this way.

Continuous Integration Server Review: CruiseControl, Hudson, TeamCity and Cruise

Comparison of two open source and two paid continuous integration servers:

http://docs.google.com/View?id=dhkskk4s_54f749s7dc

Flow Control In Scrum (Or Any Development Process)

"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?

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

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.