The following is a preliminary plan for a course which could be held in Software Factory. No plans are yet final.
Contact: Esko Luontola
Problem: In a typical software project in the business world, people are always under tight deadlines and easily it happens that people do a sloppy job when trying to get something ready before the deadline. Or at least they do not have enough time for practice, nor do they practice their craft at home (although they should). In the long run this leads to a vicious circle where people use ineffective work habbits and produce crap code slowly (the bigger the company, the more crap they produce). On the other hand, if they would take the time to practice and perfect their craft, they could produce high quality code quickly.
Idea: A workshop project where a team of 10-16 students develops some software under the guidance of a mentor. The mentor is someone who has Master skill level on the software development practices that will be used during the project. The mentor will actively take part in the project by being with the team 3-5 days per week, 4-6 hours per day, teaching them and maintaining a high quality standard. The goal of the project is not to get the software completely finished, but the goal is to concentrate on producing high quality work and improving the skills of the participants. The amount of completed software is secondary. What matters is that all that is done, is done well.
As was said by Corey Haines about the difference between what you do when you have to "get it done" and when you "do it right":
The things you do when you have to "get it done" are the only techniques that you can call "your own". Everything else you're just practicing and everything else you're an amateur at. But when you have to get it done, those are your own.I proudly say that TDD is a technique that is mine. I've internalized it. It's because of the fact that I've been doing it for five years, and when the rubber meets the road and the deadline comes on, I immediately drop back to TDD, because I'm faster to production. I always am.
And as was said by Uncle Bob:
I think the most important thing for a software developer to do, is to focus very hard on their disciplines, on learning - learning new things all the time. A software developer who does not always have a book open on his desk, is missing something. A software developer who does not allocate several hours a week - at home - to learning something new, is missing something.
The topic for the software could be an existing open source project: "Here is open source project X where we need to do Y and Z. The project's lead developer will be available for questions." Also a commercial project can be used. It's also worth considering the possibility of a "legacy code project", where the team will work on an unknown codebase which does not have tests, in order to practice skills on dealing with legacy code.
A typical week in the Software Craftsmanship Workshop might go like this:
Some examples of how the Software Craftsmanship Workshop might differ from a typical software project:
Based on earlier discussions, this kind of workshop would complement Software Factory and would be interesting from the point of view of the reseach which is done at Software Factory, because it would be very different from normal projects. The settings are quite from the opposite ends:
Problem: Online multiplayer games, especially massively multiplayer online (MMO) games such as World of Warcraft, face multiple challenges that make them different from typical business applications. Online games require low latency (opposed to high throughput), typically 50%/50% read-write load (opposed to mostly reads), high scalability and transactionality. Many databases and other systems, which are designed for business applications, simply are not fast enough for games. As a result all the popular MMO games must implement their own server-side architecture, which is very hard, and typically leads to games having concurrency bugs (for example "dupe bugs" which allow the player to duplicate items or money). And to be able to host hundreds of thousands of players, the MMO games usually rely on sharding, where players on one server can not interact with players on another server (EVE Online being a rare exception having all players in the same world). It would be better if the game developers could concentrate on the playability of their game, instead of the infrastructure and the challenges of concurrent computing. See here for more background.
Business case: Because the platform mentioned below is open-source (Apache License 2.0), producing money directly from it is hard. Some indirect means of income are: offering support services for application developers, hosting services, creating closed-source development tools for the platform, and of course developing games which run on the platform. It's also possible for the platform to run non-game applications which have similar requirements for low latency, high scalability, high consistency, 50%/50% read-write load etc. and can make the same trade-offs (reduced durability of recently committed data - although it's possible to offer better durability guarantees at the expence of latency).
Project: Dimdwarf is an unintrusive, distributed, transactional, scalable, application server and object database for the needs of online games. It lets the application programmer to write seemingly single-threaded, event-driven code, which the application server will then execute concurrently in a server cluster, adding transactionality, transparent persistence, and scaling it on multiple servers. Dimdwarf was originally inspired by Project Darkstar, which was a similar server developed as a research project at Sun Labs (Darkstar's funding was discontinued when Oracle bought Sun, and today it's developed by volunteers under the name RedDwarf).
The project would have lots of interesting and extremely challenging things to do. In order of priority:
With a team of 12-16 developers, it might make sense to divide the team to 3 sub-teams: one develops the server architecture, another figures out formal methods, and a third team develops applications which use the server. The formal methods team defines the network protocol for the server team to use. The application team gives to the server team feedback about how the server supports application development.
The above list is too big to be implemented in 7 weeks, so there is no pressure/risk/possibility in getting the system completed during one project. The important thing is to write extremely high quality code, so that the code is as simple and maintainable as possible. The problem being solved is already very complex, so any additional implementation-level complexity is harmful.
The system is developed using TDD and following the SOLID principles. This far the project has used Java 6, Guice 2, CGLIB, ASM, JDave, Mockito, Git, Maven, IntelliJ IDEA. The new architecture will probably also use Scala 2.8, Apache MINA, Specs.
Problem: When an airplane lands at an airport, it must be cleaned quickly (mostly <15 min) before the people for the next flight come in. This is done by a cleaning company which gets paid for each plane they clean. If a flight gets delayed due to being cleaned too late, or not being cleaned at all, then the cleaning company must pay sanctions. The cleaners work 24/7 in teams of 4 or more persons, and there can be concurrently some 10-20 teams on an airport of the size of Helsinki-Vantaa. The teams are commanded by a coordinator, who is sitting in an office and is in contact with the teams via radiophone. The coordinator needs to keep track of which planes have been cleaned, which planes need to be cleaned next, and where each of the teams is.
Business case: The cleaning company requires some way to keep track of the work they do. A purely paper-based solution will collapse quickly as the number of concurrent teams increases; forgetting to mark down that a plane has been cleaned leads to loss of profit. A computer-based solution with poor-usability on the other hand requires using more than one coordinator at a time, because using and inputting data to the program is too complicated. The cleaning companies around the world are willing to pay for a high-quality computer-based solution with excellent usability, because it will let one coordinator to manage more teams, which in turn leads to savings in the vages that need to be paid. It also prevents the loss of profit due to work that had been forgotten to mark down. It will also help the coordinator in decision-making, so that the coordinator is more up-to-date with what is happening, which in turn reduces the possibility of cleaning a plane too late and thus helps to avoid sanctions due to delaying a flight.
Project: PlaneSweep is a product developed by Advoca Group Oy for the above mentioned use case. It helps the coordinator to keep track of what the teams are doing, and produces reports of the completed work. The product was originally developed in 2003, but now the product is being re-designed in order to smoothly integrate flight schedules into the system, so that the usability of the product would be better. The UI of the system is about 70% designed, so it is quite well known what the system should behave like, but its implementation has not yet been started (some of the old components can be reused).
The product will be implemented as a web application, most probably using Scala, Lift, JavaScript and a relational database (or maybe a NoSQL database like CouchDB). TDD will be used to implement everything, so the project will probably start with an intensive introduction to TDD. Some areas of interest, based on which the team could be divided into sub-teams, are: