At Huawei, our group (consisting of four seasoned veterans) were charged with building a public PaaS cloud product on top of VMWare’s recently open source project, Cloud Foundry. I took the user experience aspect and the front-end part of the product, and was given eight junior engineers with no cloud exposure and no experience with dynamic languages.
While many like to think that a project architecture should be completely objective and devoid of technologies, clearly choosing a framework significantly guides the development of any architecture resting on it. For my dynamic, web-based client, I chose the FuzzyToast framework (built on top of jQuery), and Express (built on top of Node.js) for the server part (I described this choice on my blog).
I agree with Simon Brown’s approach when he wrote:
I don’t subscribe to the theory that the architecture document needs to include everything right down to the very lowest level of detail. I think too much time is wasted getting down to that level and, in doing so, you increase the likelihood and speed at which the information becomes out of date.
With only four months before we needed to release an alpha version of the product, I felt I only needed to introduce “structure, guidelines, principles and leadership to the technical aspects of [this] software project”.(1) This became a collection of Wiki pages with clarifying diagrams. Here are a couple of non-confidential Wiki pages I’m allowed to share:
Finally, I set up a git system and checked in the basic code structure using the chosen frameworks.
With a young team unfamiliar with the languages and technologies required, I devised a training curriculum. I put together a series of courses and supporting material. These were Wiki pages that I sent to the team as a “PDF book”. For instance, CP 104 referenced the supporting Node.js page.
One tradition I added as part of my team’s culture was, Ten Minute Sharing segments (每日分享). After our scrum, we alternated sharing design patterns, debugging techniques, or code recipes. I used this opportunities to introduce new technologies that we would use in up-coming sprints.
Day to day management and guidance followed a modified Scrum process with a Kanban chart through a Jira/Greenhopper system. After the scrum, I would work with the team in the evenings to answer questions, and then review their code the following day. I usually flew to Beijing for the Sprint demonstration to management and the kickoff of the next sprint.
My team of engineers were eager to learn and excited for the project. The biggest hurdle was when management insisted that along with a web app interface, I also deliver an Eclipse plugin that could also connect through our REST interface to the Cloud Foundry server.
The result of our three month effort was delivery a feature-complete, alpha product on time. The code was continuously built in Jenkins including running unit tests with 100% code coverage and the creation of online documentation.