Changelogic's Vision
- Changelogic
- Changelogic Vision
History is the enabler, not the barrier
IT development is an intellectual activity. Programmers hate writing documentation. Even if it is written, it soon becomes obsolete due to evolution of the application. People come and go. All these factors together cause the high cost of software maintenance.Researches show that up to 30% of software maintenance effort takes understanding previously written code.
And even though the maintenance activities are still very error-prone.
Nowadays everybody uses some kind of request tracker. They enter every request to the system and the requests go through the predefined process until they are finished. No serious IT organization can do without that.
So, what’s the problem? The problem is that when the requests are satisfied, they are forgotten. The only possibility that anyone deals with an old request is probably only when searching for duplicates.
But consider this: almost every requirement, enhancement and bug at some point need some decision. And the decision is made and written down to the history of the request. And forgotten when the request is finished.
Now if anybody makes some conflicting decision, it reflects in code. But when you don’t know why the code was written in the first place, you will override the previous decision thus leading to vicious circle of regression bugs. Sooner or later you will reach the point where the most of IT budget is invested into maintenance.
Our vision is to bring the history of the decisions to the desk of the people who write the code. At first, they should understand what the code is really about and only then change it. Our vision is to organize the database of requests and bind them with real code, in the way it serves as a knowledge base and documentation for further development.
Always operational, always consistent
During application development everybody focuses on getting the façade up. During stabilization time everybody focuses on implementing the corner cases. You know the 80/20 rule? Then maybe you have realized that the façade will take 20% and those corner cases will take 80%? Leading to unacceptable time and costs for software stabilization.Whatever the current programming language or application server is, to meet a business requirement, you have to change the code.
Changing a working application is always big risk, because it is so incredibly easy to change a working application into nonworking application comparing to the effort needed to change a working application into a working application with some new feature.
Our vision is to keep the applications always in some usable condition, always operational. Whenever you take the official version, it absolutely must be consistent because other people base their work on it. And if the application is not working, they either cannot work or base their further efforts on wrong assumptions thus even deepening the problems.
The mantra of methodology gurus has always been “the later you find an error, the costlier it will be to fix it”, so what’s new here?
We provide infrastructure for locking out the errors in the earliest stage possible with the mechanisms that are to be enhanced as your project is maturing. We also provide a possibility to postpone the whole change if it cannot be stabilized and will probably cause either release delay or risk of erroneous production.
Release as an opportunity
Ever released software product? If there is a release, there is a deadline. Oops, there was deadline; actually there have been already many of them. None was met. Stress is unbearable. Mistakes slip in, causing further delays and failed releases again leading to budget overflows.Releasing software is probably the biggest risk in IT. If you do release your application, you take the risk that it has errors, maybe it even causes total outage and you have to restore previous situation. If you don’t release it, you risk with missed business opportunities, unsatisfied clients, revenue that is never created.
Our vision consists of detailed release process where no version can reach production without passing test environment, acceptance tests and change verification. The rules for acceptance are dynamic; configurable by every project team itself to meet their quality bar.
Our goal is to cut the risks of release through systematic acceptance tests and impact analysis to a reasonable level thus turning the release into an opportunity.
Continuous response
The flow of business needs is continuous. IT operates in release cycles. Feature freezes and stabilization times only widen the gap.By now the showstoppers are out, but every application still has errors.
Every IT department with at least some self-respect has established procedures so they can support the current production version if there are major problems.
But every application also has some small shortages that aren’t even costly to implement but your IT department refuses to do that, because they are not bugs and should be delayed until next release. And the reason behind that is the high risk of the release and cost of increased parallelism.
Our vision concentrates on lowering the costs of increased parallelism through procedures for systematic code propagation.
Cheap parallelism enables shortening the release cycles to the level that response time to business needs is minimal.
Durable values
Are your developers talking about new framework? Your designers talking about new architecture? Your R&D about new platform?We highly encourage these efforts.
But we see these as short-term investments. In three years the framework will be obsolete, in five years the architecture has to be replaced and in ten years there will be new programming language.
Although more people will have to learn the code you write today, keep it operational, release it and do that even faster.
In long perspective.
Improved learning, faster change, controlled costs
Maintaining your ability to change at reasonable costs during maturing and scaling up through putting the history work for you, not against.
Shorter stabilization, shorter time to market
Making your IT budget meet the goals through keeping the applications always operational and complete.
Lower release risk, no unexpected costs
Turning the release into an opportunity through increased transparency.
Shorter release cycles, raised business responsiveness
Enabling you to respond to business needs through increased cheap parallelism.