The story of version 1.1

Once upon a time, a software project took around 7 months to get to version 1.0 . We didn’t have any problem all that time with our SVN (Subversion) repository as we didn’t have to release anytime before version 1.0 . we didn’t have any SVN strategy till that moment and all of us were happily committing to the trunk and enjoying a branching-less life.

The last 2 months before releasing version 1.0 were mainly focused on enhancing performance and bug fixing. we couldn’t stop at that point as we had many developers with nothing to do and more features waiting to be added to the next version. the work on the new features had to go in parallel with the code enhancements being applied to version 1.0 to get it released and ready to be deployed to production. we did create another branch for the 1.1 version.

Some of our developers started committing to the 1.1 branch while some others continued to commit to the trunk. then after 2 months of work, we wanted to release the 1.1 version. the plan was to merge the 1.1 branch into trunk, test it, fix bugs and then deploy that to production. things didn’t go that simple as we had very big code base and there were many differences between the 1.1 branch and the trunk. merging took more than a week and lots of bugs that were fixed before in the trunk, came back to life with more new bugs that had to be fixed as fast as possible to get the 1.1 version released and deployed to production.

The bug fixing phase took more than what was expected and our product team (who were playing the rule of the owner in our little software development game) had a plan with lots of features that had to be completed before the end of year and they didn’t want to stop the development of new features till we finish fixing all the bugs.

They gave us a plan for the rest of the year and they wanted to change our release strategy so we release and deploy to production at the end of every week. this was a kinda good strategy for our kind of business. the problem was that we still didn’t have a stable code base that we were sure that we can build on. we had lots of fatal bugs waiting to be fixed and we didn’t yet release version 1.1 .

Anyway, we started working on the features of the first week of the plan. while the amount of features was more than what can be finished in one week, we couldn’t finish the features in less than 10 days. this left us behind the plan by some days and we didn’t have enough time yet to fix the bugs of version 1.1 . we were pushed more to start working on the planned features for the second week. that week had more complicated features and it took us 2 weeks to finish it.

At that moment we had all that code in the trunk with lots of new implemented features and more bugs. we didn’t release anything in the previous 3 months (since version 1.0) . the project didn’t benefit of the new features. every team is blaming the other for making things go like that. the product team had more plans and features to be implemented till the end of year. the development team can’t make a new release with all those bugs.

that’s not the end of the story, but I have to stop here and start analyzing what happened. mainly, I see 2 problems.

First, the development team was committing all the code directly into the trunk. we would have created a branch for each feature. this way each feature will stay isolated with all its bugs and then when it’s stable, we can merge the branch into the trunk. this will keep the trunk always ready for deployment at any moment.

like what Mr.Radwan say, “your main code base is gold, you can’t mix it with rubbish code”. this way we can keep our gold in the trunk always ready for deployment and we can keep history of each release in a tag with the right label.

branching in source control systems

Second, the product team shouldn’t have continued requesting new features while there were many bugs not fixed and while they can’t release the finished features. they should have stopped till the development team can get all the bugs fixed and then they can meet with the development team to see how they can stop the problem from appearing again in the future.

software development isn’t that simple and not respecting this craft can turn a project into a big failure. problems in projects like that doesn’t appear just over night, people are the main reason of the problems. if you can’t control all the participants and keep them focused on what they should do, they will start behaving the way they like and will start fighting each other instead of collaborating. if they were focused, they would have noticed that the project is shifting from the right way and they would have started early to fix this.