Submitted by Steve Moyer on Mon, 2006-07-10 13:33.
... so went the famous line from the movie "Jerry McGuire". And while it may be appropriate for a sports agent, it really doesn't sound as good when I hear the salepeople in our company say it (fortunately, never directly to the customer). As a large company (C-COR has over a thousand employees), we are multi-faceted ... we have a hardware division, a software division and several mechanisms for making money via services. In all these cases, what the sales group really means is "give me some money", with the often unspoken corollary of "and I'll give you something of equal value". The rest of this article focuses on software businesses and what happens when a customer offers money for something you don't have.
Submitted by Dave Churchville on Tue, 2006-06-06 13:33.
Stop fixing that bug right now! You could be putting your project at risk without even knowing it.
When I first started developing software over 15 years ago, I thought that bugs were evil, and should never appear in any software. It was a matter of personal honor, integrity, and pride to eliminate any bugs.
Only one problem with that approach. There is an opportunity cost to every bug you fix. And there is a risk factor as well.
Submitted by Dave Churchville on Tue, 2006-05-23 14:54.
It's hard to swallow, but here it is: Nice looking things are perceived as more usable by users, regardless of whether they actually are. And what's more, nice looking products get a lot more tolerance from users when things go wrong.
For software, this means that you can build a great, usable interface that looks a little shoddy, and you could be ignored in favor of a flashy, "Web 2.0" application that doesn't do half of what you do, and is of mediocre usability.
Submitted by Dave Churchville on Tue, 2006-05-16 13:32.
"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.
Submitted by Peter Harkins on Wed, 2006-05-10 14:49.
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.
Submitted by Dave Churchville on Tue, 2006-05-09 13:50.
Quietly, under the cover of darkness and the Business of Software forums, I've been spreading the corrupting CodeSnipers influence to pull more people into the inner circle. I'm honored to have our latest victim aboard. The author of Agile Project Planning... Dave Churchville. - Editor.
"Just tell me what you want and I'll build it!"
What programmer hasn't uttered those fateful words? The problem is that even though users often know what problem they have, they are rarely the best people to tell you how to solve it.
Enter the prototype. Developers either hate them or love them, depending on their experience. If you've ever built a sophisticated prototype that faithfully re-created the entire application, only to have it forced into production, you probably hate prototypes. Or worse, maybe no one even bothered to look at it!
Submitted by Gavin Bowman on Mon, 2006-05-08 09:37.
Or, "How I learned to start worrying and love back-ups".
The 8th January 2005 began like any other Saturday, I hadn't quite woken up, and in the distance I could hear a cell phone ringing. My head cleared and I realized it was mine; I must have left it downstairs last night. I thought about letting it ring, I knew the timing pretty well, so I knew it would inevitably stop ringing seconds before I could find and answer it. For some reason, I got out of bed and headed downstairs.
In hindsight I could tell you that it felt a little different walking downstairs, maybe colder, or maybe it seemed slightly darker than usual, but I was too sleepy to notice. It's only when I stepped off the last stair into the room that I finally woke up.
Submitted by Nola Stowe on Tue, 2006-03-28 10:25.
Remember the Lone Ranger? Believe it or not, I actually watched it as a kid. I don’t know why he was called the Lone Ranger, he always seemed to have Tonto - his Indian sidekick with him. Often, I code alone (I thought about rewriting the "I Drink Alone" song to "I Code Alone" but I had only had 1 small cup of coffee when I wrote this) and I’ve been thinking of some "tricks" to help me with my lonely quest.
Submitted by Gavin Bowman on Mon, 2006-02-27 10:58.
If I believe everything I read: ideas are cheap; it's all about execution. Developers are sitting on dozens of great ideas for products or services, if they only had enough time and funding. It wouldn’t matter which idea they chose, as long as the execution was right.
Although there's plenty of truth in the "execution is everything" school of thought, it’s important not to completely devalue the idea, a good idea will imply and steer you towards the right execution.
Submitted by Gavin Bowman on Mon, 2006-02-20 08:48.
Over the last few weeks I posted a series on Micro ISV blogging, here is a brief summary of the five articles so far.