Today we visited Códice Software, the team behind PlasticSCM, and had the chance to take a look to how they work. They are currently being evaluated fot the L2 CMMI certification.We went to Valladolid (Spain), to the Technologic Park of Boecillo. I must say that first of all, it's a dreamlike place to work in a software development company. Calm, quiet and surrounded by a beautiful nature environment.
So we came into the building where they're located, along with other software development companies. There Pablo welcomed us to their company and invited us to come in. The first impression I got is that it's a clean and nicely decorated place. Every single piece is cleverly placed and serving a purpose. Large room to share with the teammates and enhance communication and workflow.
Then Borja told us about their testing process. The testing process is very cleverly done, and there's not a piece of code that isn't tested several times and in different situations. That's something you're being told everytime but you're never asked to do. And they demonstrated us that testing is necessary. This is a reason of why the branch-per-task development pattern is so important in the development management, allowing to verify every single step of the development, and then the whole software. So you increasingly create fail-safe and stable software releases.
Later, we saw how they successfully are using their own product, Plastic, as the SCM tool. They store a well-designed repository, boosting the development process to levels not reachable in other ways. Of course, source repositories have loads of advantages such as version-based operations (such as retrieving previous versions or rollback conflictive changes) or codebase safety.
Then, we were present at their today's Scrum meeting. Scrum is an agile methodology for development management, based on sprints and tasks that go into those sprints, releasing functional and stable versions of the software being developed in an increasing way. So after each sprint, you have a program that works, and you can play with without warning of crashing it all. Scrum tells to do short daily meetings of about 15 minutes where the team exposes what they did the previous day and what will be next in the current working day (sort of a development postmortem). So they met at the meetings room and talked briefly about the steps given and the next ones. I must say the way they manage the meetings is smart and efficient, by the way.
We then finished our visit and let them continue working on their new tasks.
So, these are my conclusions:
- It's important to work in a good development environment. One must feel comfortable at work, as I felt being there. Also, the working place must have all the equipment needed to help the development process, as well as enhancing teamwork.
- Test your software. Planify your tests according to your tasks and overall development methodology. Don't be lazy and do test your software. Skipping tests can be harmful too often.
- Keep repositories of your codebase. We all have done harmful changes we couldn't rollback, or messed with hordes of zip files storing the "codebase". Honestly, I've tried it, and must say that I simply can't go back to the dark world of .zip versioning systems ;)
- Scrum works, and agile development works. Maybe their detractors have good reasons against them, but I've witnessed why Scrum is defiitely good. Códice uses it, and it's a success story. Why should I need theorethical reasons of why this doesn't work, when I have real-world reasons of why this works?
A fruitful visit I will take as a reference for my future works. Can't wait to start using these practices for everything (of course, starting with Caelum ;))
