project management

Interesting perspective from Take Two CEO Strauss Zelnick reported by Ars:

During a conference call accompanying today’s earnings report, Take Two CEO Strauss Zelnick attributed the company’s inability to reach its revenue and profit goals last year to “slippage”—what you or I might simply call “delaying games.” He insisted multiple times that putting off marquee titles until they’re really fully ready is the best way for the company to ensure long-term growth, even though such delays might sometimes lead to disappointing-looking numbers in the short term.

He’s right. These days software (both the printed disks and the web) have shifted from a model of pushing a quality product out the door to pushing something out the door as quick as possible. The reality is customers only care about the quality products.

Truth is customers generally never know how long it took you to build something. It could be 10 years, it could be an hour. They just look at the quality and utility of what you’ve done to make their decision. If you’re short on time it’s because you’re too late to put a vision together, or you’re short sighted with your product. Shipping a poor product because of those failures doesn’t make up for it. Fixing strategy and vision to give enough lead time to construct it is the proper fix.

I can’t think of anything that succeeded because it quickly went through development. Ever. Even being first to market doesn’t guarantee success. Friendster went bust. Yahoo went bust. Customers have little loyalty beyond a few cult elitists (Apple fans, BMW drivers for example). I can think of quality products “years in the making” that succeeded. Being first doesn’t mean you win. Being the best means you win.

Perhaps it’s time to stop fearing becoming the next Duke Nukem’ Forever.

I hate when misinterpretations become seen as fact. Supposedly 80% of Firefox bugs won’t be fixed. That’s said to be a bad thing. Here are some realities:

In every release cycle, everyone wants every bug to block a release and therefore everyone is “blocker-happy”, and later in the cycle, all are changed to non-blocker status except the most critical as perceived by developers, drivers, and testers.
Every release of Firefox, like every release of every large software project ships with thousands and thousands of documented bugs. The overwhelming majority of which nobody encounters, or are so minor you don’t even notice.
This process isn’t new, it’s been happening since the early days of software development.
If this process didn’t work like this, there would never be a release of major software products.

A bug is either a defect or an “unintended feature”. Complex products like browsers have thousands. This isn’t a surprise to anyone who works with software on a daily basis. Why? Because every bug you fix, feature you add introduces new code, which potentially causes new bugs in other places. Even if you devote 100% effort to fixing bugs, you’ll likely never get there. That’s the nature of the game. So what makes one bug worthy of blocking? Well generally they must meet some requirements:

Must be reproducible and clearly a bug (not a Firefox doesn’t load ActiveX).
A fix must be identifiable and achievable.
Must be in a more visible location. It’s not effective to allocate large amounts of effort for something so obscure 1 in 10 million people will ever encounter such a testcase.
Must be severe in some sense (data loss, security, usability, performance, etc.)
Fix must not be beyond risk tolerance threshold.

or, it must be a project requirement, meaning a feature that is deemed necessary to ship the release and worth holding for (artwork for UI for example).

Every project involves deciding what bugs ship, and what holds a release. Every single one. If there’s someone who doesn’t, it means their QA is likely flawed or inadequate. Firefox has the advantage of thousands of nightly testers. This helps quite a bit not only finding bugs, but seeing how prevalent a particular bug is, and what it’s impact is.

One should note that just because something isn’t blocking, that doesn’t mean it won’t get fixed. It simply means the release won’t be held for that bug. Should someone fix it, and it’s approved, it can still potentially make the release. The key is that the fix be low enough risk that the benefits outweigh the risk of potential regressions.

If you’re still shocked by this, let me alert you to something: the product (browser, feed reader, etc.) you are using to read this has thousands of bugs. The OS it runs on, has thousands of bugs. Any alternative you pick will be the same. Pick your poison.

I should note these bugs do not get marked as WONTFIX or INVALID. They remain open. They may be fixed in a subsequent release or they may just become outdated and fixed through some other means (code is depreciated and replaced with something else, feature dropped, revamped).