Week 1Day 1 - "Things need to change"
Meeting the Team
If you're already a seasoned version control user, you may want to skip this chapter.
It's kind of like an introduction to why we even need version control systems in the first place.
This chapter looks at Tamagoyaki Inc's requirements and why they choose the VCS that seemed right for them.
Tamagoyaki Inc. creates software for turning a standard PC into a media center.
Their product ships to the end user and they rely very heavily on having a good presence at trade shows, in order to bring in sales.
The following conversation describes the events that led up to the defining "We need a VCS!" discussion.
In the trenches...
John sat at his desk and looked out of the window.
The rain was drizzling down the pane, but he didn't care.
It was a quiet Monday morning, the release had gone well on Friday and John was just thinking about implementing the new abstraction layer to the database he'd been asked for.
Through the music playing in his headphones he hardly noticed his boss, the chief designer and the CEO approaching his desk.
"John," shouted his boss, Markus, "get your team into the board room. Now!"
Things didn't look good.
* * *
"So, what we'd like to know John, is just how a bug that was supposed to have been..." the CEO back-tracked, "that was demonstrated as being fixed two weeks ago, made it into the final release of the software?"
"I'm sorry," John started, before being cut off.
"Sorry doesn't cut it John," said the CEO, Wayne Tobi,
"This was almost a major embarrassment for Tamagoyaki Inc. and we need to ensure this doesn't happen again. The demonstration at the trade show was close to a complete failure. Luckily someone had the good sense to bring a backup machine."
He turned to Markus.
"I want a report on my desk by the end of the day that states what the problem was, how it slipped through our fingers and what safe guards we are going to put into place so that things like this never happen again."
"Of course sir," Markus replied.
He was bright red with his own variety of embarrassment.
The room fell silent and a few minutes of silence passed before the meeting was drawn to a close and John and his team were allowed to leave.
* * *
"So, you're telling me that when Simon came back from holiday, he picked up an older copy of the library from the network share and pushed his latest code into that?" Markus was holding back the anger.
"It appears that way." Said John sullenly.
"Oh for crying out loud. How did this happen? Why wasn't he using the latest version? And why didn't QA pick up on it?" Markus looked across the meeting room at John.
"John, you need to make sure this doesn't happen again. Find a solution!"
The trouble with storage
It's not like this situation is completely uncommon.
At one point or another most people have managed to pull old code from somewhere and mistakenly use it in place of the latest, up to date, version.
When storing code on network shares or on local disks, it's easy to lose sight of which version is which, no matter how good your naming convention is.
It's like trying to build one of the baked bean puzzles when you have three boxes of them and you tipped all the pieces into one box for simplicities sake.
Not so simple any more is it?
People have a tendency to use folder names which mean something to them.
However it doesn't necessarily follow that this name means something to another developer.
"Version 2.3 -- fixed bug a" only means something to you if you know what bug a is and something like "Version 2.3 -- fixed bug a(2)" is even worse.
Unfortunately allowing people to free form type their own descriptive file names will always lead to problems like this.
When these files are stored on a network share, the problem is exacerbated ten fold because there is often no fixed reference point.
So what's the solution? Well, in a large number of cases version control can make sure that not only is there a defined place for data to sit, and with a defined structure, but also that you have a full history of the code.
Accountability is very important in code development, especially when releasing software to customers.
In some situations a customer will even mandate that the code being developed for them is stored in a version controlled environment.
In this way, the customer can ask when a certain piece of code was edited, or when an addition first entered the code base.
|
