Case Status
Log In


OASIS Development - How long d…
  • RSS Feed

Last modified on 2/6/2018 12:27 PM by User.


OASIS Development - How long does it take?!



We receive requests for new ideas, adjustments and bug reports daily. Daily we release an update implementing new features and/or fixing bugs. The question is: how long does it take for “my” feature to be implemented? This document addresses how we prioritize development tasks and what is involved with various updates to OASIS.


Starting January 2, 2007, Ingen Software will no longer suggest when a new feature or bug fix will be ready until testing of that item begins. We want to continue to deliver the best possible software as fast as possible and this requires us to prioritize development internally and maximize our development efforts.


Software development is one part engineering, one part art, and one part magic (the sleight of hand kind). In short, it takes time to setup the conditions for a new feature to be implemented. Once implemented, it again takes time to test and receive feedback from users to make any necessary adjustments to the new software.

To address the complexities of software development, we prioritize development tasks using this rough model:






Formally defined: OASIS feature does not match documentation.



Formally defined: OASIS feature observed to function in a manner that is not consistent with the general business model for lighting sales agencies or distributors.


New Feature

New idea accepted by Ingen Software as a good idea for a new OASIS feature.


Form Change

OASIS form changes require custom software development at Ingen Software. Some form changes also require code changes in OASIS and will take more development time.



A change or addition to the OASIS documentation


Additionally, we weigh these priorities based on the size of the installed OASIS user community that would be affected by the change. The more users affected, the higher the priority. This does result in cases where a new feature affecting the entire OASIS user community is implemented before a known bug that affects a single user.

Quick changes are typically pushed to the top of the priority schedule. Some of the development items take months to develop. For this reason the “quick ones” are regularly collected and implemented to ensure continuous albeit gradual improvement  – even if the priority of the item is rather low.

(Custom development for one organization funded by that organization is prioritized differently.)

Man Hours

It is common to estimate the amount of work required to develop software in “man hours”. This is the number of hours required for a single developer to create or alter software to fix a defect or implement a new feature.

Unfortunately, there is no easy guide to determine the amount of time required to implement a change. The only guideline we have is that a form only change in OASIS typically takes 1-2 business days – but only if no changes are required to the OASIS system itself.

The worst case scenario is when a database change is required. In this case, there is not a location in the OASIS database to record information required by a new feature. Database changes require a minimum of 3 months planning and 1-2 months to deploy.

THE WORST OF THE WORST: Want to hear a developer cry? Just say you are having a problem with a printer (application crashes, print gabled or print the wrong size). Or mention that when you press the <TAB> key, the “cursor jumps to la-la land”. These are some of the hardest problems to solve!

Here are some examples of OASIS projects that have been completed recently and the number of hours required for development:

Adding “Transmit Date” to the Manufacturer Shipping Request report:

Hours: 0.5

Implementation Tasks: Added the variable “TransmitDate” properly formatted to the report generator. The form was changed to include “Transmit Date” in the header of each PO.

Unit Testing: The report was run against a regression database to determine how the report looked in the previous version. Then the new report generator was run against the same database to view the result.

Defects Resolved: (All defects found in Unit Testing.) Date was not originally shown, but label was. The data tag in the XML did not match the data element created by OASIS. Changed OASIS to match the more natural tag of TransmitDate. Date was shown truncated. XML was altered to allow for enough space on the printed report for the date.

Allow the use of “Lamps” within “Kits” in projects and quotes.

Hours: 16+ for coding. Planning, testing and feedback from users took about 30 days!

Implementation Tasks: Rewrote the following code modules:

  • OASIS quote object (the kit and global total recalculate logic was very tricky!)
  • OASIS quote line object
  • OASIS quote print renderer
  • OASIS Order Create routines
  • OASIS Submittal creation routines, including the “roll up” features.
  • Various OASIS reports

Additionally, a number of smaller routines were altered to account for the updates to the new OASIS quote and quote line objects.

Implementation Strategy: The first try at implementation was thrown away as the goal was to simply apply the same lamp rules used with the “part” lines. The second concept was to rewrite the tests for “lamp” and “kit component” into a single test taking a Boolean argument as to whether the customer was including lamps or not. Once implemented, all the resulting “compile errors” were used to identify the modules requiring change. Each module was identified and altered independently.

This method relies heavily on testing. A quote was configured to test the quote and each of the features identified as “changed”. A full regression is not possible (identifying the number of permutations would have taken weeks). However, the use of “educated testing” (based on code changes) and the use of existing user data simplified the testing while maintaining quality.

Unit Testing: A regression database was used to compare the output (forms) and features (order creation, submittal creation) behaved as expected. Numerous iterations were performed between unit testing and implementation.

Conflicting Requirements

We have implemented many OASIS features over the years and shown them to numerous clients that have embraced these new ideas. The result for the client is a new business process including people, processes, OASIS and possibly other business elements.

Ingen Software has adopted the philosophy that new ideas are always presenting themselves and we will implement these new ideas. However, some of the new ideas conflict with how OASIS currently operates. Additionally, some of our clients disagree on how a feature is to be implemented.

To resolve these conflicts we have to take time during the implementation process to ask the following questions:

  • What impact will the software change have on the business processes for our existing customers?
  • If customers disagree on how a feature is to be implemented then should we create a global preference to alter the behavior? The other option is to implement the feature as a custom extension to OASIS (the client will be charged for these changes).

In short, it takes time to resolve these issues. Additionally, conflicts are sometimes discovered after a new feature is released, forcing us to delay the final implementation while we create a global preference or work with the customer with the conflict to develop a work-around.


So what is the answer: how long will it take?!

The good news, unlike manufacturing, shipping time over the internet takes minutes. The bad news is software is both engineering science and art. If the bug being fixed or the feature being implemented is similar to other work that has been performed recently, a fairly accurate estimate is possible. Otherwise, the answer to “how long it will take” is largely unknown.

Complicating matters, a “nasty” bug affecting all OASIS users will preempt all development efforts.

For these reasons, we record all bug reports and feature requests and continuously enhance OASIS!