Code Quality: Walk the Talk or Just the selling point?

Some of the mind boggling thoughts that must have come into your mind also like the times when as a developer you compromised on code quality because of tight dead lines etc. or as a team lead or manager you compromised on quality to speed up the delivery or because of risk management to reach the milestone. May be, as a team you started well but what it costs to keep up the pace for the code quality. There are many varied factors around it and we will have a brief look at it and will see how it works in the end.

To start with, we all know about the code quality significance and the long term benefits or implications (lets assume :)).

Code Quality as Selling point

If we put aside the players in the market to do the job in cheap way and deliver the crap, on broader way we have majorly two kind of players:

Big Players: How it works for big organizations that they have big processes in place to show the delivery capability and their track record and promise to deliver quality software. For clients, most of the times this much is enough to trust the quality and it sells very well.

Small Players: How it works for small organization is to focus on quality. They can not compete with big organizations in numbers but promise to deliver quality software at any cost. For clients, for whom quality is first criteria will look around for such players and usually they cater very niche market.

Lets have a look at the different stages of software development that how the code quality is compromised. This is more or less independent of the process followed, the only difference is that in traditional ways like waterfall the chances of compromise are more because of fixed time etc. and in Agile the chances of improving and rework on code quality are more (we won’t go much in details here, just that in Agile you have the flexibility to improve upon it). In this case lets say team is doing Agile (doing, being not sure :)).

Code Quality during different Development phases

If you selling code quality as one of implicit deliverable, lets see how the code quality graph usually go in different phases of the development.

Starting Phase:

Well, both the big and small players have process and tools in place to display that they deliver quality software. The team starts with putting in place the different tools to check the code quality. Team start putting nice metrics to display the graphs to prove it. Lets have a look at the factors which decide the code quality at initial stages:

Small code base: the code base is small, metrics look good and all do their bit

All excited: team is excited and show show that they deliver quality software

Process in place: all tools and process in place to get started, but sometimes it takes time for the team to find out the best solution and it what is good quality in their perspective.

All know what to do: team share initial learning and initial stages more of learning curve and finding the best solution

Less to handle: less to handle, enough time to catch up

On big picture, it looks like the team is doing good on code quality perspective.

Intermediate phase:

As the time passes, more and more functionality come, more and more modules come, more and more integrations come, more and more delivery load come into picture.

Keep up delivery pace: team get used to of ignoring code quality to keep up with the pace of delivery.

Definition of Perfect changes: the definition of Perfect changes according to what works well for the team.

More functional issues: soon things start to get apart, there are more functional problems than spending time on code quality problems.

Technical Debt increases: team start adding to technical debt, thinking to take the things later on priority basis

No common ground: multiple hands working, hard to maintain common ground. Different implementations of same technical and functional problem.

Prioritization problem: lead/manager/client start giving more priority to deliver more functionality in each iteration

Many more similar problems…

On big picture, the technical debt start increasing. Team/Manager/Client all start focusing on delivery. The earlier selling point of Quality is lost in the way. All happy that the things are working ok.

Delivery Time:

The final delivery moment comes.

There can be two things here (“Do baatein ho sakti hain ab”, sorry it reminded of hindi series Office-Office🙂 ).

First, Team struggle to make delivery on time:

delivery pressure and so forget about quality, application is working fine and lets just give the final touches.

less importance to code quality, more to functionality

team start compromising on quality

Second, Team start polishing code :

If quality metrics are part of deliverable, you start putting test cases for the code (TDD and stuff, forget about it, was lost somewhere and team doesn’t bother about it at this moment).

If client start asking for third part audits, team start doing the exercise to put test cases and policing the code around (not the best solution as the team but that is what they could deliver in those circumstances).

If it is a product and quality part to sell it to further customers, team start improving nice graphs and metrics to sell the product.

The General Trend

Hard to say and generalize it but usually this is what the trend seems like. Player/Client both sell/buy it with Code Quality as being one of the criteria but in most the cases it is lost and the solution you get in the end is more or less based on the engagement you had during that period.

Question left to all is to have their own definition of Perfect, what works well for you or where you would like to draw the line, what is acceptable/unacceptable for both or in the end is it just the selling point.

2 Responses to “Code Quality: Walk the Talk or Just the selling point?”

Shailendrasaid

Jai,
Thanks for this post.
But how do we define code quality?
Tools alone cannot ensure good code quality .. a case in the point is over emphasized use of CheckStyle , PMD in Java development. These tools can find very obvious issues but it cannot replace peer code review. Every team should have a code review guideline based on which code review should be done . And more importantly the definition of Done for a story should incorporate Code review as a must in an Agile setup.
One of the most important issues that i see in a agile setup is that requirements change too frequently and so the architecture of the project will have to be designed to be flexible enough to incorporate those changes.

You did answer the question within the points. Yes, the tools help you find the obvious problems (better to keep check of these problems because the obvious problems may act as indicator of some bigger problem) and may not fit best in the context of every code problem. Code Review/Pair programming are such practices to keep a tap on not only on such obvious issues but also to find the best approach in the context of the problem. But what defines the quality of that code is how the person looking at the code in that context perceive it.

Handling change requests is the beauty of Agile, I agree with the design to be flexible but the problem is that how do you approach to keep the design flexible enough over a period of time. The problem is over a period of time, in the name of Agile, the design start decaying and team start focusing more delivering functional points and quality part goes in the back-burner due to varied number of factors.