I spent a pleasant amount of time today looking into whether I want to replace my personal CVS version control with SVN. Subversion, you may know, is the much touted Open Source Solution to Version Control, burying CVS in features and so forth. This led to research about the truths of the matter (SVN looks good enough for me to give it a try - I do love my TortoiseCVS, but I'll try out TortoiseSVN), which led to the "standard" repository layout.
Now, I've been developing for long enough to recognize a "standard" repository by now, and I've seen enough to know that I haven't seen a standard. Done some work to improve the repositories I work with, both personally and on a team, but I hadn't given it much thought beyond that. Well, here it is:
/project
/project/trunk
/project/branches
/project/tags
What were you expecting, magic?
Failed Similes
Basically, this layout addresses life-cycles of projects. When a baby project is just being grown, of course we want protect it as much as possible. This means using source control. When something bad happens to the baby, we can just back up and restore the healthy child. If only real life were so simple!
When the baby becomes an adult, we typically want to release him into the wild. This "release" is something we want to hold on to. After all, people might come back and say the kid has some problem, like 4 fingers when he should have 5. We want to be able to fix those problems. On the other hand, we also want the kid to grow more, do more things. Basically, we have a problem. In real life, the kid can't leave and stay at the same time. Fortunately, software is not a kid, and the analogy holds no water. Like a prepositional phrase, it is out of here.
Like Elephants and Trees
What we want is to have two semi-related developments of the code: a release development, where we can address problems that users find and turn around with a patched version quickly, and an experimental version where we can try new things, throw out old things, and generally make a mess without worrying about John Q. Public.
Wait a second. The experimental version is kind of what the program was like before it was released, right? It didn't matter if this feature or that change broke everything, because Mr. Public hadn't seen anything yet. This experimental, playful (if you will) code state provides the core of everything else we wind up doing. It's where we say "what if" and see what happens. When good things happen, we turn it into a release. When bad things happen, we restore previous versions and move on. Since everything else stems from this, we'll call it the "trunk".
Of Streams and Rivulets
Release development typically results in a series of numbers. 1.0. 1.1. 1.2. 2.0. and so on. The 1.0 1.1 1.2 series is frequently a series of small changes. We found some bugs in the 1.0 code, so we fixed it and called that 1.1. We added a feature to that and released it, calling it 1.2 This is similar to the trunk, because we're taking a root and building on it. But it's different, too. We don't necessarily want these changes in the trunk, for one thing. (Of course, we might. That's what merging is for.) For another thing, it's not as playful. We need to have more certainty that we didn't break any of Mr. Public's expectations, no new bugs.
These are our "branches". By keeping them separate from the trunk, we can freely develop both at any time. We can even branch branches. Years later, when our trunk has wandered so far from our branches that we'd never know they were the same, we can still return to those branches to maintain and enhance them.
Frozen in Time
So far we have lots of growing things, quite the populous plant. Theoretically, we can get to every version of the code in the trunk and all the branches, and they can all grow independently of each other. But there's the practical side, too. We want to get to 1.1. Here we leave our forest discussion and invent a "tag".
A tag is a moment in code history. In development, there is a time when we say to each other: "Now. Now is when we release this code upon the world. Now is when it is ready." We nod knowingly. This is a big moment, and we may need to get back to it later. Here we tag the branch that is ready; we name it for the great out side; we call it "1.0". And we tag it, "1.0".
Later, we can come back to 1.0, fix those bugs, add those features, then tag and release "1.1". Tags are our ticket back to the past. Those four letters contain a flux capacitor, and we can see Doc's smile.
Are Magic
Now we know why the layout is standard. Well, it's not "standard", but it certainly seems to make sense. We know where our trunk development goes, we know where our branch development goes, and we can see where our tags go. Of course, the exact folder names and placement aren't quite as important as the ideas. We want to make our jobs as easy as possible; keeping these three concepts separate and clear does just that. So, when we see the layout:
/project
/project/trunk
/project/branches
/project/tags
we are seeing a little bit of magic.
Thursday, March 01, 2007
Tuesday, January 23, 2007
Book Review: Balancing Agility and Discipline
Recently I finished reading Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm and Richard Turner. It's the first book I've read that attempts to find a logical middle ground among all the hollering from Agile Zealots, CMM Traditionalists, and the Process Atheists. It's aimed at those interested in their development team, whether developer, task leader, or manager, and describes some of the pros and cons of Agile methods (such as XP and Scrum) and more traditional "Discipline" methods (such as RUP and TSP/PSP). Additionally, the book takes a reasonable stab at how to roll our own process.
Is it useful? Yes, but under certain caveats.
McProcess: Prepared for Convenience
The project must be willing to accept that growing their own process will be measurably better than using a "prepackaged" process. In my experience, this is not the case. Most of the time, people want the packaged solutions: all the rules and procedures are defined, it is easy to see how much of the process is really being used, and they are easy to talk about (they have a name . Like a box dinner, organizations just want to stick a process in and go. In contrast, preparing their own process implies work - deciding on individual rules and procedures, trying to determine how much can and should be used, probably getting input from all levels in the organization. There's not even a name to attach to the process.
Employee Diet
The project must have available people experiences in many different processes, and be able to judge how this or that practice will be taken by the engineers who will use them. This will help decide how much training is required to implement various practices. For example, if we want to start using pair programming, but no one in our company has ever done it, we may have to devote real resources into getting that practice started and accepted. It will be much worse if we have engineers who are experiences in pair programming, but hate it.
Chapter breakdown
Chapter 1 introduces the problem domain: software is hard, people don't understand how to make it. Disciplined methods, ala waterfall, originally proposed to solve problems by taking techniques from classic engineering. Unfortunately, that didn't work. Agile methods, developed in response to "failings" in Disciplined methods, took a less regimented approach to development, but, alas, also failed to make everyone happy. Clearly, there must be another way.
Chapter 2 gets into the mud a little and talks specifics. Both Agile methods and Disciplined methods have a "Home Ground", or characteristics that help the process succeed. These characteristics include personnel counts and skills, requirements stability, development culture, and ultimate project failure costs (lives, money, comforts).
Chapter 3 describes normal and "crisis" days for both Agile and Disciplined methods, from arrival to departure of the development and management teams. We get to see some of the style of interactions between team members for both types of methods.
Chapter 4 takes case studies for Agile and Disciplined processes. It points out where the processes failed and how these failures might be handled.
Chapter 5 proposes a method to roll our own process. Examining the risk of using one approach versus the risk of not using it can be very informative. We can rate our projects on the "Home Ground" scales and see whether they call solidly into Agile or Disciplined methods, and take steps accordingly. Most importantly, the book acknowledges we can pick and choose what pieces work for us. We can build a process from other processes, custom tailored for our project.
Finally, chapter 6 summarizes the book. Neither Agile methods nor Disciplined methods will magically solve problems; developers and management still has to use some thought to decide what process styles they should adopt. It seems to be better to make our own process from process pieces rather than take a process and trim it down.
Obey your Thirst
Ultimately, I think this technique best benefits the rare project that is interested in improving their process, but has noticed that nothing really seems to be working. The book itself has much broader range of use - any project team just getting underway will find a set of considerations in the portions of the book about "home ground", and it is certainly refreshing to read about process, agility, and iterative development without any resorting to fat-jokes.
Is it useful? Yes, but under certain caveats.
McProcess: Prepared for Convenience
The project must be willing to accept that growing their own process will be measurably better than using a "prepackaged" process. In my experience, this is not the case. Most of the time, people want the packaged solutions: all the rules and procedures are defined, it is easy to see how much of the process is really being used, and they are easy to talk about (they have a name . Like a box dinner, organizations just want to stick a process in and go. In contrast, preparing their own process implies work - deciding on individual rules and procedures, trying to determine how much can and should be used, probably getting input from all levels in the organization. There's not even a name to attach to the process.
Employee Diet
The project must have available people experiences in many different processes, and be able to judge how this or that practice will be taken by the engineers who will use them. This will help decide how much training is required to implement various practices. For example, if we want to start using pair programming, but no one in our company has ever done it, we may have to devote real resources into getting that practice started and accepted. It will be much worse if we have engineers who are experiences in pair programming, but hate it.
Chapter breakdown
Chapter 1 introduces the problem domain: software is hard, people don't understand how to make it. Disciplined methods, ala waterfall, originally proposed to solve problems by taking techniques from classic engineering. Unfortunately, that didn't work. Agile methods, developed in response to "failings" in Disciplined methods, took a less regimented approach to development, but, alas, also failed to make everyone happy. Clearly, there must be another way.
Chapter 2 gets into the mud a little and talks specifics. Both Agile methods and Disciplined methods have a "Home Ground", or characteristics that help the process succeed. These characteristics include personnel counts and skills, requirements stability, development culture, and ultimate project failure costs (lives, money, comforts).
Chapter 3 describes normal and "crisis" days for both Agile and Disciplined methods, from arrival to departure of the development and management teams. We get to see some of the style of interactions between team members for both types of methods.
Chapter 4 takes case studies for Agile and Disciplined processes. It points out where the processes failed and how these failures might be handled.
Chapter 5 proposes a method to roll our own process. Examining the risk of using one approach versus the risk of not using it can be very informative. We can rate our projects on the "Home Ground" scales and see whether they call solidly into Agile or Disciplined methods, and take steps accordingly. Most importantly, the book acknowledges we can pick and choose what pieces work for us. We can build a process from other processes, custom tailored for our project.
Finally, chapter 6 summarizes the book. Neither Agile methods nor Disciplined methods will magically solve problems; developers and management still has to use some thought to decide what process styles they should adopt. It seems to be better to make our own process from process pieces rather than take a process and trim it down.
Obey your Thirst
Ultimately, I think this technique best benefits the rare project that is interested in improving their process, but has noticed that nothing really seems to be working. The book itself has much broader range of use - any project team just getting underway will find a set of considerations in the portions of the book about "home ground", and it is certainly refreshing to read about process, agility, and iterative development without any resorting to fat-jokes.
Subscribe to:
Posts (Atom)