Archive

Archive for September, 2008

Google Chrome Makes OnTime Scream

September 22, 2008 15 comments

With the release of Google’s Chrome browser, one question comes to mind:

How is this kind of performance possible?

With browsers now being a 15-year old technology, how is it that a newcomer to the game can radically change the performance of a browser by nearly doubling the normal performance? Google’s achievement with Chrome is absolutely remarkable. It would be similar to a relatively new car company making a sports car that all of a sudden performed at 400 MPH rather than the typical 200 MPH obtained by Ferrari and Lamborghini.

For applications such as Axosoft’s OnTime, Google’s Chrome is heaven-sent. I am absolutely thrilled with the performance of OnTime under the Chrome browser. In generally, nearly ALL operations are twice as fast. Everything from applying a filter to changing a project to adding or editing an item is very noticeably faster with Chrome. This translates to an exceptional user experience. While Chrome is still a V1.0 Beta browser, it has already made it to our list of “must-work-with” browsers for OnTime’s testing.

The above chart provides a short sampling of the amount of time (in seconds) various operations take in OnTime with Internet Explorer 7, FireFox and Chrome (smaller numbers means faster load-time).

My prediction (and a bet with a colleague) is that Google’s Chrome will easily enjoy > 25% market share by the end of 2009. I think that number is actually very conservative.

Categories: Tools Tags: , , ,

New Microsoft Ads are…GOOD!

September 18, 2008 10 comments

I was one of the few that actually liked the Seinfeld/Gates ads and when they announced they are canceling the Seinfeld ads in favor of a more direct approach this morning, I was thinking to myself, “oh no! this can’t be good.” But the new ads are actually very good. I’m impressed!

Here they are:


Microsoft’s new ad Campaign

Categories: Business Tags: , ,

Axosoft’s Secret Service: Sending Large Files

September 18, 2008 124 comments

A while back, Dan Suceava (head of Axosoft’s software development efforts) and I decided to embark on a mad-man-weekend-project. The crazy idea was for us to see if we could develop a simple web-based service that allowed a user to send large files (as big as 1GB) to another user without the use of FTP. We wanted the service for us! Sending large files via email was not an option since most email programs don’t allow large attachments, and we need an easy way to send 100MB+ files, videos and databases to friends, family and co-workers.

So the idea for TransferBIGFiles.com was born.

The service went live 3 years ago! Since then, more than 1.2 MILLION files have moved through the service and thousands more go through each and every day. An average of a 1/4 million people use the service every month and Axosoft has footed the bill for more than 147 TERABYTES of bandwidth usage. It’s pretty satisfying to see a weekend project generate such incredible demand. I’ve received hundreds of emails from people all over the world who have said everything from “you are a life saver” to “I can’t believe this incredible service is actually free.” People love it.

Today, I happened to run into my own article titled “Just a Weekend Project” where I wrote the story of how we created TransferBigFiles.com in just 20 hours and it brought back some memories. I wanted to revisit some of the images from that short journey:


We did a white-board design session in an hour and a half


I hand-drew the UI on my Tablet PC


We entered our 11 tasks into OnTime (it was V4.0 at the time :-)


This is Dan installing the server


That was me – holy cow I look so much younger!

Since then, TransferBigFiles.com has received a couple of hardware upgrades and a couple of software updates to manage the demand and we’ve kept it free the entire time. We think the good Karma has definitely rubbed off on Axosoft’s success, so we’re pretty happy with the results.

The title of this article is “Axosoft’s Secret Service,” because we really don’t do much to promote Transferbigfiles.com.  But, I wanted to let the cat out of the bag for my blog readers, in case any of you are looking for a super easy way to send large files — no registration, no software to download, share files with anyone who has an email address!

Team Wiki for Document Management

September 15, 2008 2 comments

In every software development team, inevitably, there are a number of documents that spring up to help manage various project information. They often include documents like:

  • Project Overview and Goals
  • Project Risks and Concerns
  • High-level Design Overview
  • Coding Guidelines
  • Team Directory
  • and on and on…

And virtually every team I’ve seen stores these documents in some kind of network share. Some even use Microsoft’s SharePoint Server to manage these type of documents.

The problem with the standard network share is that it virtually guarantees that nobody, other than the author, will ever open these documents more than once. It’s rare that these documents stay up to date and maintained. They are hard to find and can be locked because other users are editing them or have left them open.

The ideal solution for managing these documents is something that would allow:

  • All Team Members Easy Access to the Documents
  • Appropriate Team Members Have Edit Rights
  • No File Management Needed
  • Easy Search of All Documents
  • Automatic Table of Contents

The typical network share falls short on all of these requirements, however, a typical Wiki product nails most if not all of these items. Any team that’s not yet utilizing a wiki for document management is wasting their time. A Wiki provides the flexibility of allowing any appropriate team member to create a new document, edit or update an existing document and easily find the information that they might be looking for.

The great thing about Wikis is that you don’t need to manage files on an individual file level. Unlike storing files on a network share, a wiki is easily web-accessible and provides easy read-only capabilities. The right wiki can provide a nice security system to ensure only the right people have access to view and edit files.

Wiki in OnTime 2008

We introduced OnTime’s Wiki functionality in V8.0, released back in December of 2007. In the past 9 months, we have seen OnTime’s wiki become one of the most used features of OnTime and its being used for a great deal more than we had expected. Teams have started using OnTime’s Wiki for everything I listed above, plus:

  • Processes & Procedures – Teams have started to document their processes and procedures allowing new team members to quickly access this vital information in a single, automatically organized location.
  • Methodology Information – Some teams have created wiki pages with both content as well as links to important web sites with information about the methodologies they use. A Scrum team might have Wiki pages that provide an overview of Scrum, descriptions of a backlog, sprint and so on.
  • Team Meetings – Teams have found that summarizing important team meetings in a short Wiki document helps them keep important decisions searchable while easily communicating the information with team members that may have missed the meeting.
  • Database Update Procedures – Updating the database often entails a tricky set of steps that must be carefully coordinated between multiple team members. Documenting those processes in a team Wiki helps everyone stay on the same page.
  • Sales FAQ – Teams have started creating sales-related FAQ pages for their sales team. Setting up a “Sales Project” and creating documents underneath that project ensures that the sales FAQ docs are also maintained in the right branch of the automatically generated Table of Contents, keeping clutter to a minimum.
  • Support FAQ – Similar to the Sales FAQ, the Support FAQ helps OnTime teams manage common support questions.
  • Favorite Lunch List – My personal favorite is the use of the team wiki to maintain a list of favorite lunch places near the office. The importance of using a Wiki for accommodating lunch cannot be emphasized enough :-)

Because Wiki pages are easy to create, search, edit and view, team members are more encouraged to create, edit and maintain documents that pertain to some aspect of the development process. In OnTime, Wiki pages are fully integrated into the main interface so you have access to wiki information from the same tool that you use regularly. No need to leave OnTime to look at or search Wiki pages.

Here are a couple of screenshots from Axosoft’s own usage of the OnTime Wiki. In this case we see an automatically generated Table of Contents screenshot and a page describing some best practices for a new OS X user at Axosoft:


The OnTime Table of Contents is Automatically Generated

With the release of OnTime V8.1.2 & V8.1.3 we have added a number of very important features to the OnTime Wiki that makes the Wiki even more powerful than before:

  • Full-Page Wiki Mode (like the screenshots above) – This new feature (added in V8.1.2) allows users to focus on wiki pages without having any other OnTime functionality on-screen. The full-page wiki mode also allows you to easily send the URL of a particular page to another user. When that user logs in, only that particular Wiki page is loaded (no tabs for Defects, Features, etc.). This allows a new type of user in OnTime: Wiki-only user. Editing, searching and navigating wiki pages is also easier in full-page Wiki Mode.
  • Aesthetic Improvements – In V8.1.3, we introduced a few improvements to the look and feel of the Wiki pages. For one thing, fonts tended to be different in edit mode than view mode. That issue was fixed. Additionally, we improved the look (and size) of the page title and re-ordered some toolbar buttons so that it’s even easier to use.
  • Wiki User Settings – Also in V8.1.3, we added some Wiki User Settings that allow users to choose whether or not they want to see the last modified date and user next to each wiki page name in the Table of Contents. Also, when selecting a project, the Wiki User Settings now determines if OnTime should show you the TOC for that project, the Home Page or the page you had last visited for the given project.

Since OnTime Wiki pages can also be made available in your OnTime Customer Portal, sharing information with your customers is also very easy. Regardless of whether or not you use OnTime, using some kind of a Wiki system for document management is extremely important to keeping your team efficient.

The Maxwell Curve Blunder in the Name of Scrum

September 9, 2008 14 comments

I recently ran across Jeff Sutherland’s blog article, titled Maxwell’s Curve Getting More Production. In this article Jeff refers to the Maxwell Curve, a concept created by OpenView Venture Partner’s founding partner Scott Maxwell about how team productivity actually decreases as teams work longer hours in a given week (see the graph to the right).

Looks reasonable, right?

However, if you study this graph for just a tad longer than a glance, the graph is actually quite humorous as it seems to suggest the following:

  1. Weekly productivity goes down to zero -0- if a Scrum team works 60-hour work weeks — they accomplish nothing.
  2. Using a Waterfall methodology is far more productive than Scrum for teams that must work 52 or more hours per week.

WOW! What am I missing?  This is supposed to be a pro-scrum article, right? You might recall that Jeff is a Scrum co-founder. He also has a Ph.D from the University of Colorado School of Medicine (Wikipedia), and Scott Maxwell is no slouch either having graduated from M.I.T. with a Ph.D in Mechanical Engineering (OpenView Profile Page).

Now, I’ve become a big fan of Scrum lately and I love that Scrum is taking off in a big way with so many software development teams adopting it. But sometimes, with the rapid adoption of new software, technology or even a methodology, strange claims are made. I think Maxwell’s Curve is one of them.

Now to be sure, I agree that productivity slows down and might even go negative as the number of hours worked in a given week increases beyond the social norms for the region and average age of the team, but that’s not what Maxwell’s Curve is indicating. It’s indicating that productivity actually starts to reverse itself significantly just shy of the 40-hour typical work week. Basically, the graph suggests that negative productivity kicks in and erases all of the positive productivity of the previous 40 hours in less than 20 hours: a pretty impressive accomplishment in and of itself.

If the vertical axis indicated “widgets” instead of “story points,” at about the 32-hour mark, the team would stop creating new widgets, turn around and start smashing all of the widgets they had already created previously in the work week. Software development is different than assembling widgets, of course, but it’s hard to imagine a generally productive team that would net 0 story points (productivity) because they worked 60 hours instead of 40.

What’s even more intriguing is why teams using a waterfall method would remain productive for as many as 80 hours — how the usage of Scrum could possibly slow down teams that work more than 52 hours when compared to Waterfall teams is beyond anything I can comprehend.

Reality, even in Jeff’s own example, suggests otherwise.

For the record, I’m a big advocate of the 40-hour work-week, but I have no delusions about how the 40-hour work week impacts our overall performance. The 40-hour work-week helps Axosoft maintain its competitiveness in the following ways:

  • Attract talented individuals who wouldn’t want longer hours forced on them;
  • Improve the work/life balance of employees, which is great for employee retention and general happiness levels;
  • Reduces animosity and feelings of dissatisfaction when generally developers are the only ones expected to work the long hours while management and other employees head home.

That’s why the 40-hour work week is so important, not because negative productivity takes over and erases all of the week’s accomplishments.

So do I worry if an employee makes the choice to come in on the weekend or work extra hours in the evenings on a project that he or she is excited about? Not at all! That is virtually guaranteed to improve productivity, not reduce it. But I don’t expect employees to do that and when they do, I generally make it a point to reward them for it.

So what about the Maxwell Curve? Well, I can’t just leave a blunder like that alone without attempting to correct it. So until Scott Maxwell updates his curve, I’m going to have to introduce the world to Hamid’s Curve:

Disclaimer: The above graph shows the probable relationship between productivity and work-week-hours and is totally non-scientific. It’s a rough sketch drawn from experience. :-)

Update:
Some people have suggested that I didn’t take into consideration the negative productivity of teams when the rate of bugs are increased as a result of fatigue from long hours. But that’s precisely why productivity goes down significantly and can even (in rare cases) go negative. In the article, I explain that I definitely agree that the rate of productivity goes down and often hits 0 at some point, however, Maxwell’s graph suggests that if you work a 60 hour week in Scrum, your overall productivity (not your rate) for the week is actually 0. The graph actually shows rate of productivity going negative somewhere around 32 hours. It further goes on to suggest that somehow, you’d be better off using a waterfall model if your team regularly worked 52-hours (or longer) weeks because teams using waterfall don’t hit 0 overall productivity until 80 hours of work. Those are both unwise claims to say the least.

As Dennis pointed out in the comments (see below), another interesting graph would be the “Rate of Productivity”. Here, I’ve graphed what typically happens as the work week increases in duration:

%d bloggers like this: