The life cycle

[lorenzogrv]

Leading to a new issue from the research and decisions from #8.

The life cycle needs to be thoroughly defined.

The lifecycle document is about the workflow and the tools.

@laconbass, February 2016

Keep thinking about the nature of documents and the utility of documents rather than what "stages" must include the life cycle as a workflow.

Things being documents:

• Issues
• Manifestos
• Methodologies

---

Naming is hard. Naming is an architecture thing.

@laconbass, February 2016

• Design is everything:
• Interface: Coupled with visual art, wireframing, user experiencie, interaction
• Planning
• Inventory
• Sketching
• Prototyping
• Assemby
• Architecture: Coupled with naming, definition, context, relationships, the whole and the parts, the abstracts
• Implementation: Coupled with details, code, the concretions

---

The code source control methodology relates to the lifecycle. It is a technology choice.

As I'm not an expert using git so seems better adopting an existant code source control methodology rather than developing one. Avoid NIH.

@laconbass, February 2016

The documentation is a planing thing. It's also a decision-related thing. It's also a referencing thing. It has to do with architecture, design and implementation.

Documentation is sourcecode. Documentation must be commited to repositories.

@laconbass, February 2016

Working with the unknown seems too conceptual (related to the concept) to fit within the Lifecycle.

The issue summaries should be documentation. How to call a document where some mental reasoning is done?

[lorenzogrv]

http://federicoiosue.github.io/Omni-Notes/

[lorenzogrv]

http://momentjs.com/docs/

[lorenzogrv]

Related to Software Project management.

John C. Reynolds, argues that software development is entirely design work, and compares a manager who cannot program to the managing editor of a newspaper who cannot write.

John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN Notices, Volume 43, Issue 11, November 2008, p.108: "Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write."

[lorenzogrv]

Everything is design so. That sounds familiar. Anyway, naming is an architecture thing. Naming is hard.

Naming has to do as much with the thing named as with the relations it has with its environment. Naming is putting a thing on an environment.

[lorenzogrv]

It seems to much explanation about the tools, and not enough about the workflow. Details about the tools should be a reasoning.

[lorenzogrv]

Some parallel architecting on document types and its relations seem neccessary to avoid:

• Losing mental effort (thoughts not written) when losing the focus while writing on issues.
• Going too deep on something while writing documents. This point has the benefit of discovering things at reviewing that can be fixed with refactoring, but is slow.

At origins every thing created is nothing, so unknown. Working with the unkown is origins.

[lorenzogrv]

Manifesto: A document that exposes feelings and whishes about something to be achieved.

Document: A plain text file with the ’md’ extension written following the HTML5MD Convention.

Specification: A document containing a set of names and definitions with some relation between them.

This are some whats, it seems whys and hows will be neccessary though.

[lorenzogrv]

Documentation is source to software as code is. Documentation has software entities - documents - meant to communicate software to humans, as code has software entities - objects - meant to communicate software to machines.

[lorenzogrv]

It's not a problem of deeping in tools. It's a problem of hierarchy: Can't make a methodology or workflow without having a reasoning first.

Workflow seems a better name than methodology. Methodology suggests a too restrictive procedure. Going too restrictive will impact negatively the creative/invention process.

[lorenzogrv]

Documentation is not only the documents. Documentation is also diagrams or other kind of graphic resources that are useful as documents.

useful as documents seems like a "why is the documentation important"? so... why? seems obvious but is somewhere defined?

[lorenzogrv]

Everything is design, so let's apply (actually applying without knowing) a kind of write-first design:

writing-first design is a strategy to work with the unknown. A strategy to work at origins.

[lorenzogrv]

http://c2.com/cgi/wiki?PowerOfPlainText

[lorenzogrv]

http://jekyllrb.com is about the power of plain text