Use Case

Lack of Progress Bar (Lopb) can be used for a variety of different purposes, but the primary use-case that we are targeting is to help development teams justify a request for new or improved development tools and infrastructure within their enterprises (i.e. ROI based on time savings). Such a justification based on tangible metrics is sometimes difficult to obtain. Lopb aims to solve that problem.

Problem: How to justify an upgrade

Developers may say things like:

• My laptop or desktop is too slow.
• I’m wasting too much time waiting for my code to compile/build/deploy, etc.
• It takes forever to check-in/check-out code on the server (source code repository).

Managers may wonder:

• How slow is it?
• How much time is wasted because our tools are slow?
• Should we upgrade our laptops/desktops, our servers, our software, or something else?
• What would the ROI be if we upgraded?

The problem is that many development teams don’t have a benchmarking tool to answer these questions with actual metrics. They’re forced to rely on their “gut feeling”. Unfortunately in many enterprises this may not be enough to convince executive sponsors or other stakeholders that an upgrade or other change is required.

Solution: a benchmarking tool to help calculate ROI

Lack of Progress Bar (Lopb) is an Eclipse plug-in that monitors how much time is consumed by background jobs. It presents this metric as a percentage of the total development session time.

For example:

Background jobs ran for 9% of a developer’s day.

Background jobs are:

• Operations on local resources  (e.g. open/close/edit files, compile, build, etc.)
• Interaction with server resources (e.g. source control add/update/delete and check-in/checkout, deploy, etc.)
• System or IDE background jobs (e.g. garbage collection, GUI refresh, etc.)

Developers are not necessarily blocked by a modal dialog while background jobs run, but…

• Overall system performance is usually degraded while they run, and
• Developer productivity will be impacted if he/she depends on the outcome of the background job(s)

Example: Calculating ROI for a hardware upgrade.

Here is how a development team may proceed to calculate ROI for a hardware upgrade for developer machines.

1. Install Lopb on one or more developer machines. (Developer machines should be similar in terms of system hardware and software installed).
2. Lopb will run behind the scenes collecting data, but not interfering with development.
3. After a period of a few days, the data from all developers is aggregated and analyzed. A simple metric is produced showing how much time is consumed by background jobs on average per developer per day (Example: 9% of the average developer’s day is consumed by background jobs).
4. Implement the hardware upgrade for some (but not necessarily all) developer machines.
5. Let Lopb collect data on the upgraded machines for a few days.
6. Once a few days have passed, aggregate and analyze the new data to determine the new metric for time consumed by background jobs on the upgraded machines (Example: 6%).
7. Finally, compare the new metric with the old one to determine ROI as shown below. If deemed to be cost effective, upgrade the remaining developer machines.

{TODO: ROI calc here}

Value Proposition

Lopb gives development teams the evidence they need to

• Know where they stand today (How slow? How much time lost?)
• Know what they should change (in terms of tools and infrastructure)
• Know whether the change had a positive effect or not (compare to previous metric)