The Art Of Development

The Art Of Development

Among developer community no one would love to write source code for which they cannot bet for its intent and quality. Still there would be instances demonstrating shorter lifespan, bugs, vulnerabilities, code smells and unreliable results whether discovered or not. 

There is no pride in writing any code which gets rejected by automated scans, reviewers, verification engineers and customers. There is no satisfaction when a customer or an organisation needs to payback the cost which gets multiplied over time. I am certain that nobody intends to earn such a debt or the skill set to code them. Many times it also remains unknown to the developer who authored the code due to the time it takes it to discover a bug. As a result, the opportunity for a developer to correct and learn from those errors gets delayed or missed completely. 

In my experience, it helps connect a developer with faulty code easily when a defect is discovered within a shorter time e.g. day or two or a week max. Rectifying it becomes easier as the code is still on top of developer’s mind. When a defect is discovered after long period of time, it is harder and takes longer to fix it. This also slows down the process of enabling a developer to learn from errors and write robust code.

There are many practices, techniques and tools around to help make things better; however, the need to incorporate them in daily life is mostly mandated or initiated by leaders, managers and architects to fix the damage and prevent it. It is important that developer understands the value in adopting them as it enables them to write robust code that helps them master the trade for betterment of their career and professional growth. It is a learning opportunity that teaches what is not a good or recommend practice. Give it a try and see the difference. Remember that it does not need to be initiated by someone else but you as it works in best interest of you.

Following is bare minimal in my experience that has helped me to a great extent and I hope it will help you too.

  1. Configure your IDE / build tool to report all warning as errors. Remember that warnings are potential errors. Start using static code analysis tools; it helps to identify errors and vulnerabilities in source code before anyone can see it. Use it for your advantage. 
  2. Always write unit and integration tests. It’s your best friend that protects you all the time by making sure that your code does what it is supposed to do and nothing else. Use code coverage to identify uncovered areas in your tests. Note 100% coverage does not mean it is bug free; the key is to master the technique. (see https://stackoverflow.com/questions/61400/what-makes-a-good-unit-test)
  3. Get your code reviewed by a peer, ensure it is tested thoroughly by verification engineers, pay attention to rework and aim to reduce it to zero. You will be thankful to yourself in longer run.
  4. Establish quality gates that alerts and prevents from any damage. Implement dashboards that provides accurate and instant feedback. Finally shorten the defect discovery timeline to a week or less. 

To view or add a comment, sign in

More articles by Atul P.

  • Inside Coverage

    If you're in IT you must have heard "coverage". It is a positive number representing "measured value" of "a thing".

  • A Wakeup call?

    Watched and Listened to Anupam Kher's speech at The Telegraph National Debate 2016; which has now become viral on…

    1 Comment
  • DUnit: I know you know me. Let's get to know each other better.

    The DUnit Integration with TeamCity is great. This post taking it further to get most out of TeamCity.

Others also viewed

Explore content categories