Archives
- ► 2012 (8)
- ► 2011 (157)
- ► 2010 (174)
- ► 2009 (12)
Which topics would you like us to cover more?
Latest comments
- How to reset you Kindle
3, eve...
Thanks for this article and the related "Inside th...
By H K - How to reset you Kindle
3, eve...
How do you drain power on the board? I dont have r...
By Grace - How to reset you Kindle
3, eve...
You're welcome!
By Bas - How to reset you Kindle
3, eve...
Thanks man....removing the battery worked like a c...
By DaveMan - nHapi
example
Hi Slypete, Thank you for your comment. This way w...
By Bas - nHapi
example
Hello, Employing .Net dynamics, one can implement ...
By slypete - Implementing MLLP in C#
Hi Mayura, I'm not sure I understand your question...
By Bas - Implementing MLLP in C#
I have used SSL stream to secure the MLLP transact...
By Mayura
Latest tweets
Architecture, security and coding Development processes and
quality code| Development processes and quality code |
| Written by Division by Zero |
| Wednesday, 11 May 2011 23:16 |
|
Today I read the article 'Process kills developer passion' by James Turner. His point is that all the quality assurance surrounding development (test driven development, code coverage, reviews, etc.) kills the passion of developers. This will result in poor quality code. While he really has a point, there has to be a middle ground. Long time maintenance is often forgotten. This is what code quality is really about: the evolution and long time functioning of the software. The software won't end after the project stops, therefore it's a good idea to put some effort in a standard way to document, test and maintain the code. And yes, these bits are boring (hey, it can't be all fun!) This middle ground must always be a pragmatic approach. I always value the human factor. Personally I'm convinced that reviews are a good way to ensure quality on the long term. Not only will code be corrected, but more importantly: developers will talk about there code. In this way developers will learn from each other, which will increase the joy of coding. As for TDD I believe this should be applied in a pragmatic way. If you do true TDD I'm convinced your code will become unmaintainable or at least will have a really steep learning curve (which isn't a good thing). Coverage is a quite meaningless metric. The more pragmatic approach is to automatically test the code on crucial (business) logic and bugs that appear over time. Tags:
|
Only put off until tomorrow what you are willing to die having left undone. - Pablo Picasso
