I have talked previously about the nature of the File Guard project, and what makes it a big task. Today, I’d like to share the new approach we took to create the design for that project.
File Guard is a project with a clear vision of what we want it to be, and thus a well-defined set of requirements. Because of this, and because of the many challenges I outlined in my previous blog, we felt it important to nail down a really good design before we started implementation. We knew what we wanted to do and we wanted to put down on paper exactly how to do it right.
With so many different aspects to the system, and different people responsible for different areas of that system, the design had to be a collaborative effort. In years gone by, this may have been achieved by writing little fragments of design and emailing them around to each other, with one person bringing everything together into a “master” document. This method was messy, it was hard to keep track of what was going on, and a lot of time was spent trying to keep it organised.
I have blogged previously about collaborative working , and the advantages it brings. You’ll be pleased to know that it’s not all just talk: on the File Guard project, we have put this into practice, and we are delighted with the results.
Using collaborative working tools, there was no need for emailing document fragments around. We started by producing a skeleton design document, with all the section headings in that we wanted to cover. We marked each section with who was responsible for writing it. And then we all started working on the design – all at the same time, on the same document.
They say you should expect the worst but hope for the best. So we took the decision to use this methodology with the view that it was a trial run. We regularly backed up the document, and expected that at some point we were bound to hit synchronisation issues or that work would go missing. Happily, what we found was that it all worked very well, and allowed us to really build some momentum and start putting together an excellent design.
We had short daily catch-up meetings to monitor progress. In these meetings, or in email, we would let each other know that we had finished a draft of a section. This allowed us to perform continuous peer review, reading through the sections others had written and leaving comments – embedded natively within the same single document – for the author’s consideration.
It’s difficult to describe the huge difference this method of working made. I could go and chase up the metrics and try to put together an analysis by numbers, but it doesn’t seem necessary: working this way feels better. If you have worked in Software, you will know the feeling of asking yourself “why is this so difficult when it should be so simple”? That feeling was nowhere to be found here: everything seemed to flow and come together naturally, the design quickly took shape and looked better every day, and we were all working together as a team. And by the end of it, we had an excellent design that the whole team was proud of.
I mentioned in my last blog that designing File Guard isn’t just designing software – it’s an appliance, a physical server, and the whole thing needs consideration. Next time, we’ll look at the approach we took to security.
Got an experience of collaborative working you want to share? Leave a comment below.
Disclaimer: This article is written by one member of a team, about a project that is still in progress. Knowledge may be imperfect, and things may change. This article intended to be nothing more than opinion, and should be taken as such.
Once Upon a Camayoc 