This page provides more details about specific aspects of the CODEiverse services.
Here at CODEiverse we can help you bring your idea to life, helping you through each phase of the process from design, development, testing and most importantly through getting an Minimum Viable Product (MVP) in front of actual customers as quickly as possible.
Our process involves starting by focusing first on the User Experience. This is the most important aspect of software development. Specifically, we provide the tools, and guidance to help you to create a highly detailed specification of what you want.
While you are immediately able to focus on the english words which describe your idea
(usually by just editing one or more Google Docs - literally), the CODEiverse technology
turns these documents into a formal, technical description of what you have described.
You manage the whole project through the CODEiverse WIKI, an easy to use website which allowes you
to explorer, develop and describe each aspect of your idea. Most every page in the specification website
has an "edit" link on it which takes you directly to the true source of that information
which is usually a Google Doc or GSheet.
Using this very detailed technical specification created by the CODEiverse Project WIKI, the tools at CODEiverse then create a custom SDK or Software Development Kit which provides 80-90% of the "source code" that you will need to implement your idea. This is called a Chameleon Code SDK, and building software by starting with a Chameleon Code SDK dramatically reduces the cost of the project, and most importantly - gives you an unparalleled level of control over the technology being developed.
Already have legacy code and/or other tech debt, no worries. CODEiverse works great with existing technology. The first thing we would do is to query your existing technology in order to quickly build an abstract model for your system, as just meta data (with Json or XML for example).
This meta data would the populate a huge area of the WIKI on day 1. Expanding on this data allows us to further build a comprehensive english description of your legacy technology. The nextstep is deciding which pieces of your code which are currently written/maintained by hand should be Codeefied, and when.
Any new code is Codeefied immediately, and the eixsting code is simply ported to the derived model over time. If it's working now, there's no rush.
A good example of this is reports. Often if we're porting from one system to another (and the datamodel changes), an expensive component of the migration project is "porting" all of those reports to use the new data model.
A CODEiverse Project (by contrast) often allows us to simply build a Mirror copy of the new data model which simply re-organizes the data to present it in the original format. At least in the short term, this often allows many or most of the legacy reports to simply keep working (as originally designed) against the new Datamodel - because there's a layer of Chameleon Code translating between these two systems.Back
All CODEiverse projects start with a CODEiverse WIKI. This is a WIKI style specification environment, where all of the content on the pages come from Google Docs. That's right, CODEiverse doesn't keep "the original" of any content in your project.
On the input side, all of your "source code" is saved in google docs, or existing technology which is maintained separately. You only share a COPY of this information with your CODEiverse account.
On the output side, every file which is generated is also pushed to the CODEiverse branch in your git repo. Because of this, you could delete (and then re-create) any CODEiverse project at any time - and it would simply rebuild itself given the same input materials.Back
The heart of the CODEiverse platform is the Chameleon Code SDK, which is always up to date and just mirrors the current specification described by the WIKI. In this way, each time the WIKI changes, the derived code automatically updates itself to match.Back
Because most of the code, even in the final, production version of the software is derived, we can create a fully functional implementation of even complicated ideas within hours or days (rather than weeks or months in a traditional development model). Further, immediately upon starting to get user feedback from actual real world scenarios, and changes are inevitably needed, the 80% of the code which was originally derived, continues to maintain itself and will simply update itself to match the new information provided through the COODiverse WIKI.Back
All of the code provided in the Chameleon Code SDK shares one common, very valuable asset. It is all "set based". What this means is that all of it is generated following the same rules. So, once a tool has been developed, it works the same way every single time today, tomorrow, next week, next month and in 6 years. It also works th same way whether it's generating 10, 1000 or 2 million lines of code. It always does it the same way.
Because of this consistency, if I have it generate code for 100 things, the odds of it doing one of those 100 differently than the other 99 is essentially non existent. So, once it works once, it will work every time - consistenly.
By Contract, if you ask a human developer to do something 100 times, the odds of them not doing at least one of them differently than the other 99 is virtually guaranteed. They will make a mistake. This is an enormously expensive aspect of hand written code.
This entire class of bug is removed from the code provided as part of the Chameleon Code SDK. Once a tool has been developed to do "the right thing" it always does that "right" thing - every single time. Without fail.Back
The code in the CODEiverse SDK is always up to date. Usually, when the specification for a piece of software changes, it requires that human beings go back into code, change it, test it, and release it before those changes take effect.
In many cases, when the Specification WIKi changes, those changes can automatically flow into the code, making those changes effective immediately, and pervasively through the entire tech stack.
Unlike in a 'traditional development model', Chameleon Code simply adapts, and blends into the new environment any time that the CODEiverse specification changes.Back
We already have tools to support a variety of different technologies, but the list is growing all the time - and as soon as you join the CODEiverse, you'll begin developing tools of your own - which create the code exactly the way that you and your team want, need and now, will come to expect.Back
Changes made throuugh the WIKI are then pushed (along with a commit message explaining what changed) into a branch in your Git repo called CODEiverse.
Your developers can then choose which of those changes to merge into the live code.Back
Usually, a "traditional" development model works like this:
The CODEiverse difference:
A CODEiversre project works qualitatively different in a number of different ways. To start with, to some extend, each of these steps happen in parallel, all at once. Because most of the decisions being made during steps 1-4 above are about identifying what needs to happen, by using the CODEiverse wiki to do this in a slightly more structured way than usual, Codee (the tool which derives the code from your specificaition) can immediately begin writing plumbing for the system being described.
As a result of this, we can get to a functional prototype in the first days (not weeks or months) and begin getting actual user feedback almost immediately. Essentially, this allows us to compress each 1-2 week sprint down to more like a 1-2 day "sprint".Back
If you have relationships with external development resources who manage one part or the other of your software development, a CODEiverse SDK is a fantastic way to take control over that relationship and make those offshore resources dramatically more efficient and responsive, by providing them with a solid foundation on which to do their work. Language problems are largely solve, by providing your offshore resources with a library which already includes as many decisions as possible which can be made before getting offshore developers involved.Back
What is an SDK?
An SDK or Software Development Kit is a library of code which provides a specific set of behavior or information. So an SDK might include documentation (english words) for people to understand the library, as well as source code such as C++, Python or Java, which implements specific functionality or behavior needed by your application.
How is a Chameleon Code SDK different than a 'Traditional' SDK?
A Chameleon Code SDK is different than most SDK's in so far as it is 100% derived. (What is an SDK?, What is 'Derived Code'?) Specifically, they are 100% derived from the Chameleon Code WIKI that is created and managed by the CODEiverse WIKI for your project.
Most software is developed without a project SDK (i.e. there is little or no derived code).
A custom library of code, derived directly from your existing tech, or from a description of a new idea. Each project should have an associated SDK, which includes both an english description of "the tech", as well as code, which matches the "spec", because they are both derived from one, very detailed specification.
What is 'Derived Code'?
Derived Code or Generated Code is code that is not written by hand (by humans) and is instead 'generated' or 'derived' from some other source. There are thousands of different 'transpilers', or tools which can be used to generate code - and a typical CODEiverse project will use a number of different types of transpiler.