Table or Booth

The Real Competition

Wow, NetBeans vs. Eclipse has been quite a pot-stirring debate!  I should've expected it when the Sun evangelists, themsleves, are involved.

Eclipse/NetBeans Popularity (ENP) Index

Javalobby has been stirring with NetBeans buzz and I've had some unexpected interest in my "NetBeans vs. Eclipse - No Real Debate" post.  In the end, to businesses such as webMethods, what's really important is knowing how viable each will be as an application platform.  One way to measure viability is with raw popularity; enter the ENP Index.

NetBeans vs. Eclipse - No Real Debate

NetBeans vs. Eclipse.  This used to be a flashy debate but is losing luster with the rapid adoption and growth Eclipse as a platform for developing rich client applications.  Perhaps this will explain why.

Flat Spot Shifting

I bought a new mountain bike recently and learned something pretty quickly: just as you begin a descent, immediately followed by a sharp uphill section, make sure you shift in the flat spot, just before heading downhill.  Not doing so forces you to either pedal to shift as you gain speed on the downhill or try to do so later on the uphill side.

If shifting on the downhill is even possible, given the slope angle, it requires pedaling, giving you even more speed at a time when gaining speed is already handled nicely by gravity.  Waiting to shift until you hit the uphill part causes you try to shift into the proper uphill gear right during some of hardest pedaling work you'll have.  Trying to shift during this max effort time tears up your gears and just brings you to a grinding halt (literally).  If this happens, depending on the hill, you may as well dismount and carry your bike the rest of the way.

It doesn't matter if the uphill section is short and steep or long and gradual, you're best off shifting in the flat spot before it.  As I was getting into the hang of this the other day, it occurred to me that it's quite true of commercial software development as well.  With enough practice, we should be able to predict the more demanding parts of the development cycle and prepare accordingly.

So, what kind of shifting do we need in the software world?  The group I work in starts study groups, where we pick a good book, divide it into reasonable chunks, and then have group discussions on them once a week.  Another idea floated by Luis recently is to plan for less critical training projects that give everyone a chance to work with some different technology.  It's also valuable at times like this to do team-oriented fun stuff that isn't so work related.

All of these things help us to shift gears in the flat spots.  It also suggests that flat spots should be put into the plan, if possible.  Eclipse.org's contributors have nice, big flat spots in their plan every six months.  The nice thing about tight iterations is that you get more chances to do this.  Trying to change into an easier gear during the toughest part of the development cycle forces inefficient context shifts and seldom moves things ahead any faster, if at all.  How quickly this is forgotten at times.

Painfree RCP in 3.1M5

This is the blog-workout sequel to my carefree "Eating the Eclipse 3.1M5 RCP Donut" post.  Presented here are four simple recipes for using the new 3.1M5 capabilities to create, configure, and export a Rich Client Platform (RCP) application out of one or more plug-ins.  It can all be done graphically and completely avoids messing with plugin.xml or hand-editing a .properties file.  Thanks, Eclipse RCP team for giving us this exquisite feature!

When Broken: Fix it

"If it ain't broken, don't fix it."  Like Dave Thomas and Any Hunt, who encourage fixing "Broken Windows" in their timeless book The Pragmatic Programmer, I prefer "If it's broken, fix it."  The only other option is to stop using it.  The assumption about unnecessary fixes is often that the machine cannot handle change well and will probably run best if left alone.  This may be true but the machine might still be severely lacking.

Fixing broken things applies as much to machines as it does processes.  If you find yourself in a broken process, you can either let it beat you up, fix it, or just exit stage right.  More often than not the best alternative is to fix it.  And yet, oddly enough, it seems most people's m.o. is to get the snot kicked out of them until they finally just leave, defeated.

Insist on the Fix
A better plan is to reject status quo and push to fix the problem.  This can be instigated at any level.  Often problems and their solutions aren't noticed where you'd expect they should be and fixing things means breaking out of baked in patterns and even, occasionally, talking to people who don't think things should be fixed.  In The Pragmatic Programmer, chapter one, section three, titled "Stone Soup and Boiled Frogs,"  Thomas and Hunt suggest avoiding the blank stares you'd get by asking permission to fix something:

Work out what you can reasonably ask for.  Develop it well.  Once you've got it, show people, and let them marvel.  Then say "of course, it would be better if we added..."  Pretend it's not important.  Sit back and wait for them to start asking you to add the functionality you originally wanted.  People find it easier to join an ongoing success.

If You're Wrong...
It also means occasionally being told to slow down because "It ain't really broken, Gungho."  And they'll probably respect what you're doing enough explain why.  So, the worst that can happen is, you'll learn how to stop worrying about whatever it was you thought was a problem.

New Math

The bizarre world may be the most interesting when explained by its witty rationalists.  Regarding procrasination, this had me chuckling: http://jamie.ideasasylum.com/2005/03/distraction-operator_02.php. 

It may have been intended only in jest but, if taken seriously, perhaps it would be useful in measuring how tasking and the work environment affect productivity?  Making this supposition ¬ Doing actual research to make something useful out it :^)

The S on my Shoe

DeAnn attends the University of Washington and was late to a class the other day.  She broke countless eco-religious rules by leaving the concrete path and traversing a grassy area, embarking on the shortest path to her bus stop.

The bus was in sight and had been stopped for several seconds.  Catching the 9:50 am bus would get her to her 10:00 class just as the clock would chime.  She'd knew the bus schedule by heart and couldn't afford to miss this bus since there was a test that day.  She picked up the pace, almost running but not quite, lest she look frantically uncool. 

Then she felt it as her left foot landed.  It planted itself on something not quite grassy.  Her foot slid a little forward and to the left, triggering the slightest awareness that something wasn't quite right.  As she continued her smooth jaunt, she glanced down and saw it in perfect rhythm with her stride.  It was clinging to the bottom of her shoe - "S!" she exclaimed, "S on my shoe!"

It was quite the dilemma.  She could try to swipe it off on the lawn and hope she got enough of it to avoid detection in the close quarters on the bus.  Or, she could just give up making the bus, be late for her test and go find a public restroom to clean up.  But, she was already worried about the test and missing the instructions at the beginning would be a really bad start.  What to do?

It was time for desperate measures.  So, her cool rush to the bus suddenly changed into something looking more like the electric slide.  She still moved quickly, but with only one good leg, appearing strangely to outsiders to be aggressively dragging the other reluctant, dead leg along.  She looked like the wounded but still determined antagonist in bad horror film.  It was all very noticable and uncool looking, but she was actually managing to scrape good amounts of S off her shoe.

When she was nearly to the stop and was noticed by the bus driver, she stopped to check her progress.  Astonishingly, she nearly got it all!  Two more careful scrapes on a thicker patch of grass seemed to get the last remnant.  Alas, she finally did catch the 9:50 bus and settled in, hoping no one would notice.  No one seemed to, or at least they were all very polite about it.  As the bus drove off, she looked out the window and smiled for a second or two, proud of at least one small victory that day.

Open-Source: Offense or Defense?

Simple economics apply to any software strategy and should not be ignored.  This is equally true with respect to open-source software. Using it is often a no-brainer.  Building on top of it requires more deliberation but is still a fairly straightforward decision.  The harder question to answer is "Why might I contribute my software to open-source as a part of my business strategy?"

Janitor Joke

You've got to love a janitor with a sense of humor.  I was greeted strangely today by three, fully emptied and bagged trash cans.  This is odd for several reasons:

• My cube is small and three cans make it virtually impossible to navigate
• No one else seemed to be missing theirs
• Three of a thing, is a pattern often used by interior decorators in their designs
• Hays, the potential perpetrator told me he "would have put 50 trashcans in my cube had he done it."

Maybe it's a sign telling me I have lots of emotional trash to rid or perhaps it's telling me I should start a mission, donating cans to the trashcan-needy.  Which reminds me; you never know when you'll be caught jamming a Butterfinger wrapper in your jeans pocket because you don't want to litter and there's not a single trashcan in site. 

Several washes later you'll reaquaint with your surprise piece of squirrelled away garbage when fishing for change or when you're searching frantically for that movie ticket you just purchased, only moments before, and now can't seem to find.  "I bought it; I really did!" you'll plan to plead next before finding it in your left coat pocket and smoothly handing it to the cinema-checkpoint person, all before anyone actually notices your memory lapse.  Finally, on your way to the show now, you spy a huge trashcan and toss the resilient Butterfinger wrapper, once and for all.