I have been on a tight schedule recently. We are late with the next software release. I told my team lead that any interruptions will cause further delays in the schedule. Luckily I have been able to eliminate most interruptions due to people needing my help. That is the usual drain of development time. However yesterday I found another stumbling block. The version of the code checked into source code control is broken.
You should never check in code that breaks the build. Sure nobody did this on purpose. However it affects me in a big way. I get the latest code checked out to make the changes for the software release. If the code I check out already does not compile, I am not going to be able to make much progress on my task.
From a casual inspection, it looks like there are two sources to the breakage. The first is that somebody made a lot of changes. But they did not check in all their files. So the build works locally on their machine. However the missing file updates cause compile issues on the source code control version. The other problem stems from the fact that we often make changes in the application that must coincide with database changes. It looks like the database changes are missing from the database against which the code compiles.
There must be a way to minimize these problems. We used to do nightly builds from the source code control version. That way we knew immediately when the code base was broke. Now it seems we don’t find out until somebody checks out some code and it does not work. Perhaps we should analyze the code and track down the guilty parties. Then we could do some evil things to them. This may minimize further disruptions.
Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...