Collaborative coding versus solo work

- [Instructor] The process of building applications that are based on software roughly has three high level phases. Coding or selecting a programming language and translating the requirements for the application into code that a machine can understand and execute. Testing, verifying that the translation from the English requirements or whatever the native language of the business owner is to the code language has been executed correctly. This is sometimes called verification or QA. And deploying, that is moving the code from the developers, usually laptops or location, to a production location, so an end-user or a customer can access the software application. Now in these three phases there are a number of ways that this work can be accomplished. In many software shops, the majority of these three phases of application development are done solo. And what this means is that, the coding, the researching, the testing, the deploying, and the documenting are done either individually by the same person at different times, or more frequently, by different people. Although this method of working solo on these different aspects of application development is obviously successful, there are collaborative opportunities in performing these activities. And what does that look like. Well the first level of collaboration is one that's outside the scope of this course and I call this asynchronous collaboration. And what I mean by that is when one or more people are working on one of the phases of the project and they're doing it in a way where they are not connected real time. So an example of this would be writing documentation for an application and perhaps working on a Google Doc, but asynchronously making comments and then responding to them. Another example of this would be a developer handing an application off to a tester, a tester running tests, and then notifying the developer of test failures, via an asynchronous method, such as a notification in email or possibly Slack. Synchronous collaboration is in scope of this course. And what I mean by that is you have one or more participants in the application development lifecycle, let's take the example of two developers who are either physically sitting in the same location, so they can see and hear and talk to each other and often times working on a single machine, in the case of pair programming. Or perhaps two testers are working in two different locations, but they are using software so that they can synchronously collaborate. One example of this would be to use an application such as Skype so that they could see each other over video, hear each other, and share a screen. There are many, many different tools that you can use for remote synchronous collaboration and we're going to be looking at some of those and seeing some of them in action in this course. Pair programming is a type of synchronous collaboration that has a little bit more formality around it. And what I mean by that is typically pair programming is two developers that are working on a single code base. Often times they're working on a single computer. I like to add brainstorming in the collaborative section. Brainstorming, for some people, is called a meeting, sitting around and talking about work. And I like to contrast this to another type of collaborative work which we'll be covering in this course which is mob or group programming. A key difference between brainstorming and mob or group programming is in brainstorming a group of people with various roles in application development are sitting around talking about work or potential work or deciding on work. In mob or group programming, a similar kind of a group is actually performing the work. So it's a key difference, and it might seem like a slight, maybe you know a trivial difference, but I have found when I introduce the concept of mob or group programming, that being very succinct about that difference helps to communicate the difference between brainstorming and mob or group programming across all the levels of the organization, from the executive level all the way to the implementation level. So just to reemphasize, brainstorming is sitting around and talking about deciding and discussing potential work or work that could be done on an application and mob or group programming is sitting with a group and actually performing the work.