Monday, June 30, 2008

My favorite benefit of Unit Testing

Test Driven Development has lots of benefits: Better quality code, good code coverage, good design, and refactoring.

Refactoring is my favorite. I try to write my tests before I write my code, but sometimes, I get a little ahead of myself and jump right into code. I know what it needs to do after all, and my mind just attacks the problem and puts all the code and if statements in place to handle it. And then I realize, that I need to test my code, so I write my unit tests. As soon as the unit test starts to be cumbersome to write, I know I have a problem. I've written my code to be too complex. The Unit test should be a simple thing to set up. Now I get to refactor the code.

Test Driven development makes you think. It makes you think about what a function or object should do, and what it should not do. And I take a lot of pride in refactoring. Not just other programmers' code, but mine too. Refactoring should always improve the code. Make it more self documenting, more loosely coupled, more testable. I love taking my own code, code that would have worked, and making it better. Test Driven Development is the tool that helps me reach my goal of good code that's easy to understand.

Tuesday, June 24, 2008

Thoughts on laptops in school

I've got a lot of thoughts around laptops in school. I've not read of any school that's actually succeeded in making laptops in school work, however, I also think that laptops are a great way to introduce students to computers, the internet and many things that they need in the corporate world. Not every job will need computers like that, but the computers could help them get into a more advanced position.

The New York Times and The Pittsburgh Post Gazette both have stories posted about schools that are canceling their laptop programs. Apparently the students already know so much more about computers than the teachers that they spend the entire time chatting and doing things that they should not be doing.

However, I think that there are a lot more possibilities with computers. Topics that are not normally covered can be covered. Less books need to be printed. Students can and should participate in writing about school programs that are then made visible on the school website. All of the sports can be fully covered, but so can other activities that never get anything more than a single picture in the yearbook. Students should keep blogs about the things that they have learned.

If you know of any successful laptop programs, let me know, I'm interested. I want to see this succeed.

Saturday, June 14, 2008

Don't use BeginTransactiion within a transaction.

Running Java code the other day I ran into a strange issue. My mock unit tests all worked, so I deployed a change to test, but when I ran test, it didn't work. The real thing acted differently than my mock did.

It took me nearly two hours to track the problem down, and it was strange enough that I had to resort to stepping through Java code. I prefer to find where things fail with the logging statements.

My error was with this (psuedo-code):


UpdateRecord(Record record, boolean updateRelated ) {

beginTransaction;
updateRecordInDB(record);
if( updateRelated ) {
Collection related = getRelated();
foreach(relatedRecord in related) {
UpdateRecord(relatedRecord, false); // recursive call
}
}
endTransaction;
}


When the beginTransaction was called within the recursive call, the Connection threw an error.

The solution was to remove the recursion.

UpdateRecord(Record record, boolean updateRelated ) {

beginTransaction;

insertRecordIntoDB(record);
if( updateRelated ) {
Collection related = getRelated();
foreach(relatedRecord in related) {
insertRecordIntoDB(record);
}
}
endTransaction;
}

insertRecordIntoDB(record) {
// do some important stuff.
updateRecordInDB(record);
}


That refactor allowed me to not duplicate code, and let me only call beginTransaction once, so all related records were updated within the same transaction.

Friday, June 13, 2008

Why I hate 3rd party closed source applications

I didn't always feel this way. For years I have loved 3rd party tools, some kind of black box that I just plug into and trust. I tell it what it needs and it does what it's supposed to. When there's a problem I complain to support and they update their product.

I liked this method. For many years. It's a simple method. I put my trust in someone, and they provide service. It's a proven method that works, kind of.

The problem arises when the responsiveness of the third party is slow. I find a bug that affects a major piece of functionality in my application, only in odd circumstances, but still, it happens. There is no log, and no way for me to prove that the black box is where the problem is. Unless I had source code. Something that I could step into, modify to log, or even fix the problem. It may not be a change that the provider decides to ever implement, but it could at least handle my environment the way I expect it to.

I'm not sure if the change in my philosophy is because I've grown to be more advanced as a developer, or if the market and open source has changed the expectations. I may not understand all of the source code for an application, but if I can step through it, I can usually figure out what the problem is and being able to fix something now instead of waiting weeks for a response from the vendor can be huge.

Think about the software you use in your enterprise. If you don't build it yourself, seriously consider open source, or at least contracts that let you view the source code. Having the ability to fix those problems or find the actual problem sooner, even if you can't rebuild it, can help you work with the vendor to get a fix in place sooner.

Tuesday, June 03, 2008

Four benefits of Pair programming

Over the past year I have been able to practice pair programming as well as work on my own. Between the two methods, I definitely prefer pair programming. It has several benefits that I've been able to take advantage of, and that I think other developers will get a lot out of. The hardest part about pair programming is having a good teamwork mindset.

The four benefits are:

1. Stay focused more. I tend to get sidetracked when working, not just chasing down rabbit holes looking at pieces of code that I don't need to, but sometimes with things that are not even related to the current project. When I'm pairing, the other person won't let me get sidetracked in those situations.

2. Better design. Pair programming is the same as constant code review. Even when I know the right thing to do, I don't always see that what I'm programming would benefit from approaching it a different way. Having a second person sitting there giving opinions and even just asking questions, can cause me to think about the design of the code more and implement it better.

3. Better Quality. I won't say that there are no bugs. Runtime logic bugs still get through. However, combined with Unit testing there are fewer. But the more important aspect for quality is that words are sometimes a poor way to convey a message. The two of us may look at what needs to be done and understand it differently. This difference causes more conversation and better understanding with the client. It's not a chest beating for who was right, or more right, but an effort on the part of the team to make sure that the solution is right.

4. Better/Faster Learning. A huge benefit of pair programming is that a less experienced developer can pick up a lot of really good information. A competent developer can pick up new techniques and new languages in less than half the time if he is paired with someone who is good. This was a huge benefit for me. I practically learned Java in a month pairing with a good programmer.