the Design Experience Weblog Archive

Image from Wordle

dpkg-deb -x debian-file target-directory

There are many contributors who, for whatever reason, may attempt to contribute a huge chunk of code, fully formed, as if there was no history to the development. That is, instead of building up their code in the open and comitting their code often, they work alone for months or years and suddenly this new feature appears.

Unfortunately, it is not very often that this is good news. First, anything that huge is bound to have bugs, especially if it hasn't been tested in a variety of situations. Second, by working alone, the developer has not taken advantage of the experience of the development community. Code review, and advice of other programmers is very valuable.

The author over at iBanjo suggests this is due to insecurity. That is, some programmers are afaid to share their code for fear of critcism. For the good of the project and development community programmers should work to overcome this fear. If you are afraid your code is not up to the standards of the community, there is much less chance your contributions will be accepted if you haven't taken any advice from other developers.

Another intesting point in the post is that distributed version control can actually make this worse. It affords working alone much more than CVS or SVN. A programmer can very easily fool themselves into thinking they are working with a community by developing their code all alone, and then contributing a huge patch back because the tools support this type of contribution.

I hope I don't make these mistakes too often. All along as I have learned I have sought out advice and ideas from other programmers. I know I don't have all the ideas, and more often than not, an extra pair of eyes will see a problem in a different way, and help point me in the right direction.

To write effective tests, you need to make sure each unit of code only does one thing, and it does it clearly without unexpected side effects. This gives you a chance to reflect on the intentions of the code. Very often, while trying to understand how to write a goode test, you can discover a way to improve the code. Almost every time I write a test I find a way to improve the code while I am at it.

Catching bugs is an added value of unit testing. The real value comes from thinking and reflecting on your code.