By: Andrea Bridges-Smith, Content Marketing Manager, Spanning
The modern classroom is quite a bit different than the classroom of ten or even five years ago. Students are signing up for their classes online. Educators are more readily available to their students at all times of the day through email, social media and video chat programs such as Google Hangouts. More of the class work is taking place online and being turned in electronically thanks to platforms like Google Apps for Education. All of this is becoming the norm, the new way we do things in education.
And while more education in the cloud is a good thing, it requires us to be aware of things that we may not have been before, like backing up class work in the cloud. Here are a few ways that Google Apps backup can provide real benefits to the everyday lives of students and educators:
On the first day of class, a teacher can send their students email links to the syllabus, class info, readings, et cetera that are stored in Google Drive, which they can refer to throughout the semester. However, if a student’s Gmail account gets hacked, they might suddenly find themselves without all of this important information. If they have backup in place, they can restore their hacked/deleted emails once their password has been sorted out and get back to work.
A student is more likely these days to turn in an assignment online by emailing a link to a Google Drive document. But let’s say that when their teacher opens the file to grade it, they find a blank document because the assignment hasn’t synced properly. In that case, the student can use backup to retrieve an uncorrupted version of the file and submit it, and both the student and the teacher are saved from having to do extra work and get IT or administration involved.
Teachers these days often grade and store their grades in a spreadsheet on Google Drive. If the spreadsheet of everyone’s grades for the semester were to get accidentally deleted, the teacher would likely be preparing to regrade an awful lot of material while seriously reconsidering their career choice. But if backup is in place, the teacher can easily retrieve the grades, saving themselves a massive headache.
Group projects have long been a part of education, but with the ability to see changes and chat in real time inside a Google Doc, it’s easier than ever to do it right. Students can collaborate on a document, but if someone makes a change that the group decides to throw out, they can use backup to retrieve an earlier version and move forward with that one instead.
Turning in an essay online via Google Drive sharing is great for students because it’s more convenient than bringing it to class, and it’s great for teachers because they can use online tools to immediately check for plagiarism. Google Apps backup adds another layer of benefits; if a student tries to make changes to their assignment after the deadline, the teacher can use backup to retrieve the earlier version and makes sure they’re only grading what was turned in on time.
As we transition to a more cloud-based classroom, we must prepare for the inevitable pitfalls that accompany any new way of doing things. The benefits of having the cloud in the classroom – the convenience, the collaboration and the communication – far outweigh the risks, and as long as you plan ahead for what might go wrong, you can clear the hurdles and get back to what matters.
By: Mike Pav, VP Engineering, Spanning
This is the fourth in a series of posts discussing some of our core engineering practices. In the first, I laid out what our core practices are, in the second, I talked about releasing early and often, and in the third, I talked a bit about how we have adapted some Agile practices. In this post, I will discuss our general approach to “process” and how we use hackathons as a tool to determine how much process we need.
Just as we strive to release the minimum viable product, we also want to adopt as little process as required. Obviously as our team grows, we need to change how much process we adopt. There are a couple of components to our core engineering process that we put into place on day one:
Code reviews are required for anything that will end up on our production servers.
All commits need to be associated with a ticket in our issue management system.
Any feature starts with a one-page wiki that describes the customer use case(s) and the proposed features to meet the use case(s).
Many engineering teams consider code reviews to be a luxury. We consider them to be the vanguard of our quality approach. If you have too much code for a reviewer to grok, it is unlikely that you’ve properly broken down the problem you are trying to solve. If you believe that you are too busy to spend time reviewing other team member’s code, you have missed the point that this is a team sport, not an individual exercise. The simple act of walking through our code reminds us over and over that a second set of eyes on a problem uncovers the edge cases that we glossed over on first implementation.
Our issue management system allows us to ensure that we have a good first pass decomposition of the problem we are working to solve. It is also an easy way to make sure that we are all working from a common priority list. And finally, it allows us to keep track of all the things that we will forget later. We chose a super lightweight tool so that we do not need to fight over priority versus severity or epic/story/task decomposition.
We have run multiple hackathons both at the individual level and at the team level. The team hacks have been the most eye-opening because we run with zero process and let the team figure out how they need to collaborate. The only thing we all decided to keep at first was source control, but we did not use our issue management system. This works for about 2 days, but after that we start to really miss a familiar way to keep track of things.
These hackathons also give us a way to try out new technology in a low risk environment. Several of our core features were directly influenced from our hackathons, such as:
Several different NoSQL style databases
Native versus HTML5-based mobile apps
Behavior Driven Development language extensions
Several different master/slave worker models
The key point that I’d like to make here is that you need to be just as careful with your process adoption as you are with your customer-facing feature selection. Start with what is the minimum viable process model that works for who you are today. Constantly re-evaluate your approach as your team grows and bring in new practices as needed, but not too early or too late. And use some type of forcing function to test when you need to make those process leaps.
I hope that this series has offered a small view into Spanning’s engineering approach. While it is far from perfect, it is working well for us. What have you found that works for you?
By: Mike Pav, VP Engineering, Spanning
This is the third in a series of posts discussing some of our core engineering practices. In the first, I laid out what our core practices are, and in the second, I talked about releasing early and often. In this post, I will discuss how we use some Agile practices. You will see that they both support and make possible our “release early and often” approach. I’m not going to talk about estimation specifically in this series (that topic could fill a whole new series). Instead, I’ll just hand-wave and say that we constantly estimate work effort in terms of our delivery milestones.
From an Agile perspective we do not pay any attention to story points, burndown, velocity or any of those other standard Agile metrics. It is not that we do not understand them. To the contrary, we have deep experience with formal Agile practices and understand how much value they have brought to software engineering. But, I consider those Agile metrics as first derivatives of real work rather than a direct measure of real work. Ultimately we focus on the most important thing: how often do we actually ship features to our customers?
Our weekly iteration is not a pure Agile sprint. We do commit (oops, that implies estimation) to what we will get done, but the objective is to force us – engineers, product owners, everyone – to think about features in terms of demonstrating something more than we did last time, and most importantly, demonstrating it from the customers’ point of view. We try very hard to avoid building horizontal layers of architecture (persistence, then service, then API, then UI in the last few moments of the release). Instead, we build vertical slices of a feature and then refactor relentlessly as we learn a little more. This allows us to commit code to our SCM frequently and to get other engineers consuming that code almost immediately. This is the same way that we approach external releases. From a feature perspective, we are willing to push ourselves to the point of being uncomfortable with the minimum feature set for a first release. Over and over we are reminded that all the things that we think are must-have issues for our customers turn out to not really matter when customers vote with their dollars.
We played around with our daily standups in terms of when we held them, what we talked about, how much time we spent on issues, and found that the one thing that significantly improved our standup effectiveness was the actual act of standing up and getting away from our keyboards. For our team, we don’t wait for the standup to collaborate. We collaborate all day every day. Instead, the standup allows us to step back a bit and look at the larger picture of how each person’s work contributes immediately to the whole team moving forward.
The Agile process is a wonderful framework for software engineering, but it’s important to not get so caught up in the process that you stop paying attention to what’s important: releasing features to your customers. At the end of the day, we focus relentlessly on what our customers want and making sure that the work we’re doing is directly tied to real customer feedback.
Stay tuned – in our next post, we’ll discuss how we use hackathons to guide our overall process.
Partners Can Build Profitable Data Protection Businesses Around Google Apps
AUSTIN, TEXAS, May 16, 2013 – Spanning Cloud Apps, Inc., creators of the powerful, enterprise-class data protection solution Spanning Backup for Google Apps, today announced the launch of the Spanning Authorized Resellers Program. Through the program, partners can now provide their customers the highest-rated, most complete product for protecting Google Apps data, Spanning Backup. The program has been designed to provide value-added resellers (VARs) and system integrators with outstanding margins and recurring revenues, as well as sophisticated marketing and sales support.
Spanning Backup provides backup and recovery of the complete Google Apps suite: Gmail, Drive, Sites, Calendar and Contacts. The solution features a secure cloud-to-cloud environment for protecting Google Apps data and SSAE 16 Type II audited processes that ensure its integrity. Spanning also provides constant monitoring of data backup, allowing administrators to correct issues before they become problems.
“We have designed a program that extends the value of reseller services, and brings together the key support pieces for their ongoing success,” said Jeff Erramouspe, chief revenue officer, Spanning. “We’re excited to already be working with leading VARs and system integrators worldwide and look forward to expanding into new relationships.”
“As enterprises encounter obstacles in moving to the cloud, Spanning Backup provides a unique solution that solves the challenges facing our customers in North America, Europe and Asia,” said Doug Shepard, President of the Google Business Unit for Cloud Sherpas, the world’s largest Cloud Services Brokerage and two-time Google Apps Global Partner of the Year. “We look forward to a successful partnership with Spanning as we integrate their solution into an overall cloud strategy for our clients.”
Spanning is committed to their Google Apps reseller channel; the new program provides resources to ensure that partners receive technical, marketing and sales support.
Key features of the Spanning Authorized Reseller program include:
- An aggressive discount structure with strong margins that gives reseller partners complete control over end-user pricing and a higher average revenue per user (ARPU); potential for increased ARPU by 60-80 percent over selling Google Apps alone
- Lead referral and distribution of new business opportunities
- A simple contracting process to get resellers into the market quickly and efficiently
- Customized marketing programs for specific territories, market segments and business practices, including email marketing, webinars and other co-marketing activities
“We have found Spanning Backup to be an excellent platform for delivering value added services to our clients,” said Rob Morgan, managing director for PIT Group in Wollongong, Australia. “Managing data protection policies isn’t always easy and many of our customers contract with PIT Group to do that for them. The Spanning program gave us the flexibility to bundle our services with Spanning Backup and deliver them both to our clients in one cost-effective package.”
Spanning has partners reselling Spanning Backup around the globe, including in North and South America, Europe, Middle East, Africa, Asia, and Australia/New Zealand.
What Partners Say About Spanning
“I worked with Spanning early in the development of their reseller program. They were responsive, flexible and built specific items into the program to better accommodate our requirements. With an already expanding user base using Spanning’s products, I am pleased to represent them in Israel and look forward to a long and fruitful relationship with them.”
- Amit Dunsky, CEO, high-T, Israel
“At CIMA Solutions Group, we believe that data protection is critical for Google Apps applications. We’ve seen our customers inadvertently delete data in some cases. Spanning Backup provides backup and recovery services that work.”
- Todd R. Brown, VP of sales and business development, Cima Solutions Group, Dallas, TX
“Spanning has created a flexible and easy-to-use reseller program. They offer outstanding margins and top-tier marketing and sales support. Spanning Backup will be a key part of our product offering for a long time to come.”
- Mike Vanderpool, CEO, Valley Apps, Harrisonburg, VA
Share on Twitter: @spanningbackup launches their targeted reseller channel, available internationally with tools to assist with tech, marketing and sales.
About Spanning Cloud Apps, Inc.
Founded in 2010 and headquartered in Austin, Texas, Spanning was created with a singular purpose – to help companies protect and manage their information in the cloud. The company provides powerful, reliable, enterprise-class data protection for all Google Apps: Gmail, Drive, Sites, Calendars and Contacts.\
Join a great team: http://spanning.com/company/jobs/
Get to know us: http://spanning.com/
Follow us on Twitter: @spanningbackup
Eat our favorite food: http://www.chilantrobbq.com
By: Mike Pav, VP Engineering, Spanning
This is the second in a series of posts discussing some of our core engineering practices. In the first, I laid out what our core practices are, and in this post, I’ll discuss the benefits of shortening our release schedule. Releasing early and often is the most important practice that we follow. There have been many times where I thought we had a good rhythm going only to see how much better our engineering process was a few months later after increasing our release cadence.
Releasing early and often is the very best way to ensure that we are building things our customers can actually use. We get quality in our features by using short cycles which force us to continuously explore what is the minimum feature set needed to solve a customer use case. There is nothing worse (both to Engineering morale and the overall company bottom line) than spending time to build a feature that no one uses. When we release a feature, we get very rapid feedback, which helps influence the next steps that we take.
Additionally, releasing early forces us to think about the implementation in terms of incremental customer exposure so that we build narrow slices of functionality from the customer’s perspective rather than horizontal layers of infrastructure from the engineering perspective. This has two very solid impacts in terms of quality:
It forces us to really understand the customer problem from all angles before we start coding, and that deep understanding helps us significantly reduce requirement-level defects, which are the hardest and most expensive to fix.
It also allows us to watch how our product behaves in production, and when there is an issue, the fix is obvious since very little has changed since our previous production push.
In short, we get quality in terms of our implementation because we have fewer code changes in each release and we get faster feedback on those releases.
Now, the term “release” is used at several different levels. At the top is the obvious push of code to our production servers for our customers to use, but we also do internal releases for reviews. And finally, we consider a commit into our SCM (Source Code Management tool) to be a release in that the commit has gone through a full test/review cycle and is ready for the rest of the team to consume. Each of these activities has its own cadence, but the general truism for us is that faster is better.
If you’re working with a long release cycle, consider shortening it to see if the quality of what you’re releasing improves. We’ve done it and couldn’t be happier.
Stay tuned – in our next post we’ll discuss how we’ve adapted Agile processes to work best for us.