Code Quality: Walk the Talk or Just the selling point?
Posted by Jai on February 3, 2010
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.
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:
- Start well: initial integration with quality tools, show initial nice metrices around that exists.
- 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.
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.
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.