ORA:: Development discussion thread - page 9.

Hello to all.

I have agreed to lead the development of Kora. I'm going to split this intro into three posts. This first post will let you know some things about my experience and my development philosophy. The second post will discuss the already-expressed concerns and questions I have read in the Kora forum. I realize there are a great many questions about the road ahead, and to be honest, we are in the very early phases of this project, and a successful project is not just about sitting down in a dark corner and pounding out code. There are a lot of discussions yet to be had, and a great deal of planning as well.
The third post will discuss in more depth the phases of the Kora project.

I have been in tech a long time, working for and with every type of company from corporations to small businesses, government and non-profit. I have worn many hats, from IT manager to developer to lead developer to project manager to database admin, and much, much more. I have worked in both Windows and Linux environs. I have coded all manner of languages, compiled to interpreted. I have led projects that lasted many months, and ones that lasted days. I have experienced the thrill of delivering a significant development project, only to have the project cancelled on release day. I have fixed bugs that were simple syntax or spelling mistakes that took a few minutes to find, and I have debugged distributed systems that required hiring teams of consultants and subject-matter experts, and taken months to complete.

My most recent projects involved writing a number of payment card industry interfaces, and leading a team through PCI-DSS and PA-DSS, which processes are heavily vested in forensic examination of code and the platforms on which they run. To say the payment card industry is proactive with security is an understatement. In addition, I have written a number of apps and interfaces in support of telephony initiatives, for third-party control of analog or digital phones.

My development philosophy favours simplicity and elegance over complexity. I believe in starting small, but with big blueprints, and therefore I believe that the best apps are ones that provide a core function and do it well, but are architected such that they are extensible and scalable.

As for coding, I prefer code reuse whenever possible, up to and including cloning an entire cryptocoin codebase. I see people all the time singing praises of some app that has an "original" code base. That might be worth a brief price pump, but what does it really mean? More often than not it means that someone spent an inordinate amount of time writing an original clone of an already finished product. There is a time and place for that, but it pays to explore existing solutions. And more importantly, there should be a very good reason or reasons to start from scratch.

If you go through the codebase of any coin, you will see that most code is not truly original in the aggregate. Who is going to write a new java library when one already exists that is both optimized and free? Why not use the boost libs in C++ instead of writing your own? Or STL? Even the web uses libs now. Go to any modern website, and you'll see the prolific reuse of JQuery and hundreds of other JS libs that are free to use and customize. This is not cheating - it's sensible. When a civil engineer builds a bridge, he doesn't build a new kind of bridge. Instead, he reuses best practices and designs that have proven themselves effective.

I am not a language purist or a language snob. I don't have any opinion about what the best language is. I have coded a number of them, some I guarantee nobody has ever heard of or ever will hear of. The fact is, most modern high-level languages will get you where you want to go. There may be business reasons to use a specific language, such as prevalence of people who know a language, or even client requirements. It would be somewhat insane to code Kora in LISP unless there existed a huge pool of people who know the language, and who could be easily and cheaply recruited. So, if I decide the way forward is in CPP and not Java, it does not mean that Java sucks. It means that given the project requirements, CPP satisfies more business requirements than does Java. And the reverse may be true. I'm not saying that I have made any decision about language, this is merely an example. What I am saying is when the time comes, I will choose the language based on the business needs of the Kora project.

Now that I've regaled you with a bit about myself and my development philosophy, the next stage will be to post something soon that answers questions from the main forum, and also a post that defines the project and its phases.

Stay tuned.

-nio

Topic: ORA:: Development discussion thread - page 9. (Read 13431 times)