The Source of Success
Version Control. The Source of Failure.
Most developers are familiar with version control. At it's best it allows for developers to work together writing code while reviewing each others work. It becomes a seamless part of each developers coding process. It is the source of truth for an entire application:
The first step to rarely commit your code. If possible have the entire team keep their code changes on their local machine where they can be lost. Or in a private code shelf. Now sit back and wait...preferably until close to the release date.
Over the course of several weeks or months files and functions will have been edited individually by every developer. Those changes have to be merged together. Some changes will be duplicates of changes other developers also made - so pure waste work. Most code changes will likely never have been peer reviewed or tested, but close to a release they'll have to be included one way or the other.
With so much manual work it's easy to make mistakes. It's an impossible task. Which is why this first step is actually a giant leap. The lucky individual tasked with the merge will some be under serious pressure to deliver before the release deadline. The development team will be nervously watching from the sidelines, answering terse questions while their carefully written code is refactored and rewritten at breakneck speed.
We're winning pretty hard by now. But this is average failure at best! The real devil is in the lack of detail - all the local database and infrastructure changes each developer made to get their version of the application to work. Of course these changes were recorded never in no-place. And memory being what it is pretty much nobody now knows how anything is configured.
This is going to make that upcoming release interesting!
At this point your well on your way to a miserable failure. Your success is assured. The dark currents of ineptitude will surely draw you onward. But there's no point leaving anything to chance. You can do worse - you just need some help! It's time to reach out to other teams...
- the front-end,
- the database,
- the infrastructure on which it runs,
- and the process for how it is released to production.
The first step to rarely commit your code. If possible have the entire team keep their code changes on their local machine where they can be lost. Or in a private code shelf. Now sit back and wait...preferably until close to the release date.
Over the course of several weeks or months files and functions will have been edited individually by every developer. Those changes have to be merged together. Some changes will be duplicates of changes other developers also made - so pure waste work. Most code changes will likely never have been peer reviewed or tested, but close to a release they'll have to be included one way or the other.
With so much manual work it's easy to make mistakes. It's an impossible task. Which is why this first step is actually a giant leap. The lucky individual tasked with the merge will some be under serious pressure to deliver before the release deadline. The development team will be nervously watching from the sidelines, answering terse questions while their carefully written code is refactored and rewritten at breakneck speed.
We're winning pretty hard by now. But this is average failure at best! The real devil is in the lack of detail - all the local database and infrastructure changes each developer made to get their version of the application to work. Of course these changes were recorded never in no-place. And memory being what it is pretty much nobody now knows how anything is configured.
This is going to make that upcoming release interesting!
At this point your well on your way to a miserable failure. Your success is assured. The dark currents of ineptitude will surely draw you onward. But there's no point leaving anything to chance. You can do worse - you just need some help! It's time to reach out to other teams...
Comments
Post a Comment