The decision procedure

[lorenzogrv]

Those big tasks on The life cycle are tasks that "will never "end, as part of the continuous continual improvement process that I want to achieve.

(laconbass @ January 2015)

This reasoning comes to me while reading about Modular Programming on wikipedia, while taking a break after #1.

While writting this issue summary, some research has been done about "continual improvement process", some things I should note from now onwards:

1. The word continual should be used instead continuous. Why? See CIP on wikipedia.
2. The japanese word Kaizen arises. This can't be coincidence. See CIP on wikipedia and Kaizen on wikipedia.

Found a valuable knowledge on the overview of the book _The mythical man-month_ (Fred Brooks)

My head is also burning out now with posible restructurations of the "goals" and "design principles" documents. A try to conclude why:

As design principles should be classified some way, goals should be classified to. This classification will be personal as I will take the decissions, so it should belong on the "personal notes about the software development process".

(laconbass @ January 2015)

I conclude the following tasks should be made before doing anything more:

• [x] Some content from the wiki home "attitude" section should be spliced to other section and:
  • [x] Explain how iai will enhance speed (so eficiency) through helping developer have an attitude.
  • [x] The "attitude" section should state only _why iai is considered an attitude_
• [x] A document describing my personal notes about "the software development process" should be written and maintained.
  • [x] It should note my deficiencies of knowledge as I'm not an academician of computer science.
  • [x] It should note my feeling on "how to do things the right way" (continualcontinuous improvement), and maybe the misterious appearing of Kaizen while researching to write it down.
  • [x] It should define a cycle, so i can structure "the software life cycle". Keep in mind the knowledge, don't reinvent the weel.
• [ ] The whole "Life cycle" document should be refactored because no clear sequence exists between those big tasks.
  • [x] It should reference my personal notes at the first place

[lorenzogrv]

Calling each stage/step/or-the-like PHASE confuses myself. It seems better to think on "the big tasks" as a kind of states or other word that assumes the fact that there isn't a fixed sequence of steps that cycles again and again on the same order (i.e. [:A-B-C-D:]).

The fact is that I jump from any "stage" to any other "stage", so the concept of unknown is here again. It's clear that working with the unknown is a key.

[lorenzogrv]

So a kind of a draft of the method/strategy I always apply is:

1. Observe and identify
2. Research and decide
3. Review and evolve (repeating 1, 2 and 3)

Mental verbiage: IDEA => Identify, Decide (or simply "Do"), Evolve, Again. It's not good enough, but keeps the way to the bell ding.

[lorenzogrv]

Refined the iai concept at the wiki Home page. Think LATER on keeping that knowledge on a separate page, as it is SO IMPORTANT!

"Assumptions" seems a pretty good title for that "personal notes about..." stuff. Start it as a concise introduction for the Life-Cycle document itself, and see what happens.

[lorenzogrv]

Done writing those "notes about..." Reworded to "the decision procedure", which actually is what it's need. More tasks:

• [x] Edit the _Sidebar to add links to "concept" and "decision procedure"
• [x] Reference the home on the concept introduction

[lorenzogrv]

This issue loses the focus. It has become a self-dicussion about the decision procedure so the job here is done for now (until it needs review). A new issue regarding the life cycle must be created and I'd focus on it.

Note this issue can only be closed when the decision procedure is successfully applied to refactor the life cycle. The last task before close would be:

• [ ] Refactor this issue summary

[lorenzogrv]

When discussing and researching it probably belongs to an issue