At InSTEDD -like at any other non-profit..or a well-run business- there is a constant evaluation of how we are using our donors’ money, looking for ways we can reduce overhead and anything that doesn’t translate directly into mission-related impact.
Given how much of our focus is on technology, it is natural that this concern affects how we design the infrastructure that supports our work. In this post I share the toolset we use to support the lifecycle of our technology which is effective as well as lean. Perhaps others can take advantage of the evaluation work we did or can suggest useful alternatives..
Our key requirements are:
- The tools work with our Scrum+XP (eXtreme Programming) processes
- The tools work for an internationally distributed team even when in the field
- They are efficient cost-wise as well as adequate for the task and reliable
These requirements led us to evaluate many approaches. Ultimately, we opted for an infrastructure that requires no intranet, and no on-premise servers. That means no extra staff of acolytes & operators simply to keep the things going, and associated savings on power/heat/rackspace management…expenses decidedly not core to our mission.
I’m exaggerating. We do have an intranet. It has a printer.
By using software-as-a-service or software+services we have the advantages of lesser operations and increased reliability. We must also take a hard look at three contentious areas:
- Security: Will the hosted service provide us with the level of confidentiality, transport security, and the management of user privileges that we need?
- Data Portability: Will the hosted service allow us to import – and even important – EXPORT data to another service? We didn’t want to fall into a lock-in scenario with ‘trapped data’. Both on and off-premise backups are a must.
- Accessibility: Will the service be accessible in the field? How Can it cope with low bandwidth connections? Is it possible to work offline?
In the end, we have arrived at the following list of tools that as a set fare well with our way of working and our needs. You can see the rough cost structure for the services that aren’t free (When I say ‘Free’ I mean gratis/no cost/Free as in Beer.)
Engineering Tools:
Google Code –http://code.google.com/– We use Google Code for the source code control (SCC) of components and tools we release as FOSS . It provides issue tracking, a wiki, and downloads in addition to the source code control features. Free.
CVSDude – http://cvsdude.com/ – We host in CVSdude the source code for projects in their early stages when they aren’t open source yet. Monthly fee.
Tortoise SVN – http://tortoisesvn.tigris.org/ – Tortoise is the most popular SCC client in the team. CVS & Subversion allow working offline – and managing multiple copies of the source trees on the client, and Tortoise allows you to manage these with ease. Another great feature is that we can keep in the same source tree a mix of projects hosted on Google Code and CVSDude, allowing developers to just do single update and commit operations. This helps us work on our embarrassing early code while keeping the open source projects up to date with no extra hassle. Monthly fee.
Fogbugz – http://www.fogbugz.com/ – We use Fogbugz for our work-item, task, and bug management. Batch updates are easy with its AJAX-based list management. It allows you to create private and shared views, exports data in multiple formats, provides email notification and reports (eg burndown charts) that are useful in agile processes. And – great for testers – it even has a client that allows you to take screenshots, annotate them, and attach them to new bugs. Finally, it has a killer feature that allows me to create new tasks by just typing and pressing “enter” (“killer” because its abuse guarantees my death at the hands of the engineering team). Monthly fee.
Virtualization – Although it is not “hosted infrastructure”, virtualization saves on hardware costs. We run most of our work in virtualized environments which include including dev boxes, boxes running demos, boxes for testing or building. Some devs run these from XP, Linux, or Mac OS. We tend to use VMWare, which does a good job of allowing VPCs unfettered access to USB ports and such when working with special devices. Free or not depending on the virtualization product you use and the OSs you are hosting.
The collective annual fee of all the services listed above roughly equal the cost of one moderate-size server with no OS, no software and no support staff.
Communications & Sharing
Skype – http://www.skype.com/ – For voice, video and chat. At crunch times, our team keeps a Skype channel open — sometimes for hours at a time. It provides a sense of literally being in the same room. We are also looking at ooVoo, vSee and N-way for video. Basic Skype is free. Additional features, such as forwarding calls to a cell phone, are very cheap.
Conference calling– http://www.intercall.com/– We chose a conference call provider that has access numbers in over 50% of the world’s countries. Although costs are based on the number and location of call participants, overseas tolls are avoided, which is a significant savings on international calls.
Twitter (http://www.twitter.com) “Micro-messages” are great for ad-hoc communications, especially by SMS users spread across several countries. Within the team we send twitter direct messages by prefixing messages with d as in “d some-name I just uploaded the new version check it out“. I use Twhirl as a Twitter desktop client. Free.
Sharedview – (Link) We use this new Microsoft tool for quick-and-easy screen sharing. Drawback: it only runs on Windows. But most of us have some flavor of Windows running – even if it is in a virtual machine on Linux or MacOS. Free.
Google Docs – (http://docs.google.com/) We use Google docs for taking notes and brainstorming during conference calls. It allows multiple users to collaboratively edit a document in real time. Once completed, though, we copy the document into MS Word or OneNote and save in Groove, which makes it possible to access the information offline. Free.
Groove – (Link) Microsoft Groove is useful for team coordination, managing “knowledge bases” of technologies and, most important of all, for tracking user requirements in the field. Since Groove is inherently an offline tool, it shines when Internet connectivity is an issue, but local connectivity is possible. It is not a traditional “cloud” product, but is based on a secure mesh architecture that allows pure peer-to-peer interaction. Unfortunately (hint!), it only works on the Windows OS, it speaks non-standard protocols over the wire, and has no “Web Access”/”Live” component to it. It is a part of Microsoft Office Ultimate. License Fees.
Still needing improvements…
These are some of the shortcomings with these hosted services which we hope will be addressed in the upcoming years:
- Offline access: Many web-based tools would be more useful and valuable if they also offered a thoughtfully-designed, well-architected, reliable client for offline usage (and it takes more than just sprinkling Google gears around your javascript to achieve this, but that’s a topic for another post).
- Unified authentication – The growth in number of sites using single sign on technologies such as OpenID is encouraging but more would be better. In addition, services such as access control and other crosscutting features could be added into the mix (a trend I encouraged at an AOP panel long ago).
- Support for Integration – I’d like to see more sites view themselves as ‘building blocks’ — as part of a larger solution instead of trying to be the ‘one stop shop’. Data, process, and UI integration APIs are always welcome.
So far this mix of products has been working well. The increase in bandwidth, along with tools and standards has allowed us to have core engineering-mission-critical tools online, and “software as/plus services” a cost-effective strategy we use everyday.