I wrote a reply earlier to @reggaemuffin's post on proposals for improved requirements for future hard forks of Steem - some good points are made in there. In my reply I related my experiences working for a software development company that made software for investment banks (over 15 years ago) - I learned a lot there regarding solidly reliable methods of development and teamwork (and also during my previous degree training in software engineering), yet most of it appears to be rarely used by the majority of software projects I see in the public eye today. Here's an expanded version of that reply.
Structured Design / Development is More than Just a Formality - Teams Need It!
In software development, types of structured / formal design and development are used in general for creation of systems where failure is not an option. These approaches include a high focus on production of documentation, diagrams and careful modelling/recording of the current system and any changes to it. This allows precise monitoring and management of changes and also ensures that failures can be dissected both reliably and independently to improve future performance. In short, these methods may seem in opposition to the idea of 'anarchy' and decentralisation, but in reality they are just a necessary part of the process of reliably making reliable software. At the very least they allow outsiders and short term contractors to get involved to help without having to spend weeks trawling through code and interrupting the core team with questions.
If we want to have a team working together remotely (over github and the web), then at the very least we need a coherent way for the team to grow through it's own effort and learning, based on good documentation. There are a wealth of smart and qualified people online and no doubt using Steem too - but if they can't find a way into the technicalities of the project then they can't really provide their expertise. What better way to use Steem's reward capabilities than for improving Steem? Yet, even Utopian - Steem's method for rewarding open source code development - doesn't even have the Steem projects Whitelisted, so we can't use it!
The problem I see over and over with the github / decentralised approach is that pretty much no-one produces proper design documents and technical writing (steem code doesn't even have full commenting). This means that the 'decentralisation' is highly limited since most people won't get involved as they can't gain mental overview of the project, plus it also means that it therefore isn't so much 'decentralisation' as it is 'centralisation with the convenience of public file storage for the project'.
I have pretty much never seen such formal methods used anywhere outside of military/gov/banking/science software areas (large corporate entities) - mainly because of the time and cost involved. Since most of the coding I am interested in takes place in open source now and on github.com and since these projects are largely non formal, it has been a long time since I saw ANYTHING approaching this level of design work on any modern project (although I don't spend my days looking at a large number of projects).
Don't Let The Old Systems Eat The Evolutionary/Revolutionary Ideas
Since cryptocurrency aims to literally topple the prevailing criminal banking systems - it is important that those involved don't take lightly the value of formal documentation and best practices for testing and teamwork. I can see a situation looming where the large corporate teams use their experience in such things to introduce their own version of crypto to the world and take over, as if this 'revolution' never happened. It's great to think freely and create new ideas such as Steem, but if it isn't backed up by a solid foundation, then it will be replaced.
Practical Steps For Improvement
It is not wrong to take the useful approaches from the 'old world' and use their best parts to go forward into a better world. I strongly urge that those involved take steps to increase:
- transparency
- formalisation of documents and designs
- visibility of documents/designs and roadmap
- potential for collaboration
- community involvement in testing
The funds available to Steemit inc. and even the top 20 witnesses make hiring technical authors, testers and the appropriate support staff easily within reach - yet I don't see any evidence of it being done. I can see that the Steemit job listing page has several technical vacancies, but none for any of the other architecture, testing, QA, technical writing or other support roles that are vital to success. Why is that?
My Own Personal Steps To Help
As a witness for Steem and as an avid user of Steem, I'd like to be able to help out more - but my hands are partially tied by the points already raised. Some of the top 20 witnesses apparently work together to test and improve the code to some extent, but they discuss this in a private chat room - so I don't really know the extent of it. Additionally, the code for Steem is largely in C++, which is a language that I personally haven't used for many years - so it would be a steep learning curve for me to become a dev for Steem right now. On top of all of this, I have bills to pay and am not earning enough from Steem to cover them.. So, I either need to get more witness votes to get more reward, to dedicate more time to the project - or I have to limit my help substantially.
At the very least I intend to find some time to learn to help to test future Hard Forks - as yet I don't know how practical that is for me though, without some financial help for my time.
I would be happy to help with diagramming and technical writing to some extent too - though I would need to have much greater access to the work that is being undertaken and the people involved than I do currently.
Anyway, some thoughts to chew on for you all!
Wishing you well,
Ura Soul
Vote @ura-soul for Steem Witness!
(Witnesses are the computer servers that run the Steem Blockchain.
Without witnesses there is no Steem, Steemit, DTube, Utopian or
Busy... You can really help Steem by making your 30 witness votes count!)
