How to start with this project

Please check from here the instructions:

• howto.txt (raw)

References

• Author: Roberto A. Foglietta [email protected]

• Repository: https://github.com/robang74/tinycore-editor

• Forum: https://github.com/robang74/tinycore-editor/discussions

• Google group: https://groups.google.com/g/tinycore-editor

Usefull links to visit

• rufus - https://github.com/pbatard/rufus/releases/download/v3.14/rufus-3.14.exe

• tc forum - http://forum.tinycorelinux.net/index.php?topic=18682.0

• tc corebook - http://tinycorelinux.net/corebook.pdf

• tc linux - http://tinycorelinux.net

---

Rationale

This project is a proof-of-concept of an Embedded System Building Suite based on TinyCore Linux distribution. It is broken-by-design to produce a non-certifiable system even under the mildest standards. Its development history is quite amusing and inspired by a real-life human case.

Development Model

First of all, it needs to explain the Development Model of this project because it is particularly educating about how to NOT deal with IT projects and about how to NOT manage IT senior people.

Born by asking for an emergency immediately available single-use workaround, it successively grew with a long series of small features addition out of any project planning and without any architecture design or redesign. In other words: in adding a new feature as little redesign as possible has been done.

We can call this kind of development model as

• monkey-coding design-blind features-addition

Which is quite amusing because it explains how evolution works but in this specific case just the bare-minimum non-competitive natural selection process-like has been implemented:

• if it works then does not change it.

Despite all these limitations in the developing model, the result is still interesting in many aspects and also some good ones.

History Case

In the past, I worked with a skillful system architect with a deep understanding of the system on which he was working, but with a surprisingly monkey-coding attitude. Quickly, I realized that it was the environment and not the man being negative. It is irrelevant to say anything else about that experience.

Years later that experience, the monkey-coding design-blind features-addition development model gets real. Moreover, a new motto had a birth:

• you get what you {ask,pay} for - is the new - WYSIWYG.

To the imperishable memory of all my colleagues who decided to live stressless as paid monkey-coders to devote themselves to the things that are important for their own life and nothing else.

Teaching Tool

Despite everything above, this is a great teaching tool because its redesign implies being able to deal with legacy systems. Trust me when I say that there are a lot of legacy systems out there in the real world that requires a progressive redesign because the companies which rely on them are not willing to invest in a brand-new alternative.

From this point of view, it is an opportunity to learn skills for a real-world specific market segment: scrum/agile development VS scrum/agile redesign. Both are progressive and deliverable-based ways of working and continuously bring value. The main difference is the starting point.

Finally, we learned that things can work despite an ill-or-none-at-all design.

Lessons Learned

For those who are more interested in learning some theory than dirtying their hands deep into the code:

• My SCRUM in a nutshell for Project Management

and

• P²C² Management Style for Team Management

Adequately managing a project is just as crucial as managing the people involved in the project. There is no way to separate these two aspects or avoid them. Undoubtedly, it is not a cheap approach, and this is the primary reason because numerous attempts to industrialize creative intellectual IT work have been made, in vain, since the burst of the 2001 dot-com bubble.