Tag Archives: feature

Project Methodology: What’s the Goal?

I’m struck by the number of times that people make the wrong decisions when it comes to application development as it relates to the ultimate goal.  The ultimate goal of application development is to support the business, so that the business can leverage that application to streamline processes, beat a competitor, or whatever the business need.  To that end, it seems worthwhile to deliver the best application possible.

A competing approach says that the application needs to be delivered by a certain date, regardless of the features (or failures) of the application.  Setting dates for deliverables makes sense, especially when those dates are tied to reality.  Too often though, dates are chosen without regard for the needs of the business; the dates are chosen out of thin air, using a dartboard, roulette wheel, or some other method less accurate than the aforementioned.

When due dates are chosen arbitrarily it only hurts the business.  Sure the application gets out there faster and some project manager somewhere can mark that as a completed project, but features go missing, bugs go unfixed, and the people who suffer the most are the ones who need the solution most.  That’s an important point that seems to go missing:  Business users suffer the most when arbitrary deadlines are set.  The ultimate goal, delivering a product to support the business, gets sacrified when dates are not based on reality or requirements.

Does Agile fix this?  With an agile process, more software is delivered, but that software is not necessarily better software.  And even with an agile process, deadlines are set.  However, now those deadlines are set based on even less information than other project methodologies.

Keep in mind the ultimate goal of delivering better software and supporting the business when setting deadlines.

Version Numbers Matter

After participating in a Slashdot thread about Mozila End-of-Lifing Firefox 4 already (just a few months after it came out), and then thinking about a discussion a few months back about WHATWG ditching version numbers for the HTML specification, I got to thinking more about version numbers and why they matter.

Version numbers (or even names), such as HTML5, Firefox 3.6, Windows 7, Mac OS X Lion, and iOS 5, matter.  They indicate a point in time and provide a reference to the featureset supported.  For example, mention Internet Explorer 6 to any web developer and they may cringe.  IE6 is as notorious for its lack of standards compatibility as it is for its longevity.  When a developer knows that he or she must support IE6, they automatically know that they can’t support many of the features available in newer versions and also have to provide workarounds for several bugs and anomalies inherent in IE6.

Previously, Firefox released major versions when there were major changes to the browser.  So a change from Firefox 2 to 3 brought major interface and UI changes.  Following along that model, when there were minor tweaks to the UI or the underlying web standards supported, Firefox might release a minor version, such as 3.1, 3.5, or 3.6.  Finally, when there was a bug or security fix, it was bundled into a point release such as 3.6.1.

This model worked quite well for years and helped Firefox to gain significant market share.  Several years ago, corporate web sites didn’t support Firefox, meaning that the site either wouldn’t render properly or wouldn’t work at all in Firefox.  With the increased market share came increased corporate support for Firefox.  No longer could a business turn away 10% or 20% of its visitors simply due to their browser.

Along came Chrome which began making version numbers irrelevant.  Google releases Chrome versions much more rapidly than Firefox, currently on version 12.  However, unlike Firefox, Chrome does not have the widespread adoption rate and thus the widespread explicit support from major corporations.  Granted, sites work well in Chrome but try calling your bank’s tech support line and telling them that you’re having a problem with their site using Chrome.  You’ll be told to get a supported browser.

Somewhere along the way, Firefox decided that it needed to compete with Chrome and to do so it needed to not only decrease its time between releases but also increase its major version numbers.  Decreasing the time between releases makes sense; keep adding new features and improving speed and support for web standards.  Incrementing the major version number does not make sense every six weeks.

When designing a web site, organizations need to determine what browsers will be supported.  What experience will the visitor have in a particular browser and what will happen if they visit using an older browser?   This means making choices about what browsers to support and then what features can be used based on the requirements for support.

Somewhere, right now, an IT architect or developer is talking to his manager indicating that they now need to support Firefox 5 because Firefox 4 is out of date.  And Firefox 6 is coming in 6 weeks.  Businesses, with limited resources, need to test their sites in these new versions in order to keep claiming support for them.  Sooner or later, businesses won’t be able to keep up with this rapid release cycle and will have to make a choice to either stop supporting Firefox or keep devoting resources to testing in the browser.

Granted, not much changed between versions 4 and 5 of Firefox.  But at some point, something major *will* change between versions.  Previously, it was easy to tell if something major was changing because the major version number changed.  Without being able to use the major version as an indicator of change, IT departments will need to  test the sites in each version, read release notes, and otherwise spend time that they shouldn’t need to spend.

Users are also hurt because add-ons with Firefox can and do break between major version numbers or at least aren’t listed as being compatible between the new versions.  So now users are left to either run potentially incompatible add-ons or not run the add-on at all.  This doesn’t even take into account the add-on author’s time testing the compatibility.

Version numbers simply matter.  They let us know what to expect when choosing to spend resources to support the technology, when programming for the technology, and when using the technology.

Disable Time Sync with Virtualbox

Virtualbox (or its Guest Additions) have this annoying habit of automatically keeping the clock in sync with the host, regardless of the settings that one tries to implement within the guest itself.  For example, in a Windows 7 guest that I’m trying to use for consistent screenshots I need to set the clock to specific dates.  However, as soon as I set it, Virtualbox changes it back.

Here’s how to change it:

vboxmanage setextradata “<vmname>” “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1”