Comments on: Isn’t quality code a feature ? http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/ "I write pretty software" Mon, 23 Jan 2012 10:32:42 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Allan http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-46544 Allan Fri, 24 Oct 2008 23:08:07 +0000 http://www.arpitonline.com/blog/?p=149#comment-46544 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! 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!

]]> By: paradox1x http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-46266 paradox1x Sun, 19 Oct 2008 17:30:02 +0000 http://www.arpitonline.com/blog/?p=149#comment-46266 <strong>Software Development Links: Practices and Thoughts Edition...</strong> Three links from two Comcasters: codeartisan: Jon Moore: Measure your improvements codeartisan: Jon Moore: Cracking down on technical debt code...... Software Development Links: Practices and Thoughts Edition…

Three links from two Comcasters: codeartisan: Jon Moore: Measure your improvements codeartisan: Jon Moore: Cracking down on technical debt code……

]]> By: Matt Guest http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45789 Matt Guest Thu, 09 Oct 2008 13:01:29 +0000 http://www.arpitonline.com/blog/?p=149#comment-45789 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. 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.

]]> By: arpit http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45784 arpit Thu, 09 Oct 2008 02:16:22 +0000 http://www.arpitonline.com/blog/?p=149#comment-45784 @Jon Very cool. I am glad you have a formal place in your work-flow for code quality. @Jon
Very cool. I am glad you have a formal place in your work-flow for code quality.

]]> By: Karl http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45783 Karl Thu, 09 Oct 2008 02:15:12 +0000 http://www.arpitonline.com/blog/?p=149#comment-45783 Mat and crew have us working with Review Board for a similar effect Jon. I think that comes down to the crux of it. Mat and crew have us working with Review Board for a similar effect Jon. I think that comes down to the crux of it.

]]> By: Jon M. http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45782 Jon M. Thu, 09 Oct 2008 02:08:12 +0000 http://www.arpitonline.com/blog/?p=149#comment-45782 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. 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.

]]> By: Karl http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45781 Karl Thu, 09 Oct 2008 01:38:27 +0000 http://www.arpitonline.com/blog/?p=149#comment-45781 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)? 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)?

]]> By: arpit http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45778 arpit Thu, 09 Oct 2008 01:04:30 +0000 http://www.arpitonline.com/blog/?p=149#comment-45778 @Campbell, yeah right next to -create-bugs=false ;) @Campbell,
yeah right next to -create-bugs=false ;)

]]> By: Campbell http://www.arpitonline.com/blog/2008/10/08/isnt-quality-code-a-feature/comment-page-1/#comment-45777 Campbell Thu, 09 Oct 2008 00:49:17 +0000 http://www.arpitonline.com/blog/?p=149#comment-45777 Isn't there a compiler switch -make-good-quality? Isn’t there a compiler switch -make-good-quality?

]]>