Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

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

TinyCore Editor - Building suite for a non-certifiable-by-design PoC Linux embedded system - Teaching tool about dealing with legacy systems
https://github.com/robang74/tinycore-editor

linux-distribution poc tinycore

Last synced: 5 days ago
JSON representation

TinyCore Editor - Building suite for a non-certifiable-by-design PoC Linux embedded system - Teaching tool about dealing with legacy systems

Awesome Lists containing this project

README 

        
## How to start with this project



Please check from here the instructions:



* [howto.txt](https://github.com/robang74/tinycore-editor/blob/main/howto.txt)

 ([raw](https://raw.githubusercontent.com/robang74/tinycore-editor/main/howto.txt))



### References



 * Author: Roberto A. Foglietta 



 * 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](https://github.com/robang74/P2C2-Management-Style/raw/main/my-scrum-in-a-nutshell.pdf) for Project Management



and



* [P²C² Management Style](https://github.com/robang74/P2C2-Management-Style/raw/main/p2c2-management-style.pdf) 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.