Last week all of us were baffled when suddenly one part of our application that uploads files to a FTP server stopped working. The strange thing was that the same build has been working without any issues for the past one week. We looked at everything that could have gone wrong, server, configuration, code but everything was setup fine and hadn't been changed. Also interestingly it stopped working for everyone except the developer who was responsible for the feature.
The first thing we did was to enable detailed logging to see what was happening, the logs showed two problems
- We were incorrectly formatting the path of file to upload
- The .Net framework code was changing folders after login to the root folder of the ftp where it didn't have permissions to upload the file
Further investigation showed that
the second issue was not coming on the developer's machine. Most puzzling indeed.
Then I remembered that last week .Net had issued a critical hotfix for .Net 2.0, could this be the issue. We verified that the developer didn't have the hotfix and all machines which were failing did have, Strike 1! Next we uninstalled the hotfix from one of the machines and the FTP uploads started working, Strike 2!! Finally we fixed the incorrect formatting of the ftp url and the issue got resolved on all machines with or without the hotfix, Strike 3! Issue resolved!
The problem was that the hotfix changed the implementation of the FTP code inside the .Net framework so that it behaved differently when passed an incorrectly formatted url.
This was the first time I saw a working app fail because of the way an incorrect argument was handled by a newer version of the framework. It was a good learning experience though :) Also this strengthens my belief in asserting all assumptions in code because if we had asserted that the url was infact of the format that we were expecting, this issue would never have happened in the first place.
I read a very interesting essay today - Hacknot - To Those About to Hack
that talks about why planning upfront always pays in the long run. There is a very nice story that illustrates the value of planning upfront.
I think that when people write essays like this they tend to provide an analogy that suits the point that they’re trying to make, for e.g. in this case Pro BDUF and Agile bashing.
There are a couple of reasons why the analogy is not quite relevant in this case. Firstly software is not like chopping wood, it’s not like construction infact any comparison that tries to compare software development with any kind of physical object creation is flawed. Physical objects have limitations with respect to the time and effort required to shape them or construct them. The values of these physical constants are irrelevant when it comes to software and in some cases the physical limitations do not exist at all.
Secondly the requirements in almost every software product that I’ve worked on always change after the initial code has been implemented, first because the customer/user is himself not very clear on what is required. It’s quite difficult to describe a large state machine for a CS grad let alone a layman. Also usability design itself is an iterative process for for a product with a UI the requirement churn rate is absurdly high when compared to any physical engineering activity.
So given that requirements are bound to change doesn’t it make sense to practice the one thing that you know for sure is going to happen i.e. change. No amount of planning is going to prepare you for change, you need to practice for change day in and day out by following the training regime of agile methods. TDD, pair programming, daily meetings, refactoring, rejection of BDUF etc. these things prepare the programmer for the inevitable.
I can imagine a version of the story that favors the Agile camp in which the carpenter in the middle of the day decides that he does not need a big log of wood at all! But the fact that wood chopping is a physical activity again prevents me from going ahead on that analogy.