Business Development

Back to the Future

"Have you been crammified by too much screensucking in your pilatorium lately? Are you frozoned and multifailing because your work environment’s gemmelsmerch is too high? Worry no more! Reverse that enjambleness, stop that whizilling! Acme Micro-ISV’s got the product for you!"

No, I’ve not lost my mind, nor am I channeling A Clockwork Orange, and no, this is not Word 12’s spelling checker running amok. The above is a host of new words recently minted by Dr. Edward Hallowell, a leading expert on Attention Deficit Disorder to describe the host of new information-related afflictions, maladies and crippling diseases starting to spread throughout the Information Society. Pay attention now – what you don’t know can hurt you.

80/20 Your information feeds

A few weeks ago I promised to start exploring here the 47 non-coding things you as a programmer have to do to build a successful micro-ISV. I will get to those, but before I do, we need to do some information feed swamp-draining.

Years (many) ago when I started programming, technical information came in the form of things called technical books. If you were lucky, one or maybe two of these items would be produced, published and make it to a bookshelf at Computer Literacy Bookstore in Silicon Valley about the programming language you worked with and flailed at day in and day out.

That was then, this is now.

Now, no matter how obscure the computational subject, API usage, OS bug there's a gazillion web sites, blogs, and especially RSS feeds pumping out info 24/7 on it. Like drinking from a fire hose? Nah. Try like being at the bottom of Niagara Falls, looking up.

Signs of Plague

Have you noticed more and more online people are feeling burned out and unproductive? I am. So are Gavin Bowman and Keith Casey. So is Ryan Carson. So are a lot of people.

One case is one thing. Two are a coincidence. Four? Four hundred thousand? This is no coincidence.

I see two possibilities: brain sucking aliens are draining our minds through the Internet – the ultimate killer app. Or, something else is going on. I’m hoping its something else – better odds.

Just Say No...To Your Customers?

"Can you add a Whizzy-Woo in the next release? It should be easy since you've already got a Doo-Dad-Adapter."

Ever get one of these requests from a customer? If you're trying to build a clean, usable, and effective application, the answer should always be NO initially.

But isn't the customer always right? Not about features.

NDAs: Fear and Shame

The two fundamental reasons NDAs exist are fear and shame, and that's only halfway a bad thing.

You want a little healthy fear in your life, it keeps you from trying to pet those cute little bear cubs. In business, it keeps you paying attention to things like what the competition is up to, to if your burn rate is sustainable, and how important those last few bugs are.

Most NDAs exist because of two different and worthwhile fears: early competition and secret sauce. If you and two buddies have read Getting Real and struck out on your own to start a web-based business, you'd like to delay the day that knockoffs start appearing. Alternatively, if you're Google, you have hordes of resourceful competitors and abusers who'd love to mine the offhand comments of your engineers.

But the nearly-as-common motivator behind NDAs is shame. You could call it fear of being found incompetent, but the word for that is shame. A shame-powered NDA will invariably be described as an important security measure, but the business is covering up that it runs everything in a slipshod, last-minute, "this is good for now and we need it" manner. Most organizations just barely work and spend their time lurching between crises, which is mildly disconcerting in an interdependent society but handy for breaking the spirit of idealistic young college graduates.

YAPC - NA 2006

Registration is open for the YAPC: NA 2006 being held in Chicago June 26, 27, and 28th.

Chicago.pm is proud to announce that registration is open for Yet Another Perl Conference North America (YAPC::NA) 2006. The primary conference will occur June 26th through 28th at the Illinois Institute of Technology in Chicago, Illinois. The conference will feature speakers from throughout the Perl community, as well as, keynote addresses from luminaries such as Larry Wall, the creator of Perl, and guest speakers from the broader dynamic languages and open source communities. The full three-day conference costs only $100, but early registrants can take advantage of a 15% discount and attend the conference for only $85. With such a low cost, YAPC is one of the most affordable and accessible technical conferences available today.

In addition to the conference, three open courses will be offered on June 29th and 30th. These courses are taught by some of the most notable Perl instructors: brian d foy, Randal Schwartz, and Damian Conway. The courses will all run simultaneously during the two days after the conference. Conference attendance is not required when signing up for classes, but it is encouraged.

Like nails on a chalkboard

You know the feeling... someone says something in a meeting that just grates on you. You know it's not true and now you have a choice. Do you nuke them, politely point out where they've erred, or do you simply forget it and go on with life? I had the opportunity to review a slew of Project Management books recently and Applied Software Project Management by Andrew Stellman, Jennifer Greene was one of them.

Their phrase "All developers are created equal" grated on me in this way and initially I went with the third route, but when they recently wrote an article for OnLamp titled What Corporate Projects Should Learn from Open Source and then it made Slashdot, I had to respond.

Process over programs

Software development, at heart, is the discipline of modeling business logic (or il-logic, if you will). The classic steps go something like the following:

  1. Document the existing process, such as an accounting form or communication need between entities
  2. Determine if there are any existing IT system driving the process
  3. Build a prototype or story board a solution, accounting for #1 and #2
  4. Supposing that the prototype solves the problem (or least makes thing better), go ahead and build it using whatever design/code methodology that suits the project.
  5. Deploy the system to production and commit to caring and feeding for it until doomsday or the process needs revision, whichever comes first

While this is a fine way to build software, it isn't a fine way to solve core problems. For that, I suggest we add step 1.5: evaluate the process.

Apple Creates Evangelists

Everyone seems to be excited about Apple's move to reward the top contributors to their WebKit Open Source Project. They're giving out a dozen computers, five invitations to attend Apple's Worldwide Developer's Conference 2006 on Apple's dime, and probably a bunch of other things we're not aware of at this point. Everyone seems to be surprised by this, but you're forgetting that Apple has always done this sort of stuff.

MSDN Channel 9 Interview with Gavin Bowman

In case any of our readers are interested in hearing a bit about the man himself, an interview with our very own Gavin Bowman is available on Channel 9 Shows » The MicroISV Show.

Check it out and enjoy.