More comments on the 36 hour work day.
Last year I noted the pace of development of this software's development was accelerated through what I called the 36 hour work day. A global application developed by the global oil and gas industry has the benefit of accessing more regions simultaneously. Earlier I wrote the following;
Lastly I want to add fuel to the fire of my adversaries by noting that the compression of time is something that will be implemented in this application. Instead of budgeting for four years, I think it can be done in two and half years to initial commercial release. (Maybe even less!). We are approaching a systems use that may start the day in Russia, China and India, move to the Middle East, Europe and then the United States. Users from these regions will be able to collaborate in an asynchronous manner. Hence providing for potentially a "day" of user driven development that totals 36 hours.
Since I first wrote about this concept the main issue that I have focused on is the User / Developer interactions, and I have the following comments. The Draft, Preliminary, Detailed and Final Specifications aggregate the industries knowledge in the form of wiki's and globally accessible medium. Starting with the text of the Draft Specification, Users will build the detail, UML, diagrams, voice, picture and video mediums to express their understanding and needs of the system. As the Developers interact with the Users through these rich media, it matters not where the individuals, teams and groups are located. All will have the current understanding available to them, and more importantly the history of how these decisions, standards and specifications were determined. A rich, searchable environment that defines the key attributes of the innovative oil and gas systems necessary to support the innovative oil and gas producer.
And it won't stop there. The code that is developed based on the Users specifications is accessible by the Developers and Users of the systems. This is done for a number of reasons, firstly to ensure that the systems are doing what is expected of them. The days of attaining assurance of the software vendors code accuracy and consistency. Assurance being attained by the size of the software developers balance sheet and cash balance I expect is over. These assurances don't provide any value in comparison to the variety and volume of eyeballs that can and will access the code the applications are derived from. Reading the code that makes up the application is reviewing the facts. Facts that Oracle and SAP don't provide for, I wonder why that is?