I have had a few conversations with some fellow developers here and there (most often with Mat) around code quality, and sometimes I get really frustrated to see what passes for “Good enough for now” code. In user interface development, its very easy to confuse all work with all visually displayable features. But when you are going to live with the code for a while or this code is going to be the foundation of later features, how can you not track code quality?
And of course there are extremes to that argument. I have worked with enough wannabe-architects who want the code to be pristine and who would much rather write their perfect piece of software no matter what the cost (in terms of time, features dropped or developer-pay) is. They should be tarred and feathered cause they weaken the valid calls for code quality.
But there has to be a middle ground here. The problem is well-written code is hard to quantify. Features are blessed with visibility but architecture isn’t. I had a conversation with a friend yesterday on how I prefer being a developer to a designer since design is so subjective, and what I might think is wonderful design may be pooh-poohed by someone else (worse, my theoretical manager), but code either works or it doesn’t and thats instant feedback.
Software architecture or “well-written code” seems to suffer from the same problem of subjectivity as design to some extent. And if you are fortunate enough to actually have a conversation around code quality (and I dont mean in the theoretical sense but you actually sit down and review what you have written), its lack of visible benefits to the product makes it one of the first things to be dropped when trying to make deadlines.
How do you quantify code quality then? As a developer I can tell you it has real returns. In my (Flash) world it sometimes translates to faster load times, less taxing of the CPU, smaller number of classes to be maintained, but its really hard to measure. How do you say the swf weighing 300k is worth the extra couple of weeks than a swf weighing 600k that was never written but would have if checks on code quality weren’t there. How do you measure against something that never existed ! Worse, how do you track that when there is no feature that maps to lighter swfs ?
And then there are the the really invisibles: dead code paths within code, extra classes that you dont use or are so badly written that they are such pain to work with that other developer on the project just writes new classes with the same functionality? How do you check such things? How do you justify investment in tools that enable high quality code ?
Heck, if you had to justify version control, how would you? Thank God some things like that dont have to be justified anymore but when will that stature be given to tools like Review-Board. Is code quality just a developer itch ?
Do you track code quality ? How ? Do you use any particular tools ? Do you have coding standards ? Please share your thoughts here, cause I am really curious.
Does good code-base just accidentally happen to get written or is there a process to get to it ?
Code Zen 
Isn’t there a compiler switch -make-good-quality?
LikeLike
@Campbell,
yeah right next to -create-bugs=false 😉
LikeLike
Great post and good questions. And you’re right, there is a great deal of subjectivity here.
I think, ultimately, the best judge of code quality is that what you’ve developed can be understood by, maintained by, extended by, optimized by, a team of fellow developers, and has a low WTF per minute by them (see http://www.osnews.com/story/19266/WTFs_m per Mat of course ).
That’s not a developer itch. That is efficiency in time to deliver new features and handle maintenance.
How you judge that is by tracking how often developers must fix bugs related to your code, develop work arounds not addressed by your code, and are blocked for inordinate amounts of time by not being able to refactor or improve your code.
It doesn’t happen by accident. Simple strategies like Make It Work, Make It Right, Make It Fast (see: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast) , Test Driven Development (see: http://c2.com/cgi/wiki?TestFirstDesign), Spartan Programming (see: http://www.codinghorror.com/blog/archives/001148.html), in the Java realm using well known design patterns, and using existing libraries wherever possible (don’t reinvent the wheel – keep your hands off the keyboard !!!!!) help us towards these goals. In addition there are tools like FindBugs (see: http://findbugs.sourceforge.net/manual/eclipse.html) that help us here as well.
Understanding the problem domain you are solving influences matters a great deal as well. What are the common issues your fellow developers face when working on solutions? Does what your developing help alleviate these issues or aggravate them for no good reason (other than intellectual curiosity)?
LikeLike
We’re trying a new method on our team: one of the “Definitions of Done” for our stories that involve code changes is simply that “someone else has looked at the code you’ve written”. You can get there anyway you want (pair programming, actual code reviews, you write the unit tests / I’ll write the code), etc. It doesn’t actually take that long to do, and I think is having a beneficial impact on our code quality.
LikeLike
Mat and crew have us working with Review Board for a similar effect Jon. I think that comes down to the crux of it.
LikeLike
@Jon
Very cool. I am glad you have a formal place in your work-flow for code quality.
LikeLike
To me maintaining code quality is all about the broken window scenario explained in the book ‘The Pragmatic Programmer’
The theory comes from inner city police who realized that a single broken window left unattended in a building will start a cycle of neglect that will plummet it into a state of unrecoverable disrepair.
I’m sure we’ve all patched a piece of code in a hurry to quickly get around a problem that we didn’t feel we had the time, responsibility or knowledge to fix. There are usually comments around the offending code like “Temporary fix to get around such and such” or “TODO: remove after testing”
Every one of these patches a developer comes across in the code effects their morale and overall confidence in the project and raises the possibility of them taking the quick and dirty route again. Unless these are addressed rather quickly you’ll end up with a mess of spaghetti code that is going to cause issues down the road.
In my experience team-based code reviews help to raise awareness of the code with developers who may not normally get a chance to see the big picture, gives coders the chance to show off a little and also makes them accountable for their work. When it comes down to it, nobody wants to let down the team. And if they do then that’s another problem all together.
LikeLike
Arpit,
I tried posting the below on your About page but ran into an error.
You have a really interesting background. Do you have any place online you display your illustration art for magazines and newspapers?
Are you open to side projects? I’m close to securing some funding and I’d like to explore an opportunity to work with you. Please email me a response. Thanks!
LikeLike