Building a Better Integrated Time Charging System

We could use information oriented software development to create a better integrated time and employee managing system. It would manage the following integrated features:

Endeme Set:
ABCDEFGHIJKLMNOPQRSTUV|
----------------------+
A]      -J-           |A. Assignment    Job assignment
[B]    -I-   -O-      |B. Business      ideas, opportunities
 [C] -G-        -RS-  |C. Creativity    Skunk works, research
  [D] -H-      P-   -V|D. Days off      Vacation, PTO, Holidays
 -C[E]            -T- |E. Expenses      Travel time, commute
    [F]       -P-     |F. Flow          Workflow, processes, procedures
A-   [G]      -P-     |G. Geographical  place, time
 -C-  [H]         -T- |H. Hours         Time Charging, clock in,out
       [I]        -T- |I. Incidents     Trouble tickets, tracking
    -F- [J]  -O-      |J. Job Functions Ongoing tasks
A-C*     [K]M-   -S-  |K. Calendar      Schedules, Availability
          [L] -P-     |L. Long jobs     Projects
 -C-       [M]-P--S-  |M. Money         Salary, compensation, pay
A-          [N] -R-   |N. Needs         Requirements, available work
        -J-  [O] -ST- |O. Orders        Tasks, short jobs, work orders
       -I-    [P]     |P. Passions      Personal interests
A-         -M--P-     |Q. Project phase Agile development
       -I-   -O-[R]   |R. Relationships Interactions, organization
A-               [S]  |S. Skills        Abilities, experience
A-                [T] |T. Talents       Aptitudes
              -P-R-[U]|U. User Position Responsibility, permissions
      -H-       -R- [V|V. Virtual work  Remote work, work from home
----------------------+
ABCDEFGHIJKLMNOPQRSTUV|

Endemes:
GKS.RT    - Availability
MNE.ALP   - Budget
HMI.E     - Business metrics (qualitative and quantitative)
AMR       - Contracts
BTC.P     - Growth opportunities
ASN.MPTV  - Hiring
TAJ.PRN   - Job re-engineering
GKR.QM    - Meetings
QKL.ANRST - Project management
BRN.GP    - Prospects, client relationships
GST.MP    - Resources

There are some big packages that do this so competing is probably out of the question. These packages to tend to miss a lot of these items however. That is a result of the failure to incorporate information oriented techniques in the development of the packages.

Zero, One and Infinity

There is an old ‘rule’ in software development that when you provide a capability you should provide it so that it can be used either zero times, one time, or an infinite number of times.

Endemes take the ‘one’ option to extremes. You can only use each letter in an endeme set once in an endeme.

Contact Type Endeme Set

Here is an endeme set for contact types and addresses

Address/Contact Type Endeme Set
ABCDEFGHIJKLMNOPQRSTUV|
----------------------+
A]C-                  |A. Acquaintance
[B]D-                 |B. Birth
 [C]      -L-     -T- |C. Current
  [D]     -L-         |D. Driver license
   [E]       -O-    -V|E. Employment
    [F]       -P-     |F. Former
 -CDF[G]              |G. Grave
      [H]    -O--R-   |H. Home
    -F-[I]  -NO       |I. Immigrant from
    -FGI[J]           |J. Judicial
         [K] -O-      |K. Keeper
          [L]         |L. Legal
           [M]        |M. Mailing
            [N]       |N. Next
-BC--F-      [O]      |O. Organization
              [P]     |P. Permanent
A-           -P[Q]    |Q. Query
     -G-        [R]   |R. Registry home
A-           -O- [S]  |S. Storage
              -P- [T] |T. Telephone
     -G-           [U]|U. Unspecified
-B-    -I-  -N-     [V|V. Wrong
----------------------+
ABCDEFGHIJKLMNOPQRSTUV|

Different Talents are Stressed for Data and Information Oriented Programming

A somewhat different talent endeme is useful for a data oriented software developer and an information oriented developer.

DOSD:

  1. Inductive reasoning
  2. Practicality
  3. Deductive reasoning
  4. Creativity
  5. Q-recognition
  6. Reason
  7. Advocacy

IOSD:

  1. Q-recognition
  2. Deductive reasoning
  3. Creativity
  4. Reason
  5. Practicality
  6. Inductive Reasoning
  7. Advocacy

Deductive reasoning and creativity are important for both.

Will I Build A Level 3 Computer Language?

People have asked me on occasion if I am going to build a computer language for level 3. It makes sense that there would eventually be one. However I don’t know enough about level 3 yet to do it. I do have a few ideas.

  • Classification divides things into classes. Characterization ‘sorts’ things into ‘mixture classes’. If I’m building an information level language maybe I need to invent ‘mixture classes’
  • An equivalent of fuzzy logic for endemes.
  • Endematic paths that are neither relational nor hierarchical but have the characteristic that the path order either does not matter or is not completely deterministic of the location addressed.

The language may have to include level 4 also to be useful.

Using Alpha Codes for Things in a Database or Program Requires Lots of Overhead

I often see short alpha codes or single letters used as keys in database tables. This is generally bad practice because keys should not contain content. However it reveals an information oriented tendency of some developers that sometimes leaks into database design. Alpha codes should not be used when doing data oriented work. They can however be used when doing information oriented work.

Alpha Codes Need Overhead

In order to work with alpha codes effectively, endemes provide an natural effective means of working with codes. Codes need an extensive framework to be useful. In other words codes need overhead:

  • endemes or constants
  • alpha code interpreters
  • endeme sets

Without this sort of overhead, the meanings of the codes are not supported in the software you build.

Go All The Way

Go all the way if you choose to use an information oriented approach to tackling this challenge. The sort of overhead described above supports  the meanings of the codes in the software you build. You have a choice. Either let object orientation do the work or do the work yourself to build a big information oriented framework. If you go the information oriented route it is important to not do the information approach part-way:

  • You do info part way when you ave a code table without endeme structures to define and describe and give meaning to the codes.
  • You do info part way when you have literal fields without endeme structures to define and describe and give meaning to the field names.
  • You do info part way when you make complex parameter inputs to a retrieval sp or method and the retrieval structure is not handled as information?
  • Dynamic page construction should be an outgrowth of information,not simply done because you can do it.