All right, let's get started. Welcome to the session on caring about code quality. My name is Venkat Subramaniam. We're going to talk about something that we as programmers are very passionate about. If you have attended some of my previous talks, I have to apologize. This one has no code at all.

The other ones had no slide at all, so sorry for that. But I hope we can still have a good conversation and talk about quite a few things here in terms of code quality. Best time to ask a question or make a comment is when you have it. Please do ask questions, make comments. I definitely love to hear from you, what you have in mind.

So don't hesitate. It's not an interruption at all. If you want to just step in and talk, raise your hand. But if I don't respond to you, that usually means that I'm not paying attention to where you are. But just start speaking something or make a noise. And as soon as you draw my attention, I'll yield to you and respond to your question or comment. So let's get started. First question, of course, always.

I'm a why kind of a guy. I always ask why. Why should I do it? So my first question, of course, in this context is, why do I care about code quality? Why should I care about quality of code when my intent is to write code and get code working? And the reason simply is this.

You cannot, we cannot be agile if our code sucks. Now imagine for a minute you are on a project and your company says, we are agile. And the customers are like, really, what does that mean? And your company says, that means you guys tell us what you like and we will respond to your change.

And the customers are like, that's kind of nice. Can you change these things? And your company says, sure, we are agile. Why not? And you're sitting in that meeting and as the guys are talking about it, you realize to make that change that they are talking about, you got to touch that code, you know the one I'm talking about.

And the code that you touched last time and you could not go home for the weekend. And now you're going to convince them this is not a good change to have, right? So in other words, if you cannot really have a good quality of code, it's extremely hard to be agile where agile is to respond to change based on feedback we receive.

And that's one of the reasons why we should care about code quality. So what is quality of code? Why should we really care about it in that regard? And to me, code quality is really boiling down to this wonderful quote. Programs must be written for people to read and only incidentally for machines to execute.

We spend so much effort writing code, we don't often think about reading code, but programs are for human beings to be able to understand. And what do we normally do when we speak to each other? We communicate. And there are different ways to communicate.

One way is verbally we can communicate with each other, but your code is a way that you communicate with your fellow developers in the company. And so it's important for them to be able to understand the code and to be able to maintain the code. That becomes extremely important and useful for us to think about. So from the point of view of that,

it's important for programs to be written by people so it can be read by people more than executed by the compiler or the computer itself. That's very important. Now having said that, one of the reasons why we have to make sure the code is of good quality is, unfortunately, software is never written once.

If somebody tells you they designed the software and wrote it, and they never changed it after that, they are telling you the project got canceled, right? Because any useful software has to evolve, has to change. And the amount of change the software has to go through

depends on the number of features we are trying to support. And more that is, it's got to change. And as a result, we have to support this change. That's very important. And one of the problems with software is the cost of fixing a defect increases the more time goes between writing the code

and finding the problem. If you write code, and within seconds you say, darn it, that's stupid, I shouldn't do it, duh, and then you go back and fix it, that only costs a little bit of money. But if you find it next day and fix it, that costs a little bit more money. What if you find the problem

in two months after you wrote the code? If you're like me, after two weeks, I can't even recognize my own code. I look at this and say, did I write this? So it takes more time for you to gain the context on the code and go back to fix it, and it becomes more expensive. And the worst thing is you got to look at a code written a few years ago by somebody else

who no longer works in the company. That's the worst kind of job to be in. And you're really looking at this code and trying to understand it becomes very expensive. So how can we reduce the cost of developing software and handling defects? And Boehm talks about this in one of the good papers, and they say that finding and fixing problems

in production code is 100 times more expensive than finding and fixing problems during development. So we want to be able to get to this really quickly during development and not really wait until production time for this to find. And it says 40 to 50% of effort on projects is avoidable rework.

So we do so much that can be avoided and we don't have to waste our money and time doing this. And they talk about 80% of avoidable rework comes from 20% of defects, and they talk about the 80% of defects come from 20% of modules. So this is really encouraging news because we can contain the area and really solve the problem.

And it says 90% of downtime comes from mostly 10% of defects which are really critical on projects. They go on to say one of the best ways to really improve software and reduce cost is to have peer reviews because peer reviews catch 60% of defects.

And I cannot overemphasize this. This has been around for a long time, but one of the practices that is not as much used in our industry because most of us don't like to do this for various reasons. But if there is a way we can have code reviews and peer reviews on projects, it can reduce the cost.

I'll come back and talk about this definitely more because this is such an important topic to spend time on. But it's not just a code review, and I'm very adamant about this. The worst code review you can have is where you have architects and senior developers reviewing code that other people write.

There's a name for this. It's called the priesthood-based code review where you bring in people with beard and they think they are great programmers and they sit there and say how your code sucks. This is absolutely useless. So what you really want is a perspective-based peer review. The people reviewing the code should be the people writing the code itself,

not some architect somewhere who doesn't write code anymore but is really important for them to review the code somehow and tell you whether your code sucks or can be better. So it's important for a peer-based review. Like I said, I'll come back and talk about this more later on. But then they go on to say that disciplined personal practices can reduce defect introduction rate by 75%.

Now this sentence is loaded with several important things here. The first important here is discipline. This is one of the most difficult things for us in developing software is to really have discipline. It's easy for us to acquire a lot of practices.

One of the reasons I cringe the word agile development today is if you look at most companies and look at what are they spending their time and money on, they want agile development, they want training related to agile development, you go to them and they say, can we have scrum certification please? Can we have stand-up meeting please? Why? Because standing up is so easy,

especially if you can lean on a chair, right? I don't want stand-up meetings on my team. Who cares about stand-up meetings? Tell me what you're gonna do to really effect change in building software. And guess what? That takes effort. That takes discipline. So most companies do what I call as agile by convenience.

So they want to pick and choose real practices that are so darn simple and easy to use so they can just apply those. And the real hard stuff, ah, let's not worry about it. That's not for us, right? So I don't want agile by convenience. I want agile by dedication and discipline. Let's do the real hard stuff and make the software better

and serve the needs of the customers. So discipline is extremely important in this regard. And personal discipline on projects is very important. And that means you don't say, I would do all this if only my company allowed me to do. That is utter nonsense. If we believe in doing things that's at a personal level,

then we propagate that to the team and make everybody else follow that. So personal discipline is extremely important. And if we can use some of the personal discipline practices, it doesn't eliminate defect. It eliminates the introduction of defect in software, which is a lot better than removing defects because you don't want to put in and then remove it.

So that is one thing to think about. The other thing they talk about is it costs 50% more per source instruction to develop high dependability software products. In other words, if you want to build quality software, it is gonna cost you money. It is not free. It is not gonna be something you can just kind of do along the way.

It is gonna take money and effort. Now, to really expand on this, one of the companies, which is my client, they called me up a few years ago, back in 2007 timeframe, and they said, we have problems with quality. Could you please come and do some courses related to quality and improve quality on our product?

I went and offered this course in one of their locations. And two weeks later, I was gonna go to their, another location and teach the same course and then go and teach the same course in several of their locations. So when I finished the first course at one of their locations, one of the developers came to me and said, hey Venkat, we have known you for several years.

You come here and give us all these nice talks. We get really excited about what we hear. We talk about the course. We talk about what you said for about two weeks. And then afterwards, it's business as usual. So tell us why this time it's different. And I swiftly answered him saying, that's your problem, not mine.

I just came here to teach. And I kinda walked away. Two weeks later, I went to their another location. The guy who hired me was there. He said, oh, by the way, I heard that there was a question posed to you. I said, here was the question they asked me. And he said, what was your answer? I said, it's your problem, not mine. And he said, well, okay,

do you have the same answer now or do you have a different answer? I said, I have a different answer now because that was a spontaneous answer, but I've had two weeks to think about it. He said, what is your answer? And I said, he is absolutely correct. My time and effort here is completely wasted and your money is completely wasted if you guys gonna just listen and walk away.

He said, okay, what should I do? I said, the first thing you do is for every software project in your company where quality is important, find one person in the team, not a manager, but a technical person and make that person the champion on the project for quality.

That champion on the team is responsible to first define how he or she is gonna make the team improve quality in three months, in six months, in nine months and in a year. And this becomes the responsibility of this quality champion in your team to do this. This was in 2007, by the way,

and it's been about five years and that's exactly what they have done. He's identified quality champions on teams and they have done very dedicated effort in building quality software in measurable levels. So in other words, if you're serious about quality,

don't talk about it, do it. Have somebody whose responsibility is to improve quality and they have to really work on it and show the results in a three month period, six months period, nine months period and a year and say, here's how we have improved it and here's the plan for the next three months moving forward.

So it is really something we have to really work towards to improving the quality of software. But still, the evidence is overwhelmingly clear. But one thing I noticed, I'm sure you share the feeling with me, is that companies never have time to do it. But they always have time to redo it.

This is kind of funny, isn't it? Because you go to the company and say, hey, we need to do this the right way, can I do it? No, we don't have time for it. Then we create a big mess as programmers and the company comes running behind us and saying, could you please fix it now? So they never have the money and the time to do it, but they always somehow have the time and money to redo it

and that is kind of a reactive behavior that we have imbibed in our culture as organizations developing software, we need to break out of that cycle very clearly. That's very important. So one of the things to think about is to pay the technical debt. So if you're on an Agile project and if you're scheduling your project iteration on a sprint,

I will first ask you, how much time are you dedicating in every sprint or every iteration to really address the technical debt? Do you know what your technical debt is? That is something to think about. So if you don't know what your technical debt is,

or even if you do know what your technical debt is, but if you're not giving enough time to really solve the technical debt, this is eventually gonna blow up because the way the technical debt works is very similar to financial debt. So I have a credit card, I go around, charge this credit card along the way

and as I keep charging the credit card, at the end of the month, the credit card company sends me a bill. I'm sure nobody here likes to receive that bill, right? And the bill arrives in the mail and you look at that and say, it says you owe this money. And I tell myself, you know what, I'm getting the salary, but I've got so many useful things to buy.

Why would I wanna waste that money paying for the stupid credit card? So I'm gonna send a minimum balance and continue to spend. And a year goes by and I've reached my credit limit. What does the bank do? Remember the bank cares about me, right? So the bank sends me a letter saying, dear valued customer, you exceeded the credit limit,

so we have extended it. So they increase it by tenfold because the bank cares about me so much, they never want me to get in trouble, they want me to get into real trouble. That's part of the financial world, right, where things are. So I keep spending more and spending more and spending more and one day I realize the money I owe to the credit card company

is several orders more than my salary per year. The only options I can think of is to grow a beer, change my name and move to a foreign country. I have no such intention during this trip, just to be clear, right? And the point really is, you have to have the discipline to manage your budget and pay things along the way.

And really a technical debt is exactly the same. And if we don't pay technical debt, eventually the project will have to declare bankruptcy. Now, I'll tell you about something that I learned the hard way. I was in college, and I'm sure all of you going through college did exactly the same thing, right? Please do say yes, otherwise you'll feel bad about it.

So when I was in the college, I used to rent apartments. And in my apartment, I would never clean my apartment. We would completely trash the place. And about six months after that, it would become unlivable. But it was very easy. We'll just move to another apartment.

And I thought this was life, right? I mean, when you're in college, you know kind of what do you know, right? And this was like awesome. You could trash the place and you could move, right? And then I went on to take up a first job. And when I went to take the first job is when I realized it doesn't work like the college days. Because there's a code base that you inherit. And there's been somebody else who have moved

and you are the cleaning crew at this point. What a shock I had the first time. And when you leave a project and go, there's a code you inherit and you got to maintain. And I started learning some discipline along the way. Like things like mom and dad were trying so hard to teach, right? You have to really have a discipline in what you do. Same thing with technical debt. So we have to take the time

to pay the technical debt along the way. So measure your technical debt and plan for removing them along the way. And don't lead it to a bankruptcy situation. But what is really quality though? Quality is a measure of how software is designed and implemented. But more so from the point of view

of how effectively it can change. And so a quality is extremely subjective. And so you cannot just say, here is an absolute definition of quality. There's no litmus test. You cannot take a stick and insert into the code, pull it out and say, well that's red in color so that sucks. You can't really have such measure of quality.

It's very subjective. We got to kind of evaluate it. But measuring quality is very hard. How do you really find metrics? There are some very bad metrics the world has created. One of them is the lines of code. A very bad idea, right? Because does it mean it's better if you have more lines of code? Or does it mean it's better if you have fewer lines of code? Well, neither one of them is true, right?

Because it could be bloated code that's totally unnecessary on one hand. Or a very terse and cryptic code which is hard to maintain on the other hand. So we cannot simply use the lines of code as a metric. Now it's very highly subjective, all right. But we got to have a way to measure something. And it's very qualitative rather than being quantitative.

So the first question I would ask is, is the code readable? Now here comes the problem. Have you ever met somebody who says my code is not readable? Maybe a few people do. But one of the biggest problems I see is when programmers think they create readable code, nothing is more dangerous than that.

So I have a challenge for you. If you want to create readable code, I think there's only one way to do that. The way to create readable code is to read it. There is absolutely no other way to do it. So if somebody writes a piece of code, they have no business claiming it's readable unless somebody actually has read it. And when they start reading it, they throw a fitch.

They complain about it. And when things calm down, maybe you have a code that's readable. So you can never claim a code is readable unless somebody else who has, other than the person who has written this, has actually read it. And it's got to be a couple of people to read it. So the best way to create readable code is to read it.

And what that means is never leave programmers in isolation. The worst kind of programmers are the programmers who write code and think they write excellent code. Those are the most dangerous people. Because what they do is they build a fort around them and say, I'm cool guy, I write excellent code. Hey, when was the last time anybody looked at your code?

Well, the compiler did, right? So that's not enough. As any human being, read your code and survive the process, right? And if you write the code and give it to other people, and to a great extent, I would say, good programmers are shameless. They would give the code and say, tell me how my code sucks. Now, let me say something very quickly.

I'll admit to you, I can never write good quality code. I've given up on that. I could never do it. I tried really hard to write good code, and I could never do it. But then I realized something, that I'm extremely good in finding fault with other people's code. And you come to me and say,

Venkat, write good code. I'm like, I can't do it. But you show me your code, I'll tell you a thousand ways your code sucks. So I realized I could use this to my advantage, rather than pretending that I can write good code, I write crappy code really quickly. I give it to him to code review. While I take your code and review, at the end of the day,

we all have a better quality of code. How about that? So by having a quick code review, we can actually improve the code, rather than trying to aspire to this kind of unreachable goal, pretending to write a great quality code. Because again, that's very subjective as it turns out, so why try so hard to do that? Is the code really verbose? On the other hand, too cryptic.

Are the variable names and method names named appropriately? That is something we have to think about. Is it a simple code that works? That's really hard to answer without putting a context together. Does the code have tests in it? What is the coverage of the test? These are some of the questions we could ask.

So there are some ways we can improve the quality of code along the way. So I'm gonna talk about two ways to improve code. One, you as an individual, and then you along with your team as a team collectively, what can you do? There are certain practices you can do for yourself, and there are certain practices that you would need the team to do, and we'll talk about both.

The first thing I would recommend is start early, because it's impossible to really improve the quality of code all of a sudden towards the end of the project, and say somehow we'll do a iteration where it'll improve quality. That's a fallacy, right? That doesn't work that way. So you gotta start really early. Don't compromise on quality along the way.

Have something that you maintain along the way, and if you have to really look at something, bring the team together and talk about it. Hey, can we improve this? We don't wanna just take a shortcut. Schedule time to lower your technical debt. Like I said earlier, in your schedule, in your iteration, in your sprint, you want to schedule a certain amount of time

that you want to do the cleaning of the technical debt. Make it work, and make it better. I'm a huge fan of this mantra. I'm not about getting perfection in the first run. Make it work first, then immediately make it better. That's where the red-green refactor comes in also in test-driven development. But this requires monitoring, but more important,

it requires a change in behavior. We cannot improve what we do without changing how we do things. If we don't wanna do anything different, Einstein said the definition of insanity is to do the same thing over and over,

and somehow expect a better result the next time. So if you want a different outcome, you have to change the way you do things and re-evaluate it. So it requires a change in behavior. And be willing to help, and be willing to be helped. And I believe in collaborative effort a great deal.

I want to be helped by other people in my team. I have to be a bit shameless about it. It's okay to say, hey, how can I improve? The worst thing that can happen is that I would be a better person than I was yesterday. And to be able to help also is to go to somebody and say, how could I help you with this, right? Without really hurting their feelings or emotions,

we can certainly do that. So devise lightweight, non-bureaucratic measures to do this. So I'm gonna talk a little bit about individual efforts. What can you do as a person? I don't believe in saying, I would do all this if only my company were to do this, right? I don't think that's reasonable. We got to do certain things ourselves,

and then expect the team to do the rest of the things. First, what can you do? First is care about the design that you create. Because your design lives in your code, maintainability of that is influenced. Are you coming up with good variable names for your classes, for your methods, for your fields?

Are you coming up with good names for these things? And honestly, I don't think I can come up with good names myself. I tried really hard. I would think deeply, and I would create a variable name. And the minute I give the code for code review, my fellow programmer says, hmm, why would you name it like that? That's like, what do you want it to be named?

And then you realize the context of where they are coming from, and then you converge on a better name. So it's okay to evolve the name, but do that quickly so that you have a better name. By the way, long names doesn't mean it's better. Sometimes long names are as evil as short names. But it's important to have meaningful names.

And you may say, wait a minute, isn't that kind of obvious? Well, yes it is, but how many times do we do that? How many times do we work on projects where there are single letter variables? We all know we cannot create single letter variables, but we all see single letter variables. I was teaching a course in Virginia,

and one of the guys came to me and said, hey, you're talking about coding standards. How dare you do that? We are a huge software company. We write software billions of dollars worth, and you think you have to come and talk to us about single letter variables? I kind of defended my position. I said, well sure, if you guys do that already, that's great. I'm very happy for you.

In case you're not, it's a good message to have. He said, well I was just pulling your leg. I can't tell you how many variables we have that are single letter. Our code just sucks everywhere you look at it. So I'm really glad you mentioned it. About four months later, I went back to the company to teach another course. The same guy comes to me and says, oh Venkat, remember I spoke to you last time?

Yeah, I do remember that. Well, I want you to know that you made a difference. I was so proud of it. I said, really? He said, yes. You talked about not using single letters. Thank you for that. Now we use only two letters. It's extremely difficult to kill habits, bad habits. So it's important to really work actively to create good variable names. Short methods and short classes.

Single responsibility principle at the class level. Single responsibility principle at the method level. We need to think about those things. But one of the best ways to create good code is to read good code. Honestly, most programmers don't even know how a good code looks.

Because all that they have done is seen bad code over and over and over. So if you find a good code, don't keep quiet. Immediately call the team and say, isn't that beautiful? Appreciate it. Say how beautiful this code is. And explain why you see the beauty in this code.

That is well worth the steps to take. And others can learn from that and say, this is the reason why this code is nice. And we can learn from replicating some of these things as good quality of code. So learn from reading good code. And keep it simple. How do you really make things simple? That is a challenge, right? But I may make something simple and then make it simpler.

But a simplicity really is a way to learn that is by kind of looking at our gut feelings. How do you feel about this code? I know this is not very scientific approach. But listen to yourself. How do you feel about it? And with experience, that kind of comes along the way as well. And learn from writing tests with high coverage.

And run all the tests before you check in. That's a rule we maintain in our teams is we will never check in code unless all the tests that we have pass. And that kind of is a way to do quality. But also to check in frequently. Sometimes programmers keep the code around for weeks.

And this is kind of scary. And you want to check in code very frequently. Now what's good about checking code very frequently? Others can start to use it. Others can start to look at it. It can improve right away. And if you, by the way, the first thing I would recommend doing, never use a version control system

where you can lock files. That is so 20th century, right? We should never do that. So if your source control allows you to lock a file and gain ownership of it, fire the source control system. You want a system which never allows you to lock. Then what happens? You've got to check in very frequently. What happens if you don't check in frequently?

You wait for a few days. You go to check in your code. And you realize that there have been so many check-ins. And you've got to worry about merging this file. So rule number one of coding. You should never get merge hell. You should only give it. So you absolutely have to deal with it.

So never get merge hell. Always give it. So frequent reviews really help quite a bit in that regard and promote a little bit of agility as well. Learn your language. And oftentimes, programmers begin to use a language. But they haven't really gained the strength of the programming language. And when you ask them a deep question,

they kind of give you all kinds of weird answers. That doesn't cut it. You've got to really know the language you are programming because that's our profession, right? And so as a result, we have to take the time. So read the books on the language. Play with it. Blog. Read blogs about it. Have a time with other fellow developers where you question them.

If something is not clear, ask them, how would this work? Why does this work? And that's a good question to ask. And if you're switching languages or working with multiple languages, you've got to know the differences between them as well. And it's important to avoid the cargo cult where you just do things because that's the way it was done previously. We somehow sometimes have to question and change

the way we do things. And we have to really court feedback and criticism from people. That is very important. In terms of keeping things simple, really ask, is this really necessary? Can I do something minimal to really solve the problem I know as of now? And sometimes programmers do this. They build a Rube Goldberg machine,

which is extremely complex. And you look at this and you're scared about this code. And I remember a day when I was looking at a piece of code. It was 250 lines of code to receive data and process and create an XML only for that to be sent to another function, which was parsing it again to insert it back into the database.

I'm sitting there asking, why am I doing this? And the programmer said, what if you ever want this to be extensible? Well, but what do we know about extensibility today? Nothing. Then why are we wasting all this time? And if we're doing stuff we don't need to do, let's only focus on what we know right now and maintain the code for that.

So there is a beautiful quote by Hor here. So it says, there are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

This reminds me of an experience. I was at a client site. I was reading through a piece of code, which was extremely hard to understand. I'm wading through the code, long methods, complicated logic, single letter variables. I'm scratching my head. And as I was trying to understand this code, eventually I discovered they had a huge concurrency

issue in the code. This code should not be working correctly, by the way. And when I pointed this out, one of the programmers got very angry at me. And the programmer said, hey Venkat, this code has been in production for three years. What makes you think you can come in and scare us this code is not correct today? How do you respond to that?

Well, thankfully I didn't have to. Before I could answer, one of the fellow programmers said, yeah, but remember every three weeks it'll crash and we don't know why? So yeah. So that is the question, right? The code is so complex, you don't even know what the problem is in there, and you cannot get to the point. So there are certain things you can do as an individual.

What can you do as a team of programmers? First, avoid shortcuts. I know we are all tempted to do this along the way. But avoid shortcuts wherever you can. And say, maybe this is the time to take a little bit of time and do this correctly. And let's spend the time to do this. Take collective ownership. Do not let one person own the code.

There should never be John's code and Sarah's code. It is the team's code. Anybody who has the responsibility and can take the responsibility to modify the code and ensure all the tests pass should be able to modify the code. Collective ownership is extremely important to me.

And promote positive interaction. Now this is not too easy, but we certainly have to try. The words we speak, how we communicate with other people, makes a huge difference. So rather than making people feel bad about the code they wrote, let's elevate them so they feel good about writing better code

and making good change in the software. And provide constructive feedback. For example, don't tell people your code sucks. Instead, tell them, hey, why don't you break this method into two methods? So don't tell them what is done poorly. Tell them what could be done better. That is a much better way of solving the problem. If that is a better way to do it, they can use it.

Or if they have an even better way to do it, they can always come back with it. So I have a recommendation that don't tell people what's wrong, instead tell people how it could be better. That's a better way to communicate most of the time. And do constant code reviews. I know what you're thinking. You're thinking, are you serious? You are telling us to do code reviews?

Yeah, absolutely. Code reviews are by far the most proven way to develop better quality software. And don't take this out of context. I want to emphasize it. But given a choice between writing test and code review, I value code review more. I'm not telling you I don't value writing test.

Please don't take that in that context. But between these two, I value code review a lot more. And the reason is, by far I've seen this to be the most effective way to really review and improve the quality of code. So this is extremely useful. And I know what you're thinking. You're saying, yeah, but code reviews never work.

I know what happened the last time you tried code review. You, in all good faith, you want to do code review. You started doing that on your project. But the day you wanted to do code review, you sent a meeting announcement saying, hey, Thursday afternoon at 3 o'clock is the code review in room 123.

And immediately, the guy whose code is going to be reviewed is thinking, wait a minute. That is called Bash James Day, because everybody is going to keep there and tell how his code is sucking. And he is like, maybe I should call in sick that day. I don't want to be at work. In the meantime, Julie is thinking, I already am behind schedule.

I would rather sit and write my code than looking at the stinging code that James wrote. In the meantime, the project manager freaks out. He says, wait a minute. Code review, that's the time that you did last time. And we had a fight. We had to call the cops. And we had to shut down the company. No code review for you, right? Because code reviews have turned into a highly political and emotional endeavor, and nobody wants to do it.

But we do code reviews all the time. We not only review code, we also review test cases. And I work with some fantastic programmers. Most of the time, I have no comments on their code at all. But I would come back to them and say, hey, you need to really add these three test cases that you

are missing. But how in the world can you do that? Like I said, we do this all the time. And the way we do this is very simple. We use what is called a tactical code review, rather than a team-based code review. So in first rule of thumb, there is nobody on the team who is so great that their code

doesn't have to be reviewed. So we don't have this hierarchy. We don't have the priest in the company that says, I'm better than everybody else. Absolutely not. Everybody's code needs to be reviewed. The second thing we do is, if I write a piece of code, as soon as I finish my task, I'm going to ask him to review the code, only him. And in the meantime, the code he writes,

he is going to review. In the meantime, the code he wrote, she is going to review it. So we do this very tactical code review. The next time I finish a task, I'm not going to give it to him to review, but I'm going to give it to her for review. So we rotate the people who review the code. And reviewing the code is part of everybody's responsibility.

We don't distinguish senior programmers and junior programmers in that. Well, guess what? If a junior programmer doesn't understand your code, you're in as much trouble, if not more, than when a senior programmer doesn't understand your code. So we rotate the review from among people. So when I write a piece of code, he reviews the first time. The second task I finish, she reviews it.

And we rotate among the team of people. And you cannot say, I don't have time to review code. That's part of your responsibility. If you don't review the code, your code is waiting for somebody else to review as well. So that is the time we spend along the way to review the code and improve the quality. Not only we review the code, we also review the test cases along the way and do that as well.

Now, one of the reasons to do this is explained really well by this code by a gentleman named Brian. And he said, oh, we do this all the time in our company when I explain this. And I said, well, if that is what you do, tell me how you benefit from it. And he nailed it. He said, we do code reviews because code reviews make

me a hero or make me smarter. I thought about this and said, wow, that's awesome. Hey, Brian, can I steal those words from you? He said, absolutely, go ahead, use it. And then I said, now you have to explain it to me what does it mean. And he said, code reviews make me a hero because when I give a code review to him to review, he comes back and says, oh, darn it.

I've never seen that being done that way. I learned something now. So it improves him, and he is beginning to understand the code a little differently, a better way to write software. But most of the time, the other person comes to me and says, oh, you should really handle this. You should really do this. You should name this better. And it makes me smarter because I'm

learning from the code reviews he's providing. So overall, code reviews can be extremely beneficial. And if you ask me if there's one single change I can make to developing software, that would be code reviews. It is something it's very practical to do, but it requires people to have the right attitude.

And we have done this. And in projects where we did this, the number of bugs we got in the code could be counted with fingers in one hand. That's how few we had. In parts that did not get review, we had thousands of bugs in the system with comparable amount of code. So there is absolutely no other recommendation I can make enough.

That's how convinced I am about this. And I was on projects where I was also in offshoring roles where somebody wrote code elsewhere and I had to defend to the clients. And the easiest way I could defend to these things was every single line of code written was reviewed from both sides.

And I would write code and they would review it. They would write code, I would review it. And the reason was now we were familiar with the code along the way as well. And that helped us a great deal. So I cannot emphasize this enough. And so rigorous code review definitely is important. And it removes up to 90% of errors in the software

as Bob Glass talks about in his book. So the second recommendation for a team is treat warnings as errors. Now if you really ask yourself, how many of you have seen errors, warnings in your code? Quite a few of us. Almost everybody raises the hand. And a lot of times you come to the project

and you compile it and you see warnings and you say, wow, really? And then what do you do? On the first day of the project, you are genuinely so motivated. And you tell yourself, I'm going to fix all of those. And then you look at how many there are and then you change your mind. It's like, no, not for me.

But what happens? I was on a project. And this was a brand new project for me. It's been around for a while for the company. And I compiled the code. And there were tons of warnings. And I'm like, really? Warnings? And I thought to myself, you know what? They hired me to write code not to fix warnings. I'm going to ignore it. A few minutes later, my mind is kind of saying,

but I wonder what those warnings are. I'm really curious, right? I'm inquisitive. So I look at one warning. I was scared. It said, if flag single equals true. This is in production code, right? I'm like, no way. How could this be a warning, right? This is not a warning. This is not even an error.

This is something where the compiler should drag the program by the collar, give a slap to him, and say, don't do that, right? And this was in production code. How could this be left over there? Now I have a shaking. What else is there I don't know? And I start looking at more warnings in the system. And they are very, very scary. So the very first thing I would say

is treat warnings as errors. So if there is a warning, your compiler stops and says, I will not build this anymore. OK, that's great news. And how do you do this? I was suggesting to turn on a flag in Visual Studio to treat warning as errors. And I had one guy in my team who said, oh, don't do that. Don't waste your time.

I was quite upset for a second. I said, what do you mean? Why don't you want to do this? He said, because somebody would turn off the flag one afternoon and continue to write code for three hours with warnings on it. What a waste. I said, do you have something better to do? He said, absolutely. I'm going to walk up to the continuous integration machine and turn on warnings as errors, because that's

such a great recommendation. I went up and hugged him. Absolutely, that is the right way to do, because then nobody can slip code in there with warnings in it. I was mentioning this to a company, and I was hearing people giggle in the back of the room. So I said, all right, guys, you seem to not like this idea. And they said, of course not.

This is terrible suggestion. I said, why so? Why is that such a terrible idea? And they said, well, what if you are working in a legacy code? Oh, I believe you guys have warnings. And they laughed at me. I said, how many warnings do you have? They said, how about a lot of warnings? I said, OK, how about 1,000 warnings? And they said, you don't understand the word lot, do you?

And I'm like, OK, I won't ask you the numbers. And I said, OK, you got a lot of warnings. Let's call it x. We don't know that number that will remain unnamed. And then I asked them, in six months period, have you had more warnings or fewer warnings? And they all kind of said, of course we have more warnings today than we did six months ago.

And what are you doing about it? And they all kind of shrugged and said, what do you think we can do about it? So that is a very wrong way to look at it, right? If you are inheriting code that is really bad, there's a name for it. It's called karma, right? Karma is your deeds. You inherit things, right? And you cannot change your karma.

But you cannot say, guess what? You guys gave me bad code. I'm going to make it worse in six months for you. How about that? That is professionally wrong, morally wrong. So what do you do? So what I recommend to them is, the first thing you do is, whatever that number is, x, I don't care what that number is, write a stupid script.

I mean, we as programmers can do this, right? Write a stupid script, and the script measures the number of warnings today. And that becomes your value x. Put that script as part of your continuous integration. And every time you check in code, it looks for the number of warnings.

If the number of warnings is x or less, it keeps quiet. The minute the number of warnings is more than x, it fails the build. So what does that tell you? That you added one more warning than that x number of large number of warnings you had in your code.

When you do remove a warning, then the script resets its index x to x minus 1. And now you start seeing this get better over time. And I mentioned this to him about three, four years ago, and I kind of walked away. I was back at this company about six months ago, and one of the developers came to me and he said,

they have several modules in their application today. There are no warnings for the first time in 15 years. And there are other modules where they still have a lot of warnings, but for the first time, the number of warnings is decreasing over time. So my argument is, it is not an all or nothing proposition.

You can make things better incrementally in those cases. Nobody in their right mind would say, stop all business, go fix x number of warnings where x is large number for the next three months. That is not practical. But if you put in place a way to measure the number of warnings and promise that you will not create any new warnings in the system,

I would guarantee in six months, you would have fewer warnings than you started out with, and you begin to improve the quality of software as time goes on. So in terms of complexity of code, keep an eye on the code. Look for various things. I am a huge fan of code coverage. I know a number of people who tell me, that's a bad idea,

don't look at it. But every time I look at a piece of code that has a low coverage, I see a smelly code sitting in there. So let me tell you how I use code coverage. To me, code coverage is like cholesterol number. I go to the doctor, and the doctor looks at me and says, oh Venkat, your cholesterol number is so high,

this is very unhealthy. And I say, what should I do, doc? Well, you should exercise, you should eat right, take these medicines, come back in six months. And I exercise, eat right, go back in six months. And the doc looks at me and says, oh, here are your numbers, oh wonderful, great job Venkat, your cholesterol number is really good now. Immediately I set a piece of paper to him and say,

could you please sign here, what's this? Surgicate of good health. And the doctor says, no, I can't do that. Your cholesterol number is good, doesn't mean you are in good health. I know this is not very encouraging, right? It's exactly the same. Your code coverage number is poor, you have a problem. If your code coverage number is really good, you don't have that problem anymore, right?

So it doesn't mean everything is good, it doesn't reflect a better quality of code, but the lack of it definitely reflects problems you have to address. So when I look at it from that point of view, I'm quite comfortable looking at the code coverage, and I use this quite effectively, and there are several tools you could use.

But when people argue with me and say, all right, I'm really writing code here, for the life of me, I cannot figure out how to reach in and test this code. And I usually have one recommendation for them that they seem to really not understand very well. And I tell them, if you don't know how to test the code, why don't you remove it, right? Well, after all, you're not testing the code,

doesn't matter, it's not there, right? Then you figure out a way to write a test for it and then write a code for it. If you don't have the courage to do that, I've got a suggestion for you. There's a tool very appropriately named as Guantanamo. It goes through your source control and deletes code with no test on it. On some projects, I'm scared to use it.

It may leave an empty drive behind, right? So absolutely try that and see what happens and get rid of the code that's not being covered by test cases. So we talked about code coverage. Reduce complexity of code as much as you can. How do you reduce complexity? One way is to have code reviews. Have other people look at it. If you want to use tools for this,

there are certain tools you could use that analyzes the code and looks at the path of the code to make this decision. One of them is the Thomas McCabe Index that looks at the node points and decision points through the code and determines the complexity of code. But unfortunately, though, complexity is simply not adequate because complexity may say a problem in code,

but it can be compounded by other things. You may argue this code is really complex for a reason, but I've written a thousand tests on it. I'm like, okay, I can live with that maybe, temporarily with that. So let's look at it a little differently. Let's say for a minute that I'm looking at, actually I'll come back to that in a minute.

So you certainly want to look at the complexity of code, but you want to really look at it in terms of the relationship of the code also. In other words, a code that's very highly complex is really hard to test as well, and we really have to really break it down into simple things. But in terms of code itself, we have to keep it small. Now, of course, we all know we have to keep code small.

How many of you think that long methods are a great idea? Raise your hand if you do. Nobody is raising their hand, right? Nobody here thinks long methods are good. Usually one person raises their hand, and I ask him why. He says because it's more efficient. And you gotta give credit, that's true.

But that's when Nixon was the president. But a lot of things have changed since then, right? It's a different architecture. In line, all these things have evolved. So here's a different question for you. At work, how many of you have seen long methods? Look at that for a minute. Just look around for a minute, right? Almost everybody here raises their hand.

This is called cognitive dissonance, right? We all know writing long methods is wrong, but we all see long methods. But I know how that happens, because none of you here have written those long methods. I know that. The people who wrote those long methods are at work today making those methods longer as we speak,

which is kind of scary, right? So absolutely, we gotta put an end to it. So if there's a second recommendation I can make for you, other than code review, is avoid long methods. Now, how long is a method when it is long? And somebody says 20 lines. Somebody says 30 lines. And there's always the Ruby guys who say seven lines,

right? How do you know what the number of lines is? You say, well, here's an idea. A method is short enough if you can fit the entire method into one window and don't try to lower the font size, right? Okay, that's another metric you could create. But if you really wanna think about it, it is not the number of lines of code that matters.

What really matters for the length of the method is the method should do one thing and be at one level of abstraction in the code. That is the real key. So as long as your method can be focused at one level of abstraction, then it usually ends up being relatively small.

And so make it cohesive, single responsibility principle, and one level of abstraction is very critical for us to do. Keep it dry, remove duplication of code. Duplicated code is one of the other ways we can improve software quality by removing the duplication. So actively find, there are tools that you could use.

For example, there's a tool called PMD for Java, Simian for .NET, the word Simian means monkey, meaning you monkey with the code. So you can do Simian analysis and find out where the code is duplicated. And you can remove actively duplicated code in the system. But if you really want to address the quality of software,

let's think about this a little differently. If I tell you my code is low complexity, and I tell you that the code is really having low automated tests, then I would argue that the risk is fairly high. Because a code that is not tested is a risky code.

Because what happens when you modify the code? Think about that for a minute. What happens when you change the code, when you don't have tests? That's exactly the reaction, right? You do this, and you go to the programmers and say, does your code work after you change? And the programmer says something wonderful.

The programmer says, I hope. What a beautiful word, but there's a name for it. That's called JDD, stands for Jesus Driven Development, right? It's okay, to have faith in the Lord is a good thing. But I don't want to trouble the Lord with silly code I write. I want TDD, not JDD, right?

So when you have a low automated test in your code, it becomes extremely hard, and you have to rely on hope and shrugs, and there's no feedback cycle to tell you that your code works. So automated tests tell you that not only the code worked before, but they continue to work the code as you evolve it.

So if you have a low complex code with low coverage, I rate it as a high risk. But what if I have a low complexity and high coverage? That is the beautiful land you want to live in, right? That's great. What if you have high complexity and low automated test case? That is higher risk than high.

This is the world you don't want to even dream in your nightmares, right? And then of course high coverage and high complexity is all right. But how do you really explain this to the team and say your code really is in a bad shape? So there is actually an interesting metric for it. It is called the change risk analysis prediction.

And change risk analysis prediction is a wonderful metric. And what the change risk analysis prediction metric says is that it says, I'm going to analyze the complexity of your code. I'm going to look at the coverage of your code in terms of test, and I'm going to put those together and measure the so-called crap threshold.

And the crap threshold says that your code has been moved into crappy territory. So you don't have to tell the team the code is crappy. You can show it to them now, right? And there are tools like crap4j and crap4n that measure these values for you and tell you what the value of the crappy

threshold is. So you could use tools like this to measure the quality of software and gain an impression on quality as well. So take a look at some of those tools. And as this beautiful quote says, It was one of my journeys between the ed-sac room and the punching equipment that the relation came over me.

With full force, the good part of the remainder of my life was going to be spent in finding errors in my own program. That is pure courage, isn't it? And that is a realization we have to arrive as programmers, is that we have to deal with it. So we have to deal with code smell.

Kent Beck coined this term called code smell. What a beautiful metaphor, code smell. Because why is this a great metaphor? Because you enter a room and your nose twinches a little bit because you smell something. And you say, hm, it smells funny here, isn't it?

And everybody in the room kind of look at you and say, really? Because nobody feels anything. And you sit there and start working, and you kind of look around and it's like, it really is smelling here, isn't it? And 30 minutes goes by, and you've entered this quietness. You don't feel that anymore. Your senses have dulled down, and

you're part of that smell environment. And the next guy walks in, isn't it smelly here? And you look up and join the other people. Really, right? So that is why it's such a great metaphor. What happens when you join a project? The first day on the project, you look at this code and say, who the heck wrote this code? And you join the project.

Six months later, you don't feel a thing. You are writing code in the product, right? And we tend to lose senses over time. So it's important to be sensitive to this and clear up things as soon as we can. Otherwise, we kind of get lull in the senses, and we kind of tend to lose that. So look at the code smells and identify that.

What are some of the code smells you can think of? Duplication in code, for example, unnecessary complexity in code, and various other factors you can take a look at, right? So how do you deal with code smell? Keep an eye on it, pay attention to it, clean it up, schedule time for paying those technical debt as well.

You say, you know what, that code is smelly. I'm not gonna do it right now, but I'm gonna schedule time for it to be cleared, right? So this is something we could learn from William Zinser. I'm not gonna spend time on it, but he talks about some ways to really make good communication in writing English. And he talks about simplicity, clarity, brevity, and humanity, and those recommendations really are good

for writing code as well. I want you to kind of take a look at it later on. Second thing I would say is throw exceptions, but be careful when you should throw exceptions. Sometimes people just throw exceptions all the time. I would evaluate this very clearly given a situation and decide whether it's the right thing. Second thing, don't write clever code, write clear code.

I can't tell you how many times I've been bitten by writing clever code. And when you write clever code, you think it's really cool, but nobody else understands it, and then it comes back to haunt you. So I used to write clever code. These days, the minute I write the code, if I feel it's clever, I immediately delete it. And I start over because it's so scary,

it gives me problems eventually. And don't rush to write code. Take the time. Writing quality code takes time to build, and you have to devote the time to do it. You cannot do it in a rush. What about commenting code? I have to tell you, commenting code is one of my pet peeves. And a lot of times comments are pretty useless.

Comments are often written to cover a bad code. I want comment to tell me why the code exists. I want the comment to tell me something that I cannot just learn from reading the code. So type of comments I really, really hate, for example. So one example, nothing makes me angry more than this.

Somebody writes a class, class car, and then they write public car and then constructor. It's very important, thank you, right? Or even better, right? There was a day I was looking at a piece of code. It said I plus plus with a beautiful increment. I'm like, so thank you so much for clarifying that. I was just not sure looking at the code, right?

These are absolutely useless. So instead focus on writing comments that tell you something extremely useful about why it even exists in place. So to me, a good code is like a good joke. When was the last time you said a joke and nobody understood it, and you start to explain it?

And they got it. So the number one rule of telling joke, never explain a joke, right? Because they didn't get a joke, you say, let me explain it to you. And they listen to you painfully and say, yeah, what's funny about that? And then you try, let me re-explain it to you. It gets very painful, right? A good code is like that. You just.

say it, and it's got to click, and they get it. If they don't get it, what do you do? You go home that night, and you refactor your joke. And that's exactly what you do with the code, right? Don't comment the code, rewrite it, refactor it, so it's easier for people to understand it. So make the code self-documented. I saw this code in a client site,

which was very painful to see. This is a code which is extremely scientific, very hard to maintain. And as I was reviewing the code, I saw somebody comment, God help, I have no idea what this means. And their entire application had these fields, which were L1, L2. These were extremely scientific. And you can imagine what it takes

to maintain this software. So give good names, and make it clear and self-documenting so you don't have to really write comments for those things. And finally, to talk about it, throw the error on your face. Don't ask people to go dig through log files to find errors. Make it very easy for them to approach it and find it.

So I want to summarize what we talked about with about 10 points we can take away as the final thoughts to leave you with. The first thing is practice tactical peer-based code review. I cannot overemphasize that. I already did, but I want to emphasize practical code review. Tactical code review is very important.

Consider untested code as unfinished code. I believe in automated tests. It takes a certain amount of effort to write these tests, but the investment pays off very huge. Well worth spending the time and effort to do that. Make your code coverage and metrics visible. This is so useful, I can tell you how.

If you push this out into monitors in your coffee machine, as people walk around, they look at the visible code coverage and bug count and metrics. Now it's a pressure on everybody to do better. And even better, right? If I come to the coffee machine, my code metrics are displayed, my project code metrics are displayed,

his project code metrics are displayed, and his is so much better than mine. Guess what I'm going to do? I'm going to run into him and say, hey, great job, you guys. You're doing really well on your project. I saw the metrics. Oh, well, thank you very much. He's very modest, right? And I say, no, no, no, please tell me, what are you guys doing? This is one thing that bothers me a lot. I walk into large companies as a consultant.

I would talk to one group of people doing some wonderful things. In the afternoon, they would say, go talk to this team. And they would have no knowledge of this happening on the second floor. I would say, guys, the guys on the second floor are doing this. Really? And they don't talk to each other. By putting this out, you're making aware as to what people are doing and where

to go for some information between companies, between teams. Don't tolerate anyone trashing your code. Take it very serious. If somebody breaks your build or writes poor quality code, immediately go back and say, hey, what's going on here? How can I help to make this better? We don't want this kind of poor quality code here. Let's improve this together.

And write a self-documenting code and comment wise and not what it does. We talked about that. Use tools to check quality of code and automate it as much as you can. And continuously measure this along the way. And treat warnings as errors. I talked about this already. And keep it really small as much as you can.

And keep it as simple as you can. You can take a look at some of these references later on. Thank you very much for your time. I really appreciate it.