The curse of software programming

This is what I think is the worst curse in software programming.

When you feel that you are close to solving a programming issue, or cruising along towards the solution, you are unable to or find it difficult to pause work and call it a day.

I miss the days when I could just continue working until I solve the issues, or until I’m too tired to think. Married, or with kids will know that obligations to the family calls for a “clock-out” from work for a balanced life.

I don’t advocate overtime or over-worked. But I do miss the satisfactions and triumphs over finishing a piece of work on a single track.

That’s why this is a curse. Torn between the urge to continue over a piece of work and the need to balance your life.

Code is the authority

Be damned with all the documentation that is to be done in a software development life cycle. They are time consuming, resource intensive and in the end, probably not updated against the software that is running your application.

Let’s face it. The people who need someone to write software do not know what it takes to manufacture a quality software. They are the ones sold with the message that it is cheap, fast and cross-platform. They cannot accept the facts that software application requires teams of business analysts, usability designers, graphics designers, programmers, technical writers, testers, systems engineers, and a project manager to control them all. They are mostly unable to pay for the army of engineers, or they cannot afford a year of development. In the field of high competition, software companies are forced to take on projects that are cheap and under tight schedule. In the end, software companies end up killing each other. Or end up with poor quality software with patchy documentation.

In the end, the only thing that keeps your application running is the code. In any extreme case, only the code will keep it running.

If you are the only person left, you may only have enough time to implement the requirements into the code. If you realise that the requirements document are not inline with the coding, then the code is the requirements.  Otherwise how was it implemented and kept running for that long? If you realise that the code versioning system is in a mess, then the production code is the version to maintain.

Ultimately, the code is the authority.

Hence, be damned with all the separate documents that are to be maintained separately and kept in synchrony.  We should just document the code as we write the code and the behavior-driven test codes.  Format the comments in a structure such that we could run a parser through it and generate the officious documents demanded by the business users.