There is a lot that I can say about staffing a startup technology company. I'm finding it difficult to narrow it down to the short few paragraphs that I'll present here in this blog post. Let me put it this way: technical ability is not the only factor that goes into the equation.
I am energized in a startup environment. The intense atmosphere charges me up - every second of everyday is filled with excitement. My team and I are required to put forth 100%. We think on our feet, design for anticipated feedback, create and recreate processes that enhance our efficiency and so much more. This workday can be exhilarating to the right person just as it can be pain to others. To create a vibrant team that is capable of meeting the significant challenges that face a startup tech company I always look further than technical skills.
Someone with an Axe to Grind or Something to Prove or who is just plain HUNGRY is a good place to start. I like to find candidates who are excited that they will get to take on so much more responsibility at a startup than they would be allowed at a larger company. So a person who feels that they can do things better and wants a chance to prove it may be ideal.
Now I am sure you can imagine that this may be creating a powder keg. Think about it, a room (usually a cheap one) filled with highly skilled techies that are striving to do great things. Well, defusing any potential explosions and channeling that energy into a positive direction that drives product creation is your job. Thats where your teambuilding skills come in. But you need the talent first - the right talent.
Cheers,
Brian
http://brianleblanc.net
Friday, October 1, 2010
Wednesday, August 18, 2010
Burn the Boats!
I think many of us have heard the legend of Hernando Cortez and how he captured the amazing wealth from Mexico that had so long evaded other European conquerers. If not, you can read all about it here: http://www.tonybrownonline.com/rts/index.asp?action=page&name=16525&siteid=1421
The main thrust of the story is that if you leave an avenue of escape open to yourself than you will not fight as hard for your prize. “Make or break”; “Plunder or parish”; “Do or die”. This is the message that Cortez sent to his men when he said “Burn the boats! Because if we're going home, we're going home in their boats!”
How do you think Cortez's men felt? They were facing a challenge that no one had succeeded at before. In fact, there was overwhelming proof that they were going to fail because so many had before. They were going to succeed or die. Now, how would they have felt if they had known that the boats were offshore waiting to take them home safely? Maybe a risky battle move would not be tried? Maybe they wouldn't give 110%? I think we all get it. Cortez knew what he wanted and knew he wouldn't get it if he and his men were left a safe getaway.
How does the Cortez legend apply to startup management? It is the single-most important energy for you and your team to embody for success.
How do you get that feeling? Well, for starters, how about investing everything that you have? If you know that you face financial ruin if you fail to deliver a product to market, how will you behave? Will you stay up late? Will you forgo the upgraded TV to keep afloat a bit longer? IMPORTANT: will you be extra choosy about who you hire into your company? Lets talk about that one for a moment. If your savings depended on who you hired wouldn't you want to hire in those who would work hard like you will?
What else about those that we hire? If Cortez was the only one who couldn't get back on the boat would he have only burned his? NO WAY. He burned everybody's boat. You must create a situation where all participants feel invested and you only want those that will fight to the end. Partial ownership is one way. Ownership gives a great incentive for victory, though you still have to be careful because if someone doesn't believe in the cause they could just be there for the paycheck. Another way is separation.
Is your endeavor an effort for a larger company? Are the engineers employees of the larger company? Break the ties. Move locations. Make everyone uncomfortable. “This is our new office. It is small and dingy. This is what we are affording to stay open. If we don't hit each and every milestone with quality these doors may be locked the next time you show up for work.” Who would want to work in this atmosphere and with this kind of pressure? I do! And so do many others.
Startups are cool! We get to do things and take responsibilities that larger companies don't always allow. It is fast paced and exciting. There is an element of danger. Some people thrive on this. A lot of folks don't. Pick your crew well, inspire them with the promise of shared wealth, and BURN THE BOATS!
The main thrust of the story is that if you leave an avenue of escape open to yourself than you will not fight as hard for your prize. “Make or break”; “Plunder or parish”; “Do or die”. This is the message that Cortez sent to his men when he said “Burn the boats! Because if we're going home, we're going home in their boats!”
How do you think Cortez's men felt? They were facing a challenge that no one had succeeded at before. In fact, there was overwhelming proof that they were going to fail because so many had before. They were going to succeed or die. Now, how would they have felt if they had known that the boats were offshore waiting to take them home safely? Maybe a risky battle move would not be tried? Maybe they wouldn't give 110%? I think we all get it. Cortez knew what he wanted and knew he wouldn't get it if he and his men were left a safe getaway.
How does the Cortez legend apply to startup management? It is the single-most important energy for you and your team to embody for success.
How do you get that feeling? Well, for starters, how about investing everything that you have? If you know that you face financial ruin if you fail to deliver a product to market, how will you behave? Will you stay up late? Will you forgo the upgraded TV to keep afloat a bit longer? IMPORTANT: will you be extra choosy about who you hire into your company? Lets talk about that one for a moment. If your savings depended on who you hired wouldn't you want to hire in those who would work hard like you will?
What else about those that we hire? If Cortez was the only one who couldn't get back on the boat would he have only burned his? NO WAY. He burned everybody's boat. You must create a situation where all participants feel invested and you only want those that will fight to the end. Partial ownership is one way. Ownership gives a great incentive for victory, though you still have to be careful because if someone doesn't believe in the cause they could just be there for the paycheck. Another way is separation.
Is your endeavor an effort for a larger company? Are the engineers employees of the larger company? Break the ties. Move locations. Make everyone uncomfortable. “This is our new office. It is small and dingy. This is what we are affording to stay open. If we don't hit each and every milestone with quality these doors may be locked the next time you show up for work.” Who would want to work in this atmosphere and with this kind of pressure? I do! And so do many others.
Startups are cool! We get to do things and take responsibilities that larger companies don't always allow. It is fast paced and exciting. There is an element of danger. Some people thrive on this. A lot of folks don't. Pick your crew well, inspire them with the promise of shared wealth, and BURN THE BOATS!
Thursday, February 11, 2010
Great Expectations
These days it is difficult to ignore the benefits of offshore development. The potential cost reduction's beneficial effect on a company's profit margin warrants investigation. I am sure a lot of readers are thinking that this is old news, yet I feel that there is significant room for innovation in this model that will make it even more attractive to those who have not tapped these resources for whatever reason.
My experience is mainly with companies based in India. Over the years I have had varied success but on the whole it has been positive. Keep that in mind, because the sheer volume of teams vying for your business is more than overwhelming. They are persistent and tireless in pursuit of your projects and as you would guess, many make promises that they cannot keep. The important part is to have a plan and go into the endeavor with realistic expectations. “Too good to be true” is a sound rule here.
Some ways that you can raise your chances for success with your software project is to use the commonsense methodologies that you would use in any other instance where you are evaluating an unknown.
The first thing to do is to be specific about what you want. If you have technological constraints be clear in your solicitation that you only want to hear from companies that have significant and relevant experience. If you haven't decided on technology (say Ruby on Google App Engine vs. .NET on Azure) ask for a company that has done project work closely related to the functionality that you wish to develop/enhance. If you know both of these, ask to only hear from those that fit the bill in totality. Remember, there are so many offshore development shops that you have a very good chance of finding more than a few that will meet both criteria.
After you have found a few companies to consider, ask for pricing. This varies widely. There are larger (less risky) shops that charge more. You'll find a that with the more established company the benefit to you is the savings on infrastructure and employee services. These shops usually not only charge significantly higher rates, but they have team size quotas and require deep contractual agreements. The smaller companies usually provide the best deal financially, but you have to be on your game in the evaluation period.
When you have boiled down the competition then it is time to do exactly what you would expect, ask for demos of their work that directly relates to the functionality that you wish to build. And then ask for the contact information. Speak to the client that they built it for. Not only must your potential resource be technically apt, but they must be manageable and accountable. Ask the reference your operational questions. They must be able to produce “local” references. I have found that these references are usually very forthcoming in their critiques.
Now it is time to work on you. What do you expect?
From my experience I expect that I can enhance my chances for success by implementing a model where my trusted local team provides detailed technical documentation and that we schedule the resources ourselves. The more specific we can be about not only the look and feel, but how to implement technically the better the results. This model necessitates a local architect. However, if you were to go the 100% offshore resource model, then I would ask you to be sure to continue to provide impeccable functional specifications (painfully detailed) and insist on technical documentation back that could win a Pulitzer Prize.
This is a lot of commonsense advice. The benefit to hearing it though is that it may help to counteract the many sales pitches that a newcomer to off shoring will receive. You may be promised the world at an unbelievably low price, but to take it at face value may put you in a situation where you are disappointed and your effort is endangered. While I have provided some of the steps that will help you create a successful relationship, nothing replaces experience. Working with someone that has gone through this process before will help ensure your expectations. Not only does an experienced offshore manager enable the day-to-day, but they better understand the culture and can provide valuable contacts with trustworthy sources.
So good luck with your team setup. I am always excited about global resources and the technology that enables us to benefit our bottom line while enhancing someone else's standard of living.
Best wishes,
Brian
My experience is mainly with companies based in India. Over the years I have had varied success but on the whole it has been positive. Keep that in mind, because the sheer volume of teams vying for your business is more than overwhelming. They are persistent and tireless in pursuit of your projects and as you would guess, many make promises that they cannot keep. The important part is to have a plan and go into the endeavor with realistic expectations. “Too good to be true” is a sound rule here.
Some ways that you can raise your chances for success with your software project is to use the commonsense methodologies that you would use in any other instance where you are evaluating an unknown.
The first thing to do is to be specific about what you want. If you have technological constraints be clear in your solicitation that you only want to hear from companies that have significant and relevant experience. If you haven't decided on technology (say Ruby on Google App Engine vs. .NET on Azure) ask for a company that has done project work closely related to the functionality that you wish to develop/enhance. If you know both of these, ask to only hear from those that fit the bill in totality. Remember, there are so many offshore development shops that you have a very good chance of finding more than a few that will meet both criteria.
After you have found a few companies to consider, ask for pricing. This varies widely. There are larger (less risky) shops that charge more. You'll find a that with the more established company the benefit to you is the savings on infrastructure and employee services. These shops usually not only charge significantly higher rates, but they have team size quotas and require deep contractual agreements. The smaller companies usually provide the best deal financially, but you have to be on your game in the evaluation period.
When you have boiled down the competition then it is time to do exactly what you would expect, ask for demos of their work that directly relates to the functionality that you wish to build. And then ask for the contact information. Speak to the client that they built it for. Not only must your potential resource be technically apt, but they must be manageable and accountable. Ask the reference your operational questions. They must be able to produce “local” references. I have found that these references are usually very forthcoming in their critiques.
Now it is time to work on you. What do you expect?
From my experience I expect that I can enhance my chances for success by implementing a model where my trusted local team provides detailed technical documentation and that we schedule the resources ourselves. The more specific we can be about not only the look and feel, but how to implement technically the better the results. This model necessitates a local architect. However, if you were to go the 100% offshore resource model, then I would ask you to be sure to continue to provide impeccable functional specifications (painfully detailed) and insist on technical documentation back that could win a Pulitzer Prize.
This is a lot of commonsense advice. The benefit to hearing it though is that it may help to counteract the many sales pitches that a newcomer to off shoring will receive. You may be promised the world at an unbelievably low price, but to take it at face value may put you in a situation where you are disappointed and your effort is endangered. While I have provided some of the steps that will help you create a successful relationship, nothing replaces experience. Working with someone that has gone through this process before will help ensure your expectations. Not only does an experienced offshore manager enable the day-to-day, but they better understand the culture and can provide valuable contacts with trustworthy sources.
So good luck with your team setup. I am always excited about global resources and the technology that enables us to benefit our bottom line while enhancing someone else's standard of living.
Best wishes,
Brian
Monday, February 1, 2010
What's your group mindset?
I've been reading Mindset by Carol Dweck, Ph.D. This is her take on the psychology of success. It deals with what she calls a “fixed mindset” and a “growth mindset”. A major theme in this book is that those of us who have the growth mindset embrace challenges (and even failures) as an exciting way to learn. She explains that people who believe that they have the capacity to become more intelligent look for ways to learn new things and therefore DO become smarter. On the reverse side of this coin are those who live with a fixed mindset. Here she believes live the people who have bought into the belief that your IQ is static. They spend a lot of energy proving their worth time and again attempting to seem smart and avoiding situations where they are challenged. After reading through a good portion of this, I began to reflect back on how this applies in a startup technology company. Can an organization have a collective mindset? I say yes.
Going into a startup technology endeavor (I'll say software because that is what I do) a battle scarred vet is going to know that no matter how well the upfront planning was done, unexpected challenges loom around many corners waiting to derail even the best efforts. Now, top-notch technical specifications is one of the ways to reduce the risk and therefore the impact of these “unknowns”, but there will still be some and how the team deals responds to them builds the development culture.
Applying Dweck's theory it is plain to see that the group has the choice to view the challenges as a way to learn or as another roadblock on their way to success. What example will the team lead set? Here is my hope: that early on the manager rubs his/her hands together and says“ahhh, here is an opportunity for us to increase our knowledge base, gauge the amount of time necessary for unknowns, and prove our expertise as a team”. What I mean here is a) solve a problem once and it is solved forever if a short article up on the team wiki b) time how long it takes to resolve the issue and use that factor in development estimates going forward (keep revising this as the team gets better at it). Here is a wonderful metric for evaluating the team. c) Show off! It is a good feather in the group's cap that they were hit with undocumented technical challenges and only took x amount of time to overcome them. This approach/attitude is one of the building blocks to creating an exciting team that thrives in the often unknown technical environment of a startup.
For brevity's sake, I presented just the positive side of the argument. I think we can all see what kind of group is built with a fixed mindset. I am encouraged to reinvigorate my own attitude this week when the inevitable challenge arises. I think my phrase will be “Oh! Good, this is a cool issue to work on. Who is lucky enough to spend some cycles puzzling on this one?”
Good luck,
Brian
Going into a startup technology endeavor (I'll say software because that is what I do) a battle scarred vet is going to know that no matter how well the upfront planning was done, unexpected challenges loom around many corners waiting to derail even the best efforts. Now, top-notch technical specifications is one of the ways to reduce the risk and therefore the impact of these “unknowns”, but there will still be some and how the team deals responds to them builds the development culture.
Applying Dweck's theory it is plain to see that the group has the choice to view the challenges as a way to learn or as another roadblock on their way to success. What example will the team lead set? Here is my hope: that early on the manager rubs his/her hands together and says“ahhh, here is an opportunity for us to increase our knowledge base, gauge the amount of time necessary for unknowns, and prove our expertise as a team”. What I mean here is a) solve a problem once and it is solved forever if a short article up on the team wiki b) time how long it takes to resolve the issue and use that factor in development estimates going forward (keep revising this as the team gets better at it). Here is a wonderful metric for evaluating the team. c) Show off! It is a good feather in the group's cap that they were hit with undocumented technical challenges and only took x amount of time to overcome them. This approach/attitude is one of the building blocks to creating an exciting team that thrives in the often unknown technical environment of a startup.
For brevity's sake, I presented just the positive side of the argument. I think we can all see what kind of group is built with a fixed mindset. I am encouraged to reinvigorate my own attitude this week when the inevitable challenge arises. I think my phrase will be “Oh! Good, this is a cool issue to work on. Who is lucky enough to spend some cycles puzzling on this one?”
Good luck,
Brian
Monday, January 25, 2010
Inter-release scheduling
It takes a special person to lead a start up team. They must enjoy challenges that others may find just too frustrating for words. But it is in this daily 'point - counter point' that the true start up manager thrives. A good example of this theme is what all engineering teams face in the beginning: many high-priority feature requests and a skeleton crew of resources to implement them. Lets call this resource constraint.
Resource constraint is dealt with in many different ways. One way that can be effective is to create a hybrid development model that leverages less expensive off-shore developers to supplement your local team. I plan to talk more about this model in another note, but for now I want to focus on how to make sense of multiple development efforts being run concurrently.
Because a startup is aggressively seeking to become a self-sustainable entity, any sale is treated with the highest level of criticality. So as we methodically move forward, implementing our vision of the perfect software product, we are bombarded with requests from potential sales. To an outsider, the view of the functionality in development may seem disjointed, but we all know that these pieces must be built in quickly to generate sales. On the other hand, we have a team of developers with a variety of skills. You'll see that it really becomes a puzzle of organizing projects based on when the right resource will be available versus architectural priority (i.e. this functionality must be built in to allow that functionality).
I have found one way to achieve a smoothly running team in such an environment is to create inter-release schedules. What I mean by this is schedules that are based on functionality rather than a specific deliverable. First, break the plan up by functional requirement (imagine all of the tasks for Outlook Integration v1 grouped together, then a blank line, and then the tasks for Next Phase of Reporting). Maybe Outlook Integration will be in the next release, but Reporting is not, but having it on the schedule will allow for always making the best use of your resources time. For instance if Dev A completes a task and cannot move onto the next task in that functional area until Dev B completes some supporting tasks, then you can move them onto their part of feature development elsewhere.
I think that you can see that there is a lot more finesse to this than I am able to go into here, but there are a few of you that see the fun. To those readers (that see the fun) I want to say: realize that others see this as a frustrating chore while you see a chess game. Obviously you have to have a well thought out branching scheme in source control. You must know your developers strengths. Also you have to have built a bonded team that respects you and will take direction. Finally you must balance resource reallocation so that it does not become overly tiresome on your team. There is more, but you get the idea.
Cheers,
Brian
Resource constraint is dealt with in many different ways. One way that can be effective is to create a hybrid development model that leverages less expensive off-shore developers to supplement your local team. I plan to talk more about this model in another note, but for now I want to focus on how to make sense of multiple development efforts being run concurrently.
Because a startup is aggressively seeking to become a self-sustainable entity, any sale is treated with the highest level of criticality. So as we methodically move forward, implementing our vision of the perfect software product, we are bombarded with requests from potential sales. To an outsider, the view of the functionality in development may seem disjointed, but we all know that these pieces must be built in quickly to generate sales. On the other hand, we have a team of developers with a variety of skills. You'll see that it really becomes a puzzle of organizing projects based on when the right resource will be available versus architectural priority (i.e. this functionality must be built in to allow that functionality).
I have found one way to achieve a smoothly running team in such an environment is to create inter-release schedules. What I mean by this is schedules that are based on functionality rather than a specific deliverable. First, break the plan up by functional requirement (imagine all of the tasks for Outlook Integration v1 grouped together, then a blank line, and then the tasks for Next Phase of Reporting). Maybe Outlook Integration will be in the next release, but Reporting is not, but having it on the schedule will allow for always making the best use of your resources time. For instance if Dev A completes a task and cannot move onto the next task in that functional area until Dev B completes some supporting tasks, then you can move them onto their part of feature development elsewhere.
I think that you can see that there is a lot more finesse to this than I am able to go into here, but there are a few of you that see the fun. To those readers (that see the fun) I want to say: realize that others see this as a frustrating chore while you see a chess game. Obviously you have to have a well thought out branching scheme in source control. You must know your developers strengths. Also you have to have built a bonded team that respects you and will take direction. Finally you must balance resource reallocation so that it does not become overly tiresome on your team. There is more, but you get the idea.
Cheers,
Brian
Wednesday, January 6, 2010
The Fast & The Furious: Process
The enjoyment that I have found in effecting turn-arounds in both operational and development environments comes from bringing order to chaos. I think it is fun to take charge of something that is broken and fix it. It's about the love of putting things in order (or is it the "need" to put things in order?). This usually takes the form of establishing new and efficient processes, documenting them and then training personnel in their use. There is a lot of work that goes into the last sentence (things I didn't even hint at), but as I said it can be a lot of fun and extremely rewarding.
Working a start-up company can present some of the same challenges and opportunities for "fun", but there are also some key differences. With no established procedures to work with, there is a clean slate on which to make your informed sensible decisions. There are no bad habits to break or mysteries to be solved, it is all about understanding the goals of this new venture and then customizing a successful template that you feel best suits the situation at hand. So again we find "establishing new and efficient processes, documenting them and then training personnel on their use".
One difference in crafting a turn-around at an established company and manning a start-up is the post implementation of your plan. For a turn-around the win is not only to bring the environment to a pre-defined level of achievement, but to implement a continuous improvement plan based on metrics. The procedures that were put into place need to be made up of measurable tasks which provide the metrics necessary for ongoing improvement. This is the hard part - the constant monitoring of the machine and then making the minute adjustments that increase efficiency. In a start-up this task is 100 times more difficult.
The best laid plans of mice and men, right? The ground is never too firm at a start-up, there are just too many variables. What I call "infrastructure processes" are established, providing the stability necessary for the team to move forward. Over time however factors such as the economy, new technology, governmental policy, and input from investors will have an effect on a company's goals and therefore the processes. This effect is amplified for a start-up. Flexibility must be king if the organization is to adapt. This is a different kind of fun.
In a start-up the ground may quake beneath your feet much more frequently and with more volatility. It may not be enough to make minute changes - the whole play book can suddenly be called into question. In conceiving an initial plan, the leader's job is to not only assess the new venture's goals and vision but to then weigh the risk factors that may adversely effect their efforts. For instance, what is the probability that a key governmental policy that is critical to the business will change? With this decision analysis having been done, the best plan for the organization can be established. However, a prudent leader will then staff the new enterprise with energetic and flexible personnel that can weather the exciting and challenging tasks in this fast and furious environment.
~Brian
http://brianleblanc.net
Working a start-up company can present some of the same challenges and opportunities for "fun", but there are also some key differences. With no established procedures to work with, there is a clean slate on which to make your informed sensible decisions. There are no bad habits to break or mysteries to be solved, it is all about understanding the goals of this new venture and then customizing a successful template that you feel best suits the situation at hand. So again we find "establishing new and efficient processes, documenting them and then training personnel on their use".
One difference in crafting a turn-around at an established company and manning a start-up is the post implementation of your plan. For a turn-around the win is not only to bring the environment to a pre-defined level of achievement, but to implement a continuous improvement plan based on metrics. The procedures that were put into place need to be made up of measurable tasks which provide the metrics necessary for ongoing improvement. This is the hard part - the constant monitoring of the machine and then making the minute adjustments that increase efficiency. In a start-up this task is 100 times more difficult.
The best laid plans of mice and men, right? The ground is never too firm at a start-up, there are just too many variables. What I call "infrastructure processes" are established, providing the stability necessary for the team to move forward. Over time however factors such as the economy, new technology, governmental policy, and input from investors will have an effect on a company's goals and therefore the processes. This effect is amplified for a start-up. Flexibility must be king if the organization is to adapt. This is a different kind of fun.
In a start-up the ground may quake beneath your feet much more frequently and with more volatility. It may not be enough to make minute changes - the whole play book can suddenly be called into question. In conceiving an initial plan, the leader's job is to not only assess the new venture's goals and vision but to then weigh the risk factors that may adversely effect their efforts. For instance, what is the probability that a key governmental policy that is critical to the business will change? With this decision analysis having been done, the best plan for the organization can be established. However, a prudent leader will then staff the new enterprise with energetic and flexible personnel that can weather the exciting and challenging tasks in this fast and furious environment.
~Brian
http://brianleblanc.net
Wednesday, December 23, 2009
Step 1 - You need source control
Starting or reorganizing a software development group from the ground up presents many challenges. Creating a group identity, staffing, infrastructure and operations will take endless amounts of time, consideration and then reconsideration. There are usually multiple solutions to any of these high level points and the hundreds of smaller tasks that make them up. The manager's experience and comfort with his/her past implementations should combine with the uniqueness of the current domain to guide them to the correct group implementation on which the development culture will be grown. With so many choices to make and avenues to be investigated any cut and dry decision saves valuable time and allows the manager to focus on the trickier implementation tasks. Source control is one of these slam dunk decisions.
As we all know a source control system could be argued to the top of the engineering necessity check list. It is not a nice to have but a must have. No serious development company can operate without a solution. "Which system is right for us?" becomes the question. A product that is scalable and offers flexibility must also be easy to use and solve the problems that we all found when we were using Source Safe. Finally, how much should be paid and how much time devoted to administration? I have found that the near perfect solution to all of these questions to be Subversion.
Subversion (SVN) started in '99, and was intended to replace CVS with an open source solution. It will secure your source code as well as your documentation. It supports branching and provides documentation on various implementation schemes that you can peruse prior to implementing a process. The latest version makes the merge process simpler and will help alleviate errors. Along with all of these features, SVN can be used via the command line, web or a desktop Explorer add-in "Tortoise". Finally, SVN integrates well with other bug tracking/wiki solutions like trac and jira.
So if you are looking to replace an existing source control system or implement a new one, I recommend that you check out SVN. You'll save money & time and get a robust solution that is easy to use.
Best of luck,
Brian
As we all know a source control system could be argued to the top of the engineering necessity check list. It is not a nice to have but a must have. No serious development company can operate without a solution. "Which system is right for us?" becomes the question. A product that is scalable and offers flexibility must also be easy to use and solve the problems that we all found when we were using Source Safe. Finally, how much should be paid and how much time devoted to administration? I have found that the near perfect solution to all of these questions to be Subversion.
Subversion (SVN) started in '99, and was intended to replace CVS with an open source solution. It will secure your source code as well as your documentation. It supports branching and provides documentation on various implementation schemes that you can peruse prior to implementing a process. The latest version makes the merge process simpler and will help alleviate errors. Along with all of these features, SVN can be used via the command line, web or a desktop Explorer add-in "Tortoise". Finally, SVN integrates well with other bug tracking/wiki solutions like trac and jira.
So if you are looking to replace an existing source control system or implement a new one, I recommend that you check out SVN. You'll save money & time and get a robust solution that is easy to use.
Best of luck,
Brian
Subscribe to:
Posts (Atom)