RE-ENGINEERING DEMOCRACY: Programmer's Guidelines

by Ric Carter

ONGOING PROJECT

It'll get better, I promise.



    Contents

  1. Analysis and Design Technologies
    HIPO (Hierarchical Input-Process-Output); Structured Approach
  2. Functional Considerations
    System Goals (outputs); Environment (inputs)
  3. Procedural Considerations
  4. Programming Considerations



Analysis and Design Technologies

As with any major system, Democracy and other political structures are susceptible to improvement via utilization of the techniques of Top-Down Structured Analysis and Design. Proper application of these techniques will produce a political system with fewer flaws and an easier maintenance load.

The basic techniques involved are straightforward. We'll follow standard structured analysis methodologies to implement the HIPO (Hierarchical Input-Process-Output) design model -- see the standard texts [Yourdon, DeMarco, et al] for more on this.


  1. Specify the desired Outputs of the system.
  2. Specify the available Inputs to the system.
  3. Based on the preceding, utilize structured analysis to design a Hierarchical tree of the Processes that will transform the available Inputs into the desired Outputs.

    Top-Down Analysis
  1. Define the problem in general terms.
  2. Break the problem down into more specific sub-problems or tasks.
  3. Continue the analytical process until each task is defined in the most specific terms.
    Bottom-Up Programming
  4. Design local solutions to each task.
  5. Start assembling the task solutions, testing the functions and interactions as each solution module is implemented and integrated into the system.
  6. Assemble and rigorously test the entire system

In a rigorously-structured system, only defined data is transferred between modules, and no module is privy to information that is NOT defined for it -- this is known as "data hiding". In any but the most totalitarian political systems, however, such limitations are undesirable. Transparency of information should be taken into consideration during analysis, design and programming.

Object-oriented technologies are also appropriate here -- again, see the standard texts for details. In general, an object consists of 1) information, and 2) rules to apply to that data. Derived objects inherit their rules and data from more basic objects. As with strictly-structured systems, strict object systems implement data-hiding, which is incompatible with the functional operation of the political system.


Functional Considerations

The HIPO model is driven by 1) the desired outputs, and 2) the available inputs. The overall definition of the GOALS of the system serve to define the outputs. The reality of the ENVIRONMENT of the systems serves to define the inputs. These must be looked at very closely if a usable system is to result.

System Goals ==> outputs

Some areas requiring careful consideration when specifying the system outputs include the following:

  • You probably want a STABLE system, to reduce the need for recurrent re-engineering. Stability may be either 1) static, 2)  dynamic, or 3)  other, and I can't envision what option (3) might entail, so we'll stick with (1) or (2). A static system can't adapt to a changing environment, and thus us only truly stable when extinct, so we're left with option (2). We MUST build a dynamic political system, or else we're just jerking off here.

  • You have to consider who is to CONTROL the system. Options include 1) theocracy (rule by deities and their minions, 2) aristocracy (rule by hereditary elites), 3) oligarchy (rule by exclusive elites), 4) kleptocracy (rule by thieves), 5) democracy (rule by the people), or 6) other. We're trying to re-engineer DEMOCRACY here, so we'll stick with option (5).

  • You have to consider the possible STRUCTURE of the system. Options here may include such forms as the 1) republican, 2) parliamentary, 3) monarchial, 4) matriarchal / patriarchal, 5) syndicalist, 6) other, or 7) some combination of these. Be creative here.

  • You have to consider the desired functions of the system. The basics seem to be well specified in the Preamble to the US Constitution:

    • Unify numerous diverse communities ("form a more perfect Union")
    • Handle alleged transgressions against anyone ("establish Justice")
    • Handle disputes between varied interests ("insure domestic Tranquility")
    • Handle attacks against the system ("provide for the common defence")
    • Maximize potentials for all citizens ("promote the general Welfare")
    • Minimize interference with citizens ("secure the Blessings of Liberty")

      (You may quibble with my succinct paraphrases. Tough.)


  • You have to consider the broader scope of these functions, what sub-functions they can / may / should encompass; what functions are the province of the political / legal / governmental system; what possible functions are beyond the scope of the public sector; how private [profit- and nonprofit-oriented] organizations relate to the democratic system; how PEOPLE actually fit into and are served by these functions.

  • You have to consider just what informs those functions. Is the system to implement any specific moral/ethical standards? Can those standards evolve? Who chooses the standards? Is the system to mandate the choices available to citizens, or to endorse their own choices, or to be neutral? Are all those basic functions to be defined narrowly, broadly, stiffly, flexibly? Who has a voice in choosing the definitions? Can / should / will these functions also be influenced by factors of wealth and social status, ethnic and gender identity, ideology, (in)sanity, alien / human / divine mindcontrol?

    (Such considerations may be seen as INPUTS rather than GOALS, and dealt with in that portion of the analysis.)

  • You have to consider how the system is to be structured to provide and encapsulate those functions, how power and responsibility are to be allocated amongst the structural components, how balances are to be struck amongst the components. Some ways of granulating the system may be by: 1) function, 2) locale, 3) power base, 4) affinity group, 5) status, or 6) other.

    (Such considerations may be seen as PROCESS rather than GOALS, and dealt with in that portion of the analysis.)


Environment ==> inputs

The possible outputs of a system depend upon the resources that can be input into the system. Some possible resources available to a political system include:

  • A sufficient population; and portions of that populace that are: educated; educatable; potentially and actually productive, creative;
  • Existing and potential infrastructure for communications, education, exploitation / development, expansion, whatever;
  • Interest groups promoting their economic, political, religious, ideological, regional, artistic and/or other agendae;
  • The geographic base: a natural environment with space and natural resources capable of supporting your population and providing for an exchange of commodities with other nations;
  • The governance, strength, proclivities and arrangements of neighboring and associated nations;
  • The availability of captive extraterrestrials, human slaves, paranormal entities, and other entities capable of assisting your efforts. If any. Heh heh.


Procedural Considerations

Knowing what we want and what we have, we can start designing the system. But we first have to consider the purpose of the system and its place in society.


IN MY HUMBLE OPINION:   Laws are software; institutions are the social / legal devices that run that software. Society may be seen as a giant, ever-changing machine of many diverse interests, many parts grinding against each other, generating friction, requiring lubricant to keep from over-heating, seizing-up, failing. Laws, structures and institutions for resolving conflicts between interests, groups and individuals, provide that lubrication. It's a dirty job, eh? But in a democracy, the software AND the institutional machinery must necessarily be as transparent as possible; for without knowing the truth of how the democracy operates, the governed cannot meaningfully give their consent for their governance. In one direction lies anarchy, the complete fragmentation of the populace; at the other pole, authoritarianism, the complete subjugation of the populace. Democracy is the middle path, and it's processes must be transparent, visible, apparent, for the system to remain in operation.


That said, you'll face many challenges in deciding how to structure the functions of democracy, their paths of communication, their interfaces to the populace and the outside world. Some of the considerations involved include:

  • Should the system be structured in a hierarchical, relational, networked, other way?
  • How many sovereign power centers should exist? How are they to be coordinated? When?
  • How can power be limited so no institution or interest group dominates the system?
  • Should power centers and interest groups be encouraged to compete, cooperate, both?
  • Who votes, who counts, who observes? How should ballots / elections be structured?
  • How should electoral results be interpreted? What do elections really mean and do?
  • How complicated should rule-making and -enforcement process be? Who's involved? When?
  • How complex should conflict-initiation and -resolution processes be? With whom? Why?
  • How and where and when should positive and negative feedback be applied? To what end?


Programming Considerations

Once you have a system design in place, it's necessary to code and implement AND TEST all the solutions you've devised. For details on the latter, see the standard texts on Structured Testing methodologies. Keep in mind that the system, when implemented, should be considered to be in PERMANENT beta-testing. There is no final version.

Coding a political system should be tedious, fraught with compromise, and anything but straightforward. Here are some factors you'll want to keep in mind:

  • Your code must embody the complications inherent in democracy. Every procedure, every action, every utterance of every public institution is subject to 1) legislative and/or regulatory rule-making; 2) judicial review; 3) executive enforcement; 4) competitive reporting and analysis; and 5) public comment. Thus, every module needs to handle interrupts from each of these sources.

  • To have any public acceptance, your code must be written in transparent language, in terms readily accessible to the general public, not just limited to technical / legal specialists. Eschew obfuscation; flush the jargon; KISS. Every module you write must stand alone as an understandable decision block.

  • In your basic code (CONSTITUTION) do NOT become immersed in cumbersome detail; and it's good to avoid that in all your other coding. Do NOT provide convoluted procedures, tortured decision trees, windfalls for special interests, labyrinths of minutiae. Do NOT include clearly contradictory instructions. All these will come back to bite the ass of the body politic in the future.

  • As with any competent programming job, include extensive comments in your code, clearly explaining the intent and functionality of each module. These will greatly ease the inevitable maintenance and enhancement task of future generations, as well as providing clear guidelines for those charged with executing and interpreting your code.

Remember, your code is BY and FOR and ABOUT the PEOPLE. It will be executed and interpreted and judged and modified by PEOPLE. It will help and harm PEOPLE; reward and punish PEOPLE; deeply affect the lives of the PEOPLE. We all deserve your best work. Don't fock it up.

OK, OK, it's all about people -- but you should use computers to simulate the action of your code; to check for contradictions and conflicts in the code; and maybe even to evaluate, administer and revise the code. It's widely recognized that human error plays a part in many system failures. Now is your chance to remove such error from the governance system, by automating as many of its procedures as possible.




(to be continued...)


Gentle Readers, if you have any suggestions or critiques, all your contributions will be welcomed and credited. Click on my address below to email me. --Ric


DRSB ! Bisbee ! Coati Works ! Elvis !!

[home] - [GO!] - [top]

OTRSS
Ric Carter, ric@sonic.net, www.sonic.net/~ric, copyright © by OTRSS