I had a little problem with some code that went live an through a NullPointerException, causing various problems in the production system. It was far from a disaster but not great that such a thing should happen. Additionally The error was hard to track down to its source. When I did track it down I found the problem described in this post. As soon as I saw it I knew that was contributing not only to the issue but causing additional problems.
The key here was that in testing which I reviewed with the author of this code everything was OK. I would like to have unit tests for everything testing every possible issue. But we don't. Its not always practical, its not always easy to know the issues ahead of time. We should, I should insist on it. Would projects that are running late run later, most definitely. Would we have less problems once they went live, almost certainly. I just don't have the man power right now to get everything done, and remember I am not the boss. My superiors are all non technical. They want things done yesterday. They don't understand why it isn't ready just that it isn't. As long as I can rule out critical bugs it works in my favour to get things rolled out and running, and solve the minor issues as the come up. Its inefficient and its bad practice. Solution, if you are in the same position as me then get a bigger budget and hire and extra programmer or two.
With or without the extra man power there are two possible methods that can be used to avoid at least some of the issues that come up when going live with new code. Pair programming and code review. At my previous place of employment we used both to ensure as few mistakes as possible. Pair programming is an interesting method, because it requires one computer and two people. One is in the driving seat and the other sits next to them and contributes. Anyone familiar with Agile or Extreme Programming will be familiar with pair programming. When it works its great. The time lost by having to programmers work on one piece of code is gained back by having higher quality of code, that is easier to maintain, and with less bugs. Even things like the write / compile / test cycle is improved by having less syntax errors (due to them being spotted by the one not doing the driving). Ideas are generated and turned over faster. When it comes to maintenance or fixing the bugs that do get through having two people that worked on the code originally can be very helpful. If one is off on vacation or sick, or worse has left the company, the other is likely to be around. This extra ownership of the code is so helpful in these situations.
An old colleague of mine envisioned people rotating the pairs reasonably frequently, lets say one person worked with one pair in the morning and another in the afternoon. The more people you have the more possible pairs. This could mean even more that two people have some ownership of the code. Switching pairs around will give people the opportunity to take a break from each other, which is often needed in some cases, and to find really constructive and destructive pairings, to be either encouraged or discourage in the future. An additional benefit of pair programming is the lack of other distractions, you cannot be sitting in front of some code when working with someone and then suddenly check your facebook/gmail/twitter. You will certainly need more breaks, but you wont spend real coding time wasting it on the internet.
Where it breaks down is when you do not have many people it can still be done but without the variance of a large group. The number of possible pairings is n(n-1)/2 (triangular numbers), so in smaller groups this is limited. Additionally not all possible pairs work. I was often paired with weaker coders which meant I was doing most of the thinking. It was also frustrating for me not driving because the driver was working so slowly. In some projects I was working with one other programmer and we would spend some time working on the same code and other time working separately. The other coder would frequently get stuck and ask to do some work in a pair. This was code for either me working and explaining what I was doing to his code as I went along, or sitting behind him growing ever more frustrated as I told him what to do. That was a particularly nightmare case. Other pairs that I worked with were great. We thought alike, solved problems quickly together and saved time exactly in the ways mentioned above.
Code review is a lot more annoying but is a great final barrier before moving to production. I would often work with another coder on some code, then later go to someone more senior than me to be my pair for the installation. This meant that I had to explain all changes to the senior person, who would look over the code for any glaring errors, and understand the changes that I had made. Installation was made safer by having someone look over my shoulder making sure that I didn't do something stupid in production. The reason its annoying to do is again because it means taking the time of someone senior to go over something you know well again. If you want to get something in to production quickly it can be really annoying having someone asking you to justify every line of code. However in the long run this is the safest way to do things.
If you haven't tried pair programming, try it, even for a couple of hours a day.
Happy coding.
No comments:
Post a Comment