Developing with Version Control using Dropbox?

At this point I will suppose that everybody knows what Dropbox is; otherwise I would suggest visiting its Wikipedia page to read more.

What is a version control? This does not make the purpose of the article either, but I will provide a brief introduction of what a version control can do:

    • tracks changes of your files
    • manages conflicts made by multiple changes of the same file by multiple developers
    • supports branching and merging (branching happens when you want to experiment (or work on a new feature) without affecting the main set of files)

Bryan Bradow, programmer at MicroStrategy, a leading worldwide provider of enterprise software platforms, wrote a really interesting blog post attesting the power of Dropbox as a version control system with the title “Developing with Version Control Using Dropbox”. Bryan argues this with the following statements:

  1. Dropbox is a little more subtle that regular Version Control Systems as Subversion or Git
  2. You don’t have to do anything as far as check in/ check out
  3. Never think about back-ups and any modification is synced and versioned

All of the above arguments I stand against in the following sections as they do not provide any reason for which Dropbox is to be used as a Version Control System.
I find it a little bit intriguing that a programmer can recommend Dropbox as a Version Control. Also many students confuse Dropbox to a version control system and frequently use it for individual university projects. Not once I have heard when starting a group programming assignment “Ok guys, I’ll start by sharing the Dropbox folder.”.

1. “A little more subtle that regular Version Control Systems as Subversion or Git”

By a little more subtle, Bryan probably refers to the inability of Dropbox to support merging or branching.

In the case of a small individual project these might not be needed, but under no circumstances these tools could miss when a bigger project is developed with multiple developers. The power of systems like Git and Subversion stands in their ability to branch projects and merge branches them at any given time. This way each individual developer can work on its particular part of code, without worrying about the work the others are doing.

Therefore, a system that does not support these two powerful tools cannot be considered as reliable for a programming project with multiple developers.

2. “You don’t have to do anything as far as check in/ check out”

Yes, I agree with this statement. You never have to check in or check out, but you can never save the state where you are to return to a past state of all your files project.

Let’s say you just finished the first part of your project. A reasonable choice would be to save the state of your project until that point and commit all changes in a version control system with a message probably saying “Part 1 completed and working”. This way you could always come back to this stage of the project if something goes wrong along the way.

If you were to use Dropbox, you would probably have to save the date and time when you finished “Part 1”. You would have all the versions of the files that you modified and you’d probably have to revert manually all the files in the project back to the last version close to the date and time when you finished. That really does not sound like a reasonable way of action. Dropbox is great when you have a number of documents/ photos/ presentations that need to be in sync on all your devices and that should be it.

In conclusion, the check in/ check out when this does not help you if you need to go back to a previous state in the way version control system would. It just saves your current progress.

3. “Never think about back-ups and any modification is synced and versioned”

Sound like a great plan, but what happens if you forget Dropbox turned off or something else happened? There can be days until you realize that your system did not back anything up.

Many times we have problems with the internet connection, either is the weak signal from the router or the small upload speed. Sometimes I tend to close the programs that stay connected and exchange information online every minute such as Dropbox, uTorrent, Google Drive, etc. . Not once I turned off Dropbox and then realized after a couple of days is not in sync, when I was trying to access a Dropbox folder from a remote computer.
Another plausible case is that your Dropbox application gives you an error and you have to turn it off. You could very easily forget to turn it on again and so the sync of your files would be done.

Do not try to make your life easily and “never think about back-ups”, something can always go wrong and it is better to realize it earlier than later. When you are using a Version Control System, every time that you commit something and push it to your repository you receive a confirmation that everything worked well and your files are save, this not being the case for Dropbox.


Using a Dropbox is definitely not a substitute for a version control system as I presented in the upper sections. Many programmers tend to use dropbox in addition to version control to keep their repositories up to date on all of their computers (home or work stations), but definitely not as a substitute for it. I definitely hope that in the future novice programmers will be taught earlier that there is no substitute to version control and stop using Dropbox as one sooner.

Response to “Agile Software Development in China”


This article is a response to Agile Software Development in China by s1314857.

In the article, the author presents an overview of what Agile Software Development means and some of its principles together with the challenges firms in China are facing to adopt this methodology.

The main point of this article is to challenge one of the author’s main statement about why Chinese software businesses did not adopt Agile Methodologies (“non-large scale companies do not implement standard methods“). I  will argue that small companies can easily adopt Agile and I will provide examples and methods to overcome the possible challenges. In the first sections I will also touch a little bit on the structure of the article and suggest some improvements.

First let’s start with the Introduction

Where is the Introduction? There is no introduction.

While the author starts with a good overview of what Agile Development means, I found it hard to find a structure of the article, struggling to find an introduction paragraph. Therefore, I did not know of whether it will talk about software companies that use Agile or maybe Agile methodology successfully implemented in China. Only after reading the 3rd section everything became clearer.

In conclusion, I really think that this article would have benefited from a better organization, by providing an introductory paragraph which would mirror the conclusion.

Where do the ideas come from?

While some of his arguments are well structured, there is little evidence that can support his statements, like: “Firstly, there are lots of software companies in China, but few of them are large-scale.” or “Some Chinese development teams prefer the cowboy coding, which is a term refers to go-as-you-please and unplanned coding style.”.

Arguments like these bring little value to the content of the article and make it seem that the article brings many ideas into play. Also I do not understand if the arguments come from personal experience or they comes from a specialized source, therefore it fails to convince the reader about how Chinese businesses actually work.

In conclusion I find it quite hard to argue his statements since I do not really know the source. It should have been specified whether the ideas in the article come from personal experience or from a reliable source like a book or survey over the Chinese software companies and what the challenges they encounter are.

Agile in Small Companies

I will continue this section by studying some of the challenges a small team might encounter when using Agile techniques, but how easy it would be to overcome them. By looking at the size of the team, the number of projects a team can have in a sprint and how they handle refactoring I will try to demonstrate how Agile can be incorporated in the culture of a small team.

Size of the Team

Ever since the launch of this methodology, Agile development has been seen to fit small teams of experts. A team of four or six developers can therefore work perfectly.

The main roles in an Agile team are: Team lead (also called “Scrum Master”, who is responsible for facilitating the team, obtaining resources and protecting it from problems), Team member (developer, which can include modelling, programming, testing, release activities, etc. ), Product owner (person responsible for the prioritized work item list).  Also having an even number of programmers facilitates pair programming, and having a meeting with the whole team might just involve turning around the chairs.

There is no success scheme into implementing Agile Methodologies and each of them cam be adapted to the size of the team while maintaining a number of self-motivated team members.

Too many projects competing for limited number of developers

Smaller teams of developers sometimes spend too much time swapping between projects (people are not like supercomputers to switch context whenever its needed with no effects), so the efficiency of the team could reduce.

A solution to this problem would be to shorten the sprint length (the time period between two deliveries), so that the sprint can concentrate only on one project at the time. Even though unexpected problems might arise, solving them could be easily added to the next sprint rather than interrupting the current focus, giving us an increase in the productivity and quality of the code. A simple Kanban board (a simple model consists of three columns: “to-do”, “in progress”, “done”)  can also be used so that the team  to impose the constraints on the work that the developers are doing (limiting the work-in progress), so they do not do unplanned work.

In conclusion, there need to be some sort of compromises in regards to the amount of work a team undertakes during a certain sprint in order to keep the efficiency and productivity of the team to the maximum.

Refactoring older code

Time for deep refactoring is sometimes lacking in small teams that have many projects, although this is crucial in a Test-Driven Development approach and maintaining a clean code database.

This is where pair programming comes into help, having two sets of eyes on every ticket reduces the time for refactoring, this way developers help each other by talking about what kind of tests to write and go on for a better start. One problem that refactoring is addressing is about functionality that is never used and makes the code unreadable. By pairing the problem can easily be addressed and it is more likely to build in scope.

Many mistakes are caught as they are typed, pair programming encouraging code review.  This way refactoring can be done on the way as well, needing less time to spend afterwards.

Even though the time for refactoring older code is sometimes lacking, by using a pair programming approach helps us write better code,  more likely to build in scope and therefore spending less time for refactoring.


I have looked at some of the challenges that a small team might encounter when using Agile techniques and provided examples of how to overcome this problems. At its beginnings, Agile was designed for small teams and its purpose was to enhance communication and interaction. What make Agile methods different is the way they deal with development and how the teams need to adapt to this working culture based on communication and cooperation.


What does it take to be Agile?

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.


Sean Cody, Bank of America’s process architect, is reinforcing the paybacks of adopting an Agile development in an interview for Information Age . He is offering insights into how Agile reduces risk, the shift away from from classical waterfall approaches and the return on investment. I mostly agree with his ideas, but I would like to outline some differences about the skills that developers need to be part of an Agile team, the benefits of adopting this approach and what it means to be part of a hybrid team.  The one point to be understood from reading this is that there is not only one correct way of doing things. Applying an agile methodology across a big firm is a big advantage, but you will find it hard for people to adapt, especially managers (who are sometimes too tempted to micromanage) that find it hard to delegate and let people come up with their own ideas.

Why do people need to change from the classic waterfall approaches to Agile?

Sean is arguing that working in a business that gains money from being a little bit faster than its competitors brings us to the conclusion that working software needs to be delivered on time and with as few defects as possible. Agile reduces risk and facilitates open collaboration between developers and business stakeholders, and enables process adaptability throughout the software development life cycle.

In addition to these ideas I would say that by adopting Agile, people in teams give deliverable software each sprint (a sprint is a period of time – usually two weeks), which makes it faster to find defects. The progress and the speed of the team can also be monitored between sprints. This way you can see which teams perform better and even do competitions between teams (gamification), so they would be more challenged.

What skills do people need to be part of an Agile team?

Sean’s argument is that people do not need a specific set of skills and that all Agile practices are simply common sense. I would like to contradict this idea and say people need a certain set of communication and inter-personal skills.

From what I have seen young people tend to be more open to the new methodologies, are open to try with the risk of failing, while more experienced programmers do not want to change their routine that has worked well for them throughout their career.

With teams spread over 3 continents, you would find it hard or impossible to be pair programming with a colleague that is 3000 miles away. Pair programming is when two people pair to resolve one task, one is coding and the other one is looking and asking questions/ having a conversation. I have worked in Bank of America over the summer and I realized that with today’s technology it is not that hard to do, you only need a headset and screen sharing software. Although there are some difficulties caused by different time zones. The good thing about pair programming is that you need to know what you are doing (no more trying something without actually knowing what you are doing); you have a pair of eyes looking all the time “over your shoulder” and asking about what you are thinking about.

This kind of pressure makes you be more consistent, more serious, change the game and make you work better and harder, but also helps you become better at expressing your ideas and having to communicate all the time. In conclusion, people having problems communicating their ideas would find it hard to adapt in an Agile team.

Are there any Team Managers?

The short answer is maybe. An Agile team is supposed to have no team leads/ lead developers/ managers, but as Sean is suggesting: “a purist interpretation of Agile practices would state that the business must fully commit to the process if Agile is to succeed, but the reality of the business environment we operate in is that we’re not always going to get that complete level of buy-in”.

I would reinforce this idea with an example. The team I was working in was a hybrid team. Changing from a waterfall approach to Agile did not seem to be as straightforward, so a hybrid was developed without changing the fundamentals: continuous integration, test-driven development, iterative and incremental approach, etc. The sole difference was a designated lead developer who set long term goals and checked everyone’s progress. Although many “hardcore” Agile adopters from other teams, that were following the methodology to the letter disagree that this was indeed an Agile team, it seemed to work perfectly for us.

Even if one was called manager, most of the decisions were still taken together, the tasks were assigned to pairs of two and the sprints’ projects were successfully finished on time.

Is Agile right for all projects?

The article suggest that Agile is not suitable for distributed teams or large projects. I would like to argue against this idea, based on the following examples:

  • For a team split across 3 continents (London, Hong Kong, New York): There are two scrum meetings (scrum meeting happen so that everybody keeps up to date with the progress of the sprint): one in the morning and one in the afternoon – Europe time. In the morning meeting all the people from Asia and Europe, with a few from the States would be online. In the afternoon meeting all the people from Europe – New York and a few others would be online. This means that everybody has the opportunity to report what they are working on and also ask for suggestions when they get stuck.
  • A large scale project can be difficult and time consuming. If this project is time consuming, requirements can change over time. If the requirements change you would need a suitable approach where you can change the direction in which the project is heading. By following the Agile approach you can easily adjust your next sprint to introduce possible changes in the management’s perspective over the final product.

Developers need to learn to work in smaller teams. No one needs to be continuously checked to see if they are doing well. . Today’s programmers are more than just software programmers, they also do testing, design and planning, which involve a number of different qualities to consider. Being part of a multifunctional team is an advantage and pairing makes the team balance the work better and get rid of the dependence over certain key people. In an Agile team everybody works for a common goal, there are no individualities, no one is considered better or worse than anybody, and this makes the teams be more competitive and get more software done in time.

I would like to conclude that I agree with most of Sean’s ideas, but consider that agile developers need different sets of skills. They need to be more malleable and this is a good thing because the technologies change so quickly now and will definitely change quicker in the future. Being an agile developer is the best preparation for the future.