why be normal?
Welcome to Sign in | Help
in Search

Step 0: The One Thing to do before developing

Last post 10-31-2008, 11:59 by icelava. 0 replies.
Sort Posts: Previous Next
  •  10-31-2008, 11:59 4755

    Step 0: The One Thing to do before developing

    Immediately from this day forth, this imperial edict shall take effect

    Thou shalt asettan thy Version Control System aeror thy development beginnan

    In other words, no matter how small, trivial, short, simple, ephemeral, even alone, the development work assigned to you may seem, establish your repository before commencing on a single line of code. Nope, I am not asking for an elephant gun to shoot down a mosquito. Let me explain why, with a quick anecdote.

    During my National Service years, I was posted as a HQ staff officer. My big boss, the Head of the division, mandated that I held a notepad and pen whenever I meet up with her. It was not for purposes of sketching her wearing the Heart of the Ocean. We had serious business to work on, and her saw to it that I jotted down all her statements in ink. Her premise was a simple one - she deals with humans. Humans forget. Period. This crucial lesson in life still rings true more than ten years on. Very loudly. I sometimes wonder why this has not been made law yet.

    Anybody who has done programming know this truth first hand. A five minute break is all that it takes to make us forget what we - our own selves - have done. And yet, we continue this sinful habit of regularly overestimating our memory retention capabilities. We look at a project/job scope, and laugh out, "we will be done by the time the repository is setup!" You know something? Projects, even the smallest one fit for a 16-year-old intern, have a high tendency to outlast the original developers and architects. What was originally scheduled to span perhaps a month of "quick and dirty" POC work slowly stretches to include more concepts to demonstrate, newly-discovered problems to solve, more manpower to assist, more technical artifacts like design documents and reports, project source code, databases, setup guides. The list grows on.

    Before one realises it, a mountain of documents and source files has amassed. All sorts of backups - representing various stages of development - spanning arbitrarily across everybody's computers, devices, and drives. Who knows which is the latest copy? Which version has the capability of retrieving data from the actual mainframe database? Why is this feature still not done when it has been reported so? Was it developed in an isolated copy? The historical path of development is only as good as the original authors remember them to be. That is, provided they have not been rolled off to another project, quit the company, or gone on long vacation. And no, I have never experienced a handover process that taught me 100% of what I needed to carry on with the job. Plenty of easter eggs, and nasty surprises, to be found.

    Now this does not mean the usage of a VCS automatically confers perfect historical tracability and accountability. You can take a powerful assault rifle, but still need to operate and aim it properly before you can hit targets effectively. In fact a VCS alone still leaves alot of leeway for arbitrary structure that can be misunderstand and lost if not properly communicated. Especially if developers do not conceptually grasp branching and merging. But that is an expansive topic of its own that I do not wish to digress into. My point here is, one needs to habitually "setup base" - perceive VCS as the bare minimum of foundational piling and cementing before building the household of source code on top of it. No matter how arbitrary your hierarchy may be inside the repository, the key thing to recognise is:

    The repository will remember every single step you took along the way. Much more efficiently than you can ever do. The notepad of the contemporary developer is right before your eyes.

View as RSS news feed in XML
Powered by Community Server, by Telligent Systems