Those working at the highest levels of abstraction inherit the most change from below.

Your application framework may be like standing on the shoulders of a giant, but that giant is a beneficiary of an entire civilization, which is nested on the ground of the Earth, which itself is locked in orbit around the Sun, which itself is orbiting around the galaxy, which itself is still accelerating through the Universe after being ejected from an epochal Big Bang, which itself was probably the result of a collision in an even higher abstraction on our path to infinite regression.

I’m not saying that you’re insignificant — quite the opposite, I’m saying you’re fortunate; as much to be alive as to be a developer with all these great tools to build on.  A few years ago it would take an army of tie-sporting programmers chanting corporate songs in lockstep to produce an end result that a single coder can do from their bedroom today.

But as commercial developers we also have a problem.  It’s so addictive to work in these high levels of abstraction to rapidly change the world for our users that we often don’t see the ground moving beneath our feet.  The reality is our platforms are in motion too, and it’s a fallacy to imagine that our currently cushy abstraction will forever insulate us from having to go back to the drawing board.  But redesign we must.

So why change?  As the platforms we’ve chosen to build on evolve, more and more of the arcane glue between our ideas and tangibility is being done for us by the platform.

Here are a few examples:

• In Firefox, the browser-based spell checker adds spell checking to every text box in a web-based application.  That removes a huge burden from web developers who should never have had to deal with server-side spell checking in the first place.  There are clear benefits for the user too: they get consistent spell checking support that they don’t have to re-train for each application.  Their last name added to the dictionary on one site is reflected on every site.
• Again in Firefox, browser-based extensions can take over even more of the heavy and redundant functionality that shouldn’t be wasting developer time at the application level.  My favorite recent example is the WriteArea extension which adds an inline HTML editor to any <textarea>.  This cuts out a large chunk of the source code footprint (FCKeditor, and ironically TinyMCE, are both hefty); it reduces the amount of client-side script you’re requiring people to cache; and it also reduces complexity, especially on Ajax-enabled sites that may be popping up asynchronous edit windows on floating DIVs.
• Memcached is a distributed shared memory cache that can take over your home-brew caching layer.
• Syndicating application content as RSS is a great way to offload notifications to tools that are better suited for it, without overloading your users’ e-mail inboxes.
• PHP5 introduced SimpleXML; which while far from perfect, I’d take any day over the event-driven nonsense we were doing in PHP4.
• PHP6 will introduce native Unicode support (I’ll wait while the Java crowd stops laughing).  Right now we’re having to hack support together with the ‘mbstring’ extension and deal with side-effects in binary strings from libraries out of our control.
• I’ve been pleasantly surprised by my forays in to OSX and iPhone development land.  While XCode itself is no Eclipse, the Interface Builder puts the UI tools I’ve used in Java (Swing or RCP) to shame.  This abstracts the relationships between the code and the interface.
• Amazon’s elastic computing (EC2) and redundant storage (S3) services are game changers. Designing your application to take advantage of elastic computing and “unlimited” storage can remove your hardware-imposed scaling limits — at least until you’re successful enough the costs of doing it yourself are less imposing.

If you haven’t gone back to the drawing board in the past 12 to 24 months, chances are you’re wasting a lot of time on things that are already solved.

Sure, that sounds great in theory, but my community will turn into a com-mutiny!

If you have a sufficiently large user community around a project, you likely have your own subgroup that gets loud every time significant change is hinted at.  “We don’t want to have to retrain our entire team to do things a different way,” they say. “Small improvements are okay, but don’t go turning us upside down.”

It’s never a great feeling when you feel your project needs to diverge from the comfort zone of some of your most loyal users — most of whom helped you grow from nothing — but it’s more important that your project still exists with at least as much contagious enthusiasm in a year from now.  Hopefully more.

So where’s the “paradox”… Or was that a sensational headline?

I’ll make this real simple.  Let’s say you’re building applications on the LAMP stack.  PHP and MySQL are going to evolve with or without you.  Someday in the fairly soon future, Linux distributions will be standardizing on PHP6 and MySQL 6.  If your application doesn’t work in that environment, your users are going to have to maintain time capsules where it does work.  If their servers break, they’re going to have to spend extra time reverting a new server to old versions of everything.  That limits what they can do with their hardware.  They’re going to miss out on the other less-directly-tangible benefits of the platform: stability, security, maintainability.

Even if your application simply works with new versions of your platform, you’re at the risk of your competition offloading grunt work to their platform and spending their time making their product and packaging better.

The paradox is that you’re going to have to change anyway, and it’s going to cost you far more energy to not change and maintain a time capsule than it’ll take you to embrace change and draw energy from your platform.

Rewriting a successful application can be daunting, but it’s also inspiring to know you’re working on something that people definitely will use because you’ve already proven the idea.  This time you’re informed by all the things that didn’t work out like planned, and you have the ability to turn the roughest spots into the improvements you’re the most proud of.

This is the “why”, but I need to sit down and write out my thoughts on the “how”.  The real dividends from a software rewrite come from sweeping away the scaffolding cruft of a first attempt and building from a stronger,cleaner, more maintainable foundation on the ideas that survived.  It’s also more important to design for changeability than around a concrete feature set.  Your first re-write shouldn’t sow the seeds of your second in another year or two.  I’ll definitely post a follow-up.

The world is full of commercial software developers who breathe a huge sigh of relief when they ship a new release of their project. They start thinking about vacations. I used to be able to relate to that.

Before starting WGM, I used to be among the purist crowd who considered the ability to just “fire and forget” in development a major job perk (if not a requirement). I naively felt that projects started at their conceptual best, when you built from a blank slate, and I didn’t enjoy watching them degrade and get “boxed-in” through the endless concessions made during maintenance and marketing. Ideas were pure and reality was evil. Users was somehow a dirty word.

My reality at WGM, thankfully, has been much more practical; and my collaborative, iterative development eyes are wide open. There’s a powerful, unavoidably-magnetic sense of pride and ownership here that makes it impossible for us to just “fire and forget” anything.

I often find myself entranced by our hosted helpdesk servers. They’re running hundreds of copies of Cerb4 for customers who exist in this — as my past self would say — “messy real-world”. The same past self would gawk at the liability of hosting all this data, and whimper, “I just want to write code!”. After all, every design flaw and inefficiency is embarrassingly magnified on this scale… and yet, I love it!

It’s way too easy to forget how many inefficiencies you’re forgiven when you’re working on a scale of one copy on one machine. I’ve really found my way as a developer by honestly looking at what hasn’t worked, and still trying new things knowing they could very well dead-end, because it’s always a much stronger lesson than simply googling “the best way to _____” and blindly assuming someone else’s opinions or conclusions. Obviously it’s practical to do research, but that’s a far cry from letting something you “read somewhere” become your immutable opinion.

So, do yourself a favor and find a way to be responsible for hosting at least 100 copies of your own software for real users. Naturally, you can charge whatever you want, as long as you still end up with a population of at least 100. Take care to not oversell your hardware, because I’m assuming you do actually want to provide a useful service to people; and your brand is going to be in the gutter if things are completely unusable.

You’ll be getting paid to learn how to write better software. You’ll get the mindshare of being the application people choose because it doesn’t bog down or die when you have a mere 500,000 records in the database.

(If there’s any interest on this topic, I’d love to do a couple more posts about the things I do to benchmark and monitor my applications in our high-use hosting environments.)

Usually you don’t hear someone described as well-intentioned until they’ve messed up somewhere.

I know too many talented and well-intentioned people who are professionally ineffective. Ineffective, because the result of their effort isn’t meaningful progress toward making tomorrow better than today.

(Measuring better is going to depend on the task at hand. For knowledge work, let’s say better means less repeating yesterday through mindless zombie motions today.)

Never-ending droplets

In some roles, emptying a bucket that will never stop filling up with accumulated droplets is the job description.

The ineffective way to handle these never-empty buckets is to just occasionally dump them in the sink.

It would be a lot more productive to dump these buckets into a garden. Our endless tedium could help produce useful resources — food, flowers, trees, fish-stocked ponds.

Conservation of the point

My point isn’t that you should run around hugging trees (but feel free!). Instead, every time you’re barraged with tedious tasks that have no end in sight, and you can’t automate them, find a way to build a garden out of them.

Instead of repetitively laboring through the same questions in phone calls and e-mail, treat them as a resource for constantly improving your documentation or website in ways you hadn’t originally thought of. Tomorrow those improvements will undoubtedly save everyone time.

Using the same example, you could also make a habit of asking each person who calls or e-mails a question of your own. You could tune your marketing without obnoxious and impersonal surveys.

You’ll start to perk up every time the phone rings.

Paraphrased e-mail:

“You should be ashamed of yourselves for charging for software built on free software!”

Hey Potential Customer Who Feels All Software Should Be Free,

I wanted to write you a quick note about your “free software stack” jab.

Libraries, frameworks, languages and operating systems are the prime candidates for being open-source software.  Hobbyists, professionals and students can all share in the building, maintenance and testing of those components.  Everyone can benefit from them for many purposes, and anyone can feed in donations of time, word-of-mouth or money to projects they want to see flourish.

Those open-source components are also used by commercial companies to build applications which are high-level and specialized.  The libraries, components and syntax of a particular programming language act as glue that binds high-level concepts and business logic together into tools.  Such tools are a unified front-end for the constituent components that would individually have little (or no) consumer value or appeal on their own.  Such tools also require a lot of ongoing business-related miscellanea (e.g. support, marketing, documentation) that many open-source programmers would rather live without.

Commercial software has a vested interest in the open-source software it depends on, and an unspoken moral responsibility to provide time, money, recognition, or energy to those projects when possible.  It’s an ecosystem.

It would be a much bigger warning sign to me (of inexperience or misplaced priorities) if a project was rolling its own XML parsing libraries, building its own database abstraction layer, or writing its own templating system, if those components weren’t at the core of that project’s purpose for existing.

Component projects that have philosophical reasons for only promoting free software have the option of releasing their work under licenses like the GPL, which requires derivative software to follow suit.  We use LGPL or BSD/MIT licensed components, where the authors put their work (for varying reasons) into the ecosystem between free and paid software.

Complaining about that is like saying all books should be the cost of their paper because words are free.  There’s a lot of value created by someone who gathers innovative, efficient ideas and technology into a ready-to-use format for your business.

I’m certainly not ashamed of where we fit into that.  You’re a random human being on planet Earth who came into contact with us because of what we’re doing.  Did you also spend the same amount of time looking for programming languages or templating engines?  I imagine you were looking for something a little more immediately usable.

Signed,
 - A dedicated team of talented people who are perpetually immersed in building charming solutions to all those nasty business problems which led you to our doorstep in the first place.

[[ This is a first draft I posted rather quickly since I needed to share these instructions with a few people immediately. I'll be returning to this article to clean things up. ]]

Putting your screencast on most video sharing sites will require you to use resolutions much smaller than full-screen, high-definition video. It’s a shame, but so are bandwidth costs.

You can still provide an incredibly useful screencast in a small video window with a few clever tricks. I’ve found CamStudio to be one of the best screen recorders for these requirements. It has an excellent “follow the mouse” scanning feature, which lets you provide a moving region of your full resolution screen based on what you’re pointing at with the mouse. It’s also free and incredibly easy to use.

For sharing videos, I’ve come to like Jumpcut more than YouTube due to their online video editing toolset, slightly better resolution and more liberal allowances on file size and video length.

What you need to screencast:

• CamStudio: http://www.camstudio.org/CamStudio20.exe
• A Jumpcut login (http://www.jumpcut.com/)
• The DivX codec (http://www.divx.com/divx/windows/download/index.php)
• A headset microphone
• Little enough sleep or enough caffeine to make yourself interesting

CamStudio Setup:

• Install CamStudio 2.0
• Run the application.
• Region->Fixed Region->640×480
• Options->Record Audio from Microphone
• Options->Enable Autopan, Autopan Options->Speed->Max
• Options->Video Options, DivX, Quality 90%, Configure, Home Theater Profile
• Options->Cursor Options, Show Cursor + Use Actual Cursor, Highlight Cursor + Size Halfsize + Circle + Color Yellow (RGB: 255,255,125)
• Options->Keyboard Shortcuts->Record/Pause (CTRL+ F12)

Recording a Video:

• Minimize everything on your desktop and open the application you want to talk about.
• Harmonize your Chi and attempt to channel every great speaker you’ve ever heard.
• Press the record button in CamStudio (or CTRL+F12).
• A region will appear, you can place this anywhere since it will follow you around automatically, but it’s best to place it near where you want to start talking (and where the mouse is).
• Once you place the region, you’re LIVE. Start gesturing wildly and explaining your actions as a running narrative to an empty room.
• After you’ve covered what you wanted to talk about, press CTRL+F12 to pause recording. Open CamStudio in your systray and stop the video by clicking the huge blue square button in the toolbar.
• If all goes well, your video will compress using DivX and pop up a preview that you can play. By default this .AVI file will be saved in your Program Files\CamStudio directory.

Uploading and Editing the Video with Jumpcut:

• Log into Jumpcut (http://www.jumpcut.com/)
• Click “Upload” in the top menu. Click the exorbitant green upload button. Select your video file from the appropriate directory.
• Depending on your upload speed, you may want to get some more coffee or take a polyphasic powernap.
• Once the clip is uploaded, click “Create” in the top menu. Choose “Open the Editor” at the bottom of the page. Maximize your browser if you haven’t already (some options like to hide at the bottom).
• On the right, set the dropdown to “Your Media->all your clips and photos(1)”. Drag your clip to the white frame at the bottom.
• Click “Titles” from the editing toolbar in the middle of the page. I prefer “A Scanner Darky”, but feel free to shop around. Enter your title text and click “Add”. Drag the orange title timing bar from the timeline toward the left until it’s about a half-inch long. You’ll want to experiment with this when previewing your video.
• Click the rewind button in the video preview area (to the left of the play button). This resets the video to the beginning. Click the play button and watch your video.
• Unless you have a healthy ego, or you’re oblivious about your faults, you’ll probably fall to morose depths of self-deprecation while watching the preview. Attempt to remember that you’re going to be harder on yourself than other people will be, unless you had too much caffeine or you’re just really bad at explaining things off the top of your head. If you’ve had 4 cups of coffee and you’re still falling asleep while listening to yourself, it’s probably time for “take two”.
• There are a lot of other fun toys in Jumpcut, but I’m not going to bother explaining them. Play around on your own time!
• Once you’re happy with the video, or at least have resigned to the fact your voice really does sound like that, hit the “Publish” button at the bottom of the page.
• Enter title, tags, visibility and click the “Publish” button.
• You have a video! Even if you chose to make this video private, you can still share the URL with people you trust with your fragile ego in the palm of their hands.
• You can embed this video on your website by clicking the “share” link under the video and copying the “embed” HTML. There are also several other provided options for distributing your video.

Feel free to provide a link to your video in the comments here!

I’m clenching a rough rope tightly between my left thumb and forefinger as I descend down the throat of a bottomless pit. I am not encumbered by the panicky implications of safety equipment. My right arm is gesturing wildly into empty space, acting as the ground-wire for an overstimulated mind.

I tilt my head back and let my eyes reassuringly trace the taut lifeline up to the tiny disc of blue sky, the size of a full moon, capping the vertical chamber. The sight sparks an anonymous memory, which flutters to dutifully provoke a faint aftertaste of life in the center of my chest. Never willful to leave anything unanswered, a familiar dream-like reality superimposes itself on my surroundings. It’s as if I’m standing in a subway tunnel, directly facing an oncoming car, while being pulled backwards strongly by something’s insistence that it’s the proper place for me to be. I twist my head to look over my right shoulder, but everything is dark and shapeless. The illusion melts. I find myself still inching downward, carnally addicted to the growing clarity of my thoughts; paternally insulating them from everything that only knows how to dampen and mute.

I pause to contemplate how I’m as equally dependent on the rope staying anchored from above as I am on my desire to not let go of it. While the only biofeedback I’ve received so far has promised that further down is better, I ask myself if I’m any more objective by now than an alcoholic whose bitter swill has grown sweeter with inebriation. I can’t help but smirk as I tell myself the outcome of a bitter poison is the same as a sweet one — that the only difference is the courtesy of a warning.

An electric pain echoes between my left middle finger and elbow. The bloodless knuckles of my left hand wish to inform me that they’ve noticed they’re the only members of our mutual congregation who are doing any struggling. My mouth opens in instinctive response to the mental image of my left hand turning the wheel of a giant faucet, which proffers a drop but promises a torrent.

Remember the Milk is web-based task management app.

It’s been a month since I made Remember The Milk (RTM) part of my daily life. At this point, I’d go through massive withdrawals if I had to “Forget The Milk”.

Tips:

• It’s not very obvious that you can edit multiple tasks at the same time by pressing ‘m‘. This is really useful, because I often find myself wanting to tag or schedule several related tasks to reduce repetitive keystrokes and mouse gestures.
• There is a huge list of advanced search options. You can convert any set of search results into a dynamic Smart List. For example, if you search for “dueBefore:tomorrow” you can create a list which will always show the current and overdue tasks for today. Just click the “Save” tab to the right of the results. This gives you a list you can work on until it’s empty, instead of the default lists which will always have future tasks at the bottom. It’s far more motivating to work toward an empty “to do” list!
• Make your lists “Getting Things Done” contexts like @Errands, @Home, @Office and @Study.
• Your lists sort on priority by default. If you change the sorting drop-down to due date it will still sort each date by priority. This makes it easy to spot the occasional high priority task that’s overdue, which you generally want to handle before today’s tasks.
• If you’re like me, it’s a hassle to try to find a specific browser tab when you have 100 tabs open across 15 Firefox windows. Try firing up RTM in a separate browser (IE, Opera, Safari). This makes it a lot easier to jump around the desktop taskbar throughout the day while being productive.

Surprises:

• I originally looked at RTM for the Twitter integration, but I find myself adding tasks through their web interface more often than I use the IM->Twitter->RTM functionality.
• We set up our entire team on RTM so we can share tasks, but with RTM is always reminding me about the next productive thing I should be doing I rarely find myself dwelling on what other people are doing.

Likes:

• Reoccurring tasks are my favorite feature. These help ensure I’m making constant progress on our business objectives (“reply to forum posts every weekday”, “reply to blog comments every weekday”, “assign project tasks every Monday”, “audit the backups every Sunday”), as well as the mundane household things I often overlook (“drag trash cans to curb every Thursday”, “make credit card payments every Friday”).
• The iPhone interface is very convenient, especially if you have context lists like @Errands.
• The flexibility on date entry is fantastic (e.g., “every other Thursday at 5pm”).
• Being able to send a single task to multiple contacts (without having to duplicate it) is a big time-saver.
• $25/yr for the Pro features is quite the bargain.

Peeves/Wishlist:

• It’s a little annoying that the current task remains checked after I save an edit. This forces me to habitually press ‘n‘ (select none) when maintaining my lists.
• I wish I could make my to-do & completed lists public so my contacts could see what I’m working on.
• It would be amazing if my contacts could be notified (by e-mail, Twitter) when I finish a particular task that they’re waiting on. That would be easy to pitch as the killer Pro feature.

If you aren’t using RTM yet, check it out!

Related reading:

• Lifehacker readers vote for Remember The Milk as the best web-based task manager.
• Remember The Milk now integrates with Gmail!

After my post “JIRA Is More Annoying Than Having to Eat Three Times A Day” was published yesterday, Jon Silvers from Atlassian (developers of JIRA) stopped by and left a friendly comment.

I’m incredibly impressed that my tongue-in-cheek critique came to his attention so quickly.

Hey Jon,

First, thanks for commenting! I’m glad you took my ranting in good spirits and left a gracious comment. I must not have put my karma into overdraft protection.

“Hm, there are lot of people who want to eat three times per day, even some that would be happy with one meal.”

Ouch! At the risk of sounding insensitive, I’m sure they also find the daily existential requirement of eating — and the neuroendocrinological punishments for not eating — profoundly annoying too. At least breathing is automatic, or we’d get absolutely nothing else done. I certainly can’t argue against the fact that we’re incredibly lucky in our selection and availability of food.

“My other first thought after reading this is whether you’re using filters to find only the issues relevant to you? [...] It’s not consumer software, it was never meant to be.”

Yeah, the customer-facing bit is really the key to our issues. We’re directing end-users to JIRA to submit their own feature requests and bug reports. For many of the reasons that JIRA is great for developers (e.g., specificity), it’s conversely daunting for our average end-user.

It would be great if we could really take a democratic community pulse on various feature requests to help us build each release roadmap. The voting feature does exist, but our experience has shown that only the most enthusiastic users will go through the trouble of logging in, reading all the open requests and voting on each task’s profile. Unfortunately, the demands on most people’s time necessitates community polling features that are more socially “Digg-like”.

As I mentioned in my post earlier, I did get the impression that a non-developer user community wasn’t intended to be directly served by JIRA’s interface; however, I’m sure we’re not alone in sending end-users to JIRA anyway. There isn’t a good alternative, beyond fielding every request personally in real-time, or transcribing requests from piles of e-mail. JIRA at least ensures busy developers won’t unintentionally ignore feedback.

“We are working interface improvements, with the knowledge that (A) lots of people really like JIRA as it is today and don’t want many changes and (B) others like you want to see change.”

We’re in both camps. As techie developers, we liked JIRA enough to buy it. As community-driven software designers, we feel JIRA needs an additional community-focused interface that streamlines the feedback process and allows user democracy to contribute to project decision-making.

I’d like to see distributed feedback from the community helping to elevate the great feature requests and showstopping bugs above the overwhelming majority of trivial or self-indulgent requests. That would save us a lot of time as developers, and it would display that we’re always listening (which encourages more feedback, and the cycle continues).

Here’s one of the features I’d headline if I was going to create a JIRA alternative:

Even when we aren’t expecting users to directly vote on tasks or add themselves as watchers, we need the ability to create a private waiting list per task. That list would allow us to add links to helpdesk tickets, forum posts or attach contact e-mail addresses. Once we’ve finished a given task, that waiting list tells us exactly who to ping. There are ways to currently hack this together using private comments on tasks, but the feature really should require that we’re notifying the waiting list before the task disappears.

“You might also want to discuss your pain points on our forums [...] or if you can stomach (pun intended) another JIRA, you can log issues and feature requests…”

Haha! I’ll do that. It’s certainly more efficient for you guys than implanting tracking devices in rogue bloggers (or, you know, following everyone’s RSS).

It’s great to see that you guys are so on top of feedback.

Photo by bocavermelha

Up until I snapped a few minutes ago, I wasn’t sure anything could be more annoying than having to eat every day. After all, I’ve been told by close friends that I’d be a happier entity if I was simply a brain in a jar, left entirely to its own thoughts. I don’t disagree.

Tonight started out normally enough:

• I fired up JIRA for the thousandth time.
• I dug through the ever-shifting, free-for-all, trivial-showstopper, dupe-a-thon of a roadmap for the thousandth time.
• I wracked my brain trying to sort out the new bugs and wishlist items from ‘Unassigned‘ purgatory, which contains over a hundred tasks that aren’t either outright reject-worthy or important enough to schedule.

Except tonight, something cried out in my mind and asked Why are you reading every single thing AGAIN?

It’s pretty embarrassing when you don’t have a good answer for your own internal teleprompter. It must be something like catching yourself with your pants down. There really is no explanation.

I don’t think it’s entirely JIRA’s fault — but I do think I’ve realized we aren’t their target audience. We’d rather just play bouncer at the door of Club Development and decide which tasks are on the guest list, are too damn sexy to turn away, or have a $100 bill cleverly folded into their handshake. Instead, we have tasks sneaking in the side door, cloning themselves, and all simultaneously proclaiming themselves the most interesting thing in the room.

There’s no reason that a user of our software, clutching a precious scrap of feedback, should arrive at Fort JIRA and be put through the Mensa screening program before they can share. We should be rolling out the red carpet and carrying them to the suggestion box in a golden litter.

Perhaps JIRA wasn’t meant to be customer-facing – and that would explain quite a lot. But if I was going to adopt something for my own neurotic use I’d just keep writing out my ideas in magic marker on rolls of toilet paper (or as I like to call them, perforated Post-Its).

Simply stated, we need something that:

• Doesn’t require a customer login of any kind (but may test for humanness).
• Doesn’t feel the need to ask the customer for more than a block of textual feedback.
• Will bother looking for possible duplication when submitting bugs or ideas.
• Allows our developers to quickly tag, categorize, assign and prioritize suggestions on acceptance without requiring us to open each task’s freaking FaceBook profile.
• Lets us simply pile accepted tasks into “Doing now”, “Will do later”, “Probably will never do, but we don’t have the brass pendulums to say so”.
• Provides simple RSS for everything (e.g., new submissions, current assignments).

Maybe I’ll write it. (Then someone can rant about all the things it can’t do that JIRA can.)

Can anyone save me from the compulsive desire to write things from scratch? Let me know in the comments.

Photo by Grazie, Davvero

Robert Scoble recently stated why enterprise software isn’t sexy enough to cover on mainstream technology blogs.

He offers two arguments:

• The majority of tech blog readers will never be in the position to buy enterprise software.
• Stories about business software, due to a disconnect with their readership, don’t produce meaningful traffic for the blog’s advertisers.

He then asks what can be done to make business software sexy enough to talk about.

Here’s my take contribution to the discussion:

For the bloggers:

If a large software company is giving day-to-day end-users the cold shoulder to schmooze with the market’s decision makers, then they aren’t owed any organic word-of-mouth.

As Scoble points out, anecdotally (but my experience agrees), most workers on a company’s front lines will probably trend toward hating their current business software when asked. In fairness, I also doubt the majority of those workers are offering management a request for any specific alternatives.

This is one area where technology bloggers could be doing a valuable public service, by informing technology workers about the good ideas coming out of the business software market. Make people say “That is much better than the crap I have to use every day!”.

Even if these tech workers are disempowered, and feel their petitions to management are futile, the situation will never improve if the only discussion going on is paid for with multi-million dollar advertising budgets.

For the enterprise software developers:

Assuming for the moment that you want more organic word-of-mouth (and who doesn’t):

• Hire and empower enthusiastic developers who bring fresh perspectives to your problem domain. Look for developers who have first-hand experience as users of software like yours. These people are going to put more thought into the problem you’re trying to solve for people. If time is money, then efficiency is time. Time and money are sexy. 12 keystrokes for common functionality is not.

• Listen to your end-users. These are the people who have to use your application every day. You might think it’s more important to appease the people making the current buying decisions, but today’s helpdesk worker may very well be tomorrow’s influential startup founder. Technology enthusiasts like this attract a large following and they love to talk about what they’re discovering or using. Don’t outsource your suggestion box – let your actual developers connect with the end-users through online communities and feedback portals. Two-way communication is sexy. Megaphones, press releases and moats are not.

• Make an effort to adopt current technology. A lot of technology bloggers, developers and consumers would love to talk about a behemoth like you using some of the same tools that they are (maybe even some tools they wrote!). This doesn’t mean you have to offer an iPhone interface or rewrite everything in Ruby. There are plenty of opportunities for a big tech player like you to contribute to communal libraries which meet 90% of your needs already. Open source libraries and tools are sexy. Golf course nepotism is not.

• Be approachable for technology enthusiasts. Look at Sun Microsystems’ Startup Essentials and Amazon’s EC2/S3 web services. Those strategies build a relationship with non-captive users and let them figure out what you’re all about. Those people broadcast over blog, IM, text or a good old-fashioned chat over drinks. I trust what my peers tell me about you a lot more than I trust an advertising testimonial from the CEO of Megacorporation, Inc. Reaching out with downloadable demos and startup friendly options is sexy. Hiding your entry-level pricing and product demos is not.

You might want to hurry,  business software users are trying new things too.