I’ve mentioned here and here about the brown bag meetings we have at EPS. We’re taking this idea to the next level so that we can push the knowledge transferring further and quicker. The main idea is that we will be meeting also on Saturday mornings, for about 3 hours, and therefore get more things done.

The final product of this idea is to have a .NET application to replace the process and tools that we currently use for timesheet, travel expenses report, and billing. However, the ultimate objective is to increase/improve the developers’ knowledge on the different areas involved with software development, from tools and frameworks through processes and architecture.

Below is a little more detail around this project. We’ve already had a few meetings, and tomorrow I’ll post another entry here with a summary of the meetings we’ve had so far. I’ll try to keep posting updates every week so to keep track of our progress. I want to somehow document this experiment.

I’ve already tried this on a small scale with Milton, a new developer we’ve hired, where we’ve built a new project on the evenings during a 3-week period when he was visiting Houston, and we both agreed I was able to have a lot of knowledge transferred to him on such timeframe, so I’m really looking forward to see the results when applied to a larger project with more people involved.

So here goes a little more detail about this project…

The Requirements

• Every developer should contribute writing/designing the app;
• The app should be built following all best practices/design possible. The code should look pristine (as good as we can given our knowledge at hand);
• The app should showcase both Milos (our framework), best practices, clean design, etc.
• Elements of an Agile process should be used (I say “elements” because we’ll introduce those elements as we feel comfortable, and as we them fit inside of our organization);
• The app should be written following Test-Driven Development (TDD) principles;
• VSTS should be used to keep track of work items, progress, iterations, etc.;
• Every code should be written pair-programming;
• A Continuous Integration process must be used (which includes auto-generating ClickOnce manifests for the app)
• The app should be built in a way so that we could easily create different front-ends to it (WinForms, WPF, Web, Silverlight, compact device, etc.).

The Ultimate goals

Besides the goal of having a working application that we’ll use in-house, we have other actually bigger (or more important) goals in mind:

• Get all our developers to master Milos;
• Make sure that everybody is familiar with the most important OOD principles and best practices;
• Get everybody to get used to TDD;
• Developers would eventually get more concise in the way they write code. That’d help with people jumping between projects and maintaining somebody else’s code;
• Since the app would have full test coverage, the integration tests will improve the code quality of Milos as we can include those tests into the main framework’s automated tests list;
• We’ll increase our knowledge of using VSTS to track progress, iterations, etc, on projects;
• Pair programming is a great way for developers to learn (knowledge transferring);
• We get everybody to learn more about things such as continous integration, ClickOnce, etc.
• We get a great sample application for Milos.

How do we implement this idea?

This is what we have in mind in order to implement this idea. There’s nothing written in stone, so we’ll be constantly evaluating what’s working and what’s not and then improve the things that need to be improved. We’ll definitely inject our experience gathered from the other projects we’ve worked on into this project, and the experience we gain from this one project will certainly spread into the other projects.

• Have weekly 1-hour meetings (on weekdays), and another 3-hour meetings on Saturday mornings. Nobody should do anything single-handed, since that’d defeat the main purpose of this project. Everything must be done either in pairs or bigger groups;
• On each meeting, requirements would be gathered, mockups will be created, code will be designed, written, and validated by the end-users (that’d be whoever uses the product of our project, that is, both developers and non-developers);
• When designing/writing, developers would alternate control over the computer every 10 minutes. That is, one developer takes control of the computer, and say, writes the code. After 10 minutes, another developer takes over. This goes on until the meeting is over;
• On the beginning, it is better if every developer could be in the same meeting room. Once we’ve got things rolling, we will split things up into 2-person teams. For instance, maybe Joe (fake names are used here) could team up with Mary to validate requirements for the app and write up some more specs, while Michael and Gene work on implement some of the requirements gathered previously. The teams would alternate every week, or even within the same meeting (maybe a meeting would start with Gene and Mary working on requirements for the first half of the meeting, and then they each would go join a separate team to work on implementing the requirements);
• Developers should not go on their own implementing parts of the application by themselves. One could go on his own trying something out outside of the app, but when it comes to actually implementing it into the app, it must be done in pairs, so that others can both learn from the solution, or bounce ideas back and forth to analyze whether the developer isn’t missing something important.
• We have developers working remotely, from distant locations such as Brazil and Austria, so we’ll be using a mix of Live Meeting and Skype in order for them to participate in the project.

Coming up on the next post…

Like I mentioned, soon (I guess tomorrow), I’ll be posting a summary of the meetings we’ve already had, and what our experiences have been so far. Of course, that’s going to be mostly from my point of view, of my interpretation of somebody else’s point of view, so we may get my fellow co-workers jumping in and helping me out with that.  🙂