Why Care About Code Quality?
We wanna be agile, what is agile means? Agile means we gonna get the feedback from customer/PM and based on that feedback, we go back and respond to those changes. So that in the next PM meeting we can say that here are the changes, you wanted us to do last time, so review it and then we can move forward.
AS sitting there with the customers and asking them what kind of change you need to make, you begin to realize that the particular change they want to make, if you were going to make, you will have to touch that peace of code, u remember the one that I am talking about, right? That peace of the code that u touch last time and u could not go home that weekend. U gonna quietly tell the customer, u know that’s not a good chance after all, because u don’t wanna spend yet another weekend at work.
So in another word, one of the main reasons to care about code quality is as simple as that u cannot be agile if your code sucks, so it's important for us to care about code quality. It doesn’t mean that just because you have the quality of code, u are agile, I am not saying that, right? I am saying that it will become really hard to be agile if your code sucks.
Abelson & Sussman talk about his in their book, in the SICP book (Structure and Interpretation of Computer Programs),” programs must be written for people to read, and only incidentally for machines to execute”, so we all write code and we focus so much on writing code, so more than writing code, me must make sure that our code is readable, so now, why is this important for us to read someone’s code in our team? And the reason is, we write code just once but we have to maintain it continuously, and if we not gonna maintain the code then what is the point in writing that. And any code u write has to be maintained if somebody tells u that they
Code Reviews
Pair programming
Never get code reviewed by the non-programming person (manager or architect)
If managers are not doing programming then they can give more time to dev-testing and wiki documentation for functionality.
Beware of ticket only managers
Use UML Diagram in Architecture Design.
Appreciate person in CR and Arc meeting if he has done a good job.
1 to 1 meeting.
Don’t Interrogate
Don’t interview
Add many good points also
Ask for his problems (even if it's personal, it will help in building a good relationship)
BDD & TDD
Never show every task very urgent or critical (it will reduce the criticality of original critical tickets)
Never show your junior’s work on your name
Assign someone’s work to others just because the main person will come late… this will double to analysis time and will interrupt the other also
Variable names must be greater than two characters
Never apply lots of reporting tools and other monitoring on developers; it will end up in reducing performance instead.
We all write code and we focus so much on writing code but more the writing code we must make sure that we are writing readable codes.
Now, why is that important to write the readable codes? And the reason is, we write code only once but we have to maintain it continuously.
If somebody tells you that they wrote the code once and they never changed the design or code. What they are telling is, the project/feature is canceled.
How to write readable code?
Just write the code and give it to somebody to read it. And this is really important because even the original programmer has left the company, your code will still remain readable. It will reduce the maintenance time as well as, there will be no need to remember the code, as code is readable, it can be changed easily even after years. It is a kind of code review also.
You can fix the issue in non-readable code immediately after the code, maybe even after 3-4 days.. but later even after 3 weeks. If you try to fix the issue then you will have to first understand the whole scenario again. And what will happen, if you get the request to change the code after the year.
So we must write the code in such a readable form, so that it can be fixed by anyone in the team.
How to detect defects and how to reduce the defect (not talking about fixing the defect): adding features during development is 100 times cheaper than doing changes in the maintenance.
40-50% of maintenance code is an avoidable rework
90% of the downtime of the projects comes for 10% code, bugs.
Never reintroduce the defects. Resolve the defect in a way that it should never come back with bugs. So you can save the re-fixing time
Code reviews and unit tests both are very important but code reviews have much more impact on the quality of product compare to unit tests.
As Code reviews make sure that your code is readable. As another mind reads your code and if that finds any issue in it, it will reject the code review.
Its extremely important that who is doing code review, now in your organization if only programmers write code and so-called architect or managers review the code. It is a very dangerous situation.
The code reviewer should be a fellow programmer who is writing code with you, in the same team.
Such as non-coding architect and dev. managers are very dangerous for application if they are allowed to do code reviews
While doing a review, the reviewer must make sure the code has proper test coverage, it has written all required unit tests.
Disciplined practice can reduce the introduction of bugs and increase the quality of code.
We are not saying that discipline reduces defects, we are saying discipline reduces defect introduction.
We can see most of the company saying that we don’t have time to do it, we need to do it now, ASAP but they always have time to redo it. Programmers tell that we need the time or it going to take time and managers force that no we don’t have time, we need to fix it by today only, within a few hours. Then developers do the mesh and finish the work at the end of the day. But then what happens, that fast & furious code will be converted into multiple bugs and will take 20 times more time for bug fixing than it would have taken in initial development.
People are making the same mistake again and again and expecting different results. To get a different result you will have to do the change, and meetings are not called change. An introduction of the new meeting will consume more time and things will go more bed instead of going positive.
Technical Debt: people take shortcuts during critical immediate issues and leave a few things in between knowingly. We must clear such technical debts ASAP.
Technical debt is not a wrong thing but resolving those technical debts is the issue. You must schedule the time to fix the technical debts. It must be part of your work and schedule. A dedicated time for fixing technical debts will increase the quality of code as well as reduce the upcoming defects and defect introductions.
Technical debts are just like your credit card, you do the shopping and when it’s time to pay, you just pay the minimum amount and continue doing shopping. After doing the same for continually for a few months you will reach to a place where u won’t be able to pay it and you will become bank corrupt. Same this is with technical debt, people keep doing it and once it goes beyond their limit, they silently switch the track/job and leave that tech debt for other people.
Freezing of the requirements: many people use this term that we have frozen the requirement but the real term is “We
We wanna be agile, what is agile means? Agile means we gonna get the feedback from customer/PM and based on that feedback, we go back and respond to those changes. So that in the next PM meeting we can say that here are the changes, you wanted us to do last time, so review it and then we can move forward.
AS sitting there with the customers and asking them what kind of change you need to make, you begin to realize that the particular change they want to make, if you were going to make, you will have to touch that peace of code, u remember the one that I am talking about, right? That peace of the code that u touch last time and u could not go home that weekend. U gonna quietly tell the customer, u know that’s not a good chance after all, because u don’t wanna spend yet another weekend at work.
So in another word, one of the main reasons to care about code quality is as simple as that u cannot be agile if your code sucks, so it's important for us to care about code quality. It doesn’t mean that just because you have the quality of code, u are agile, I am not saying that, right? I am saying that it will become really hard to be agile if your code sucks.
Abelson & Sussman talk about his in their book, in the SICP book (Structure and Interpretation of Computer Programs),” programs must be written for people to read, and only incidentally for machines to execute”, so we all write code and we focus so much on writing code, so more than writing code, me must make sure that our code is readable, so now, why is this important for us to read someone’s code in our team? And the reason is, we write code just once but we have to maintain it continuously, and if we not gonna maintain the code then what is the point in writing that. And any code u write has to be maintained if somebody tells u that they
Code Reviews
Pair programming
Never get code reviewed by the non-programming person (manager or architect)
If managers are not doing programming then they can give more time to dev-testing and wiki documentation for functionality.
Beware of ticket only managers
Use UML Diagram in Architecture Design.
Appreciate person in CR and Arc meeting if he has done a good job.
1 to 1 meeting.
Don’t Interrogate
Don’t interview
Add many good points also
Ask for his problems (even if it's personal, it will help in building a good relationship)
BDD & TDD
Never show every task very urgent or critical (it will reduce the criticality of original critical tickets)
Never show your junior’s work on your name
Assign someone’s work to others just because the main person will come late… this will double to analysis time and will interrupt the other also
Variable names must be greater than two characters
Never apply lots of reporting tools and other monitoring on developers; it will end up in reducing performance instead.
We all write code and we focus so much on writing code but more the writing code we must make sure that we are writing readable codes.
Now, why is that important to write the readable codes? And the reason is, we write code only once but we have to maintain it continuously.
If somebody tells you that they wrote the code once and they never changed the design or code. What they are telling is, the project/feature is canceled.
How to write readable code?
Just write the code and give it to somebody to read it. And this is really important because even the original programmer has left the company, your code will still remain readable. It will reduce the maintenance time as well as, there will be no need to remember the code, as code is readable, it can be changed easily even after years. It is a kind of code review also.
You can fix the issue in non-readable code immediately after the code, maybe even after 3-4 days.. but later even after 3 weeks. If you try to fix the issue then you will have to first understand the whole scenario again. And what will happen, if you get the request to change the code after the year.
So we must write the code in such a readable form, so that it can be fixed by anyone in the team.
How to detect defects and how to reduce the defect (not talking about fixing the defect): adding features during development is 100 times cheaper than doing changes in the maintenance.
40-50% of maintenance code is an avoidable rework
90% of the downtime of the projects comes for 10% code, bugs.
Never reintroduce the defects. Resolve the defect in a way that it should never come back with bugs. So you can save the re-fixing time
Code reviews and unit tests both are very important but code reviews have much more impact on the quality of product compare to unit tests.
As Code reviews make sure that your code is readable. As another mind reads your code and if that finds any issue in it, it will reject the code review.
Its extremely important that who is doing code review, now in your organization if only programmers write code and so-called architect or managers review the code. It is a very dangerous situation.
The code reviewer should be a fellow programmer who is writing code with you, in the same team.
Such as non-coding architect and dev. managers are very dangerous for application if they are allowed to do code reviews
While doing a review, the reviewer must make sure the code has proper test coverage, it has written all required unit tests.
Disciplined practice can reduce the introduction of bugs and increase the quality of code.
We are not saying that discipline reduces defects, we are saying discipline reduces defect introduction.
We can see most of the company saying that we don’t have time to do it, we need to do it now, ASAP but they always have time to redo it. Programmers tell that we need the time or it going to take time and managers force that no we don’t have time, we need to fix it by today only, within a few hours. Then developers do the mesh and finish the work at the end of the day. But then what happens, that fast & furious code will be converted into multiple bugs and will take 20 times more time for bug fixing than it would have taken in initial development.
People are making the same mistake again and again and expecting different results. To get a different result you will have to do the change, and meetings are not called change. An introduction of the new meeting will consume more time and things will go more bed instead of going positive.
Technical Debt: people take shortcuts during critical immediate issues and leave a few things in between knowingly. We must clear such technical debts ASAP.
Technical debt is not a wrong thing but resolving those technical debts is the issue. You must schedule the time to fix the technical debts. It must be part of your work and schedule. A dedicated time for fixing technical debts will increase the quality of code as well as reduce the upcoming defects and defect introductions.
Technical debts are just like your credit card, you do the shopping and when it’s time to pay, you just pay the minimum amount and continue doing shopping. After doing the same for continually for a few months you will reach to a place where u won’t be able to pay it and you will become bank corrupt. Same this is with technical debt, people keep doing it and once it goes beyond their limit, they silently switch the track/job and leave that tech debt for other people.
Freezing of the requirements: many people use this term that we have frozen the requirement but the real term is “We
