Spotify recently documented their progressive approach to scaling Agile development with a fairly large team. Gilt’s approach has many similarities, but since some Spotify best practices are Gilt anti-patterns, it’s worth a closer look.
The Gilt tech team is about 100 strong. Most of our development is done in Manhattan. We’ve also got a small team in Portland, Oregon and a larger one in Dublin, Ireland.
The cornerstone of the Gilt process is the initiative. We define an initiative as “a project that we expect to work on for the foreseeable future.” Our foreseeable future is typically 3-12 months, depending on the area. An initiative might be to increase organic search traffic to the site.
We work on the order of 10 initiatives in parallel. The decision to green light an initiative depends on a number of factors. The most significant factor is a mathematical model of how we expect the initiative to perform, but we also consider softer factors like direct customer happiness and innovation.
Prioritizing a set of initiatives focuses the technology group on an initiative portfolio. This portfolio makes a clear statement on what is important, and indirectly, what is not. This has had a profound effect, halting our previously unending feature level prioritization discussions. This change has made not only our team happier and more productive, but also our stakeholders.
Unlike Spotify, we don’t maintain a roadmap document. Our roadmap is simply the sum of active initiatives. We revisit the set of prioritised initiatives every few months.Read the full post on The Gilt Tech Blog.
Google are associated with innovation in every aspect their business. Their management techniques are no exception. Google employ multiple award systems to motivate employees and perhaps the most notable is their peer-to-peer recognition program. This program allows Google employees to proactively recognize their peers for doing something big or small that goes above and beyond the call of duty. Peers often reward an activity that would have gone completely unnoticed by managers.
Read the full blog on Peer to peer recognition at Google.
Is great leadership the key to an organization's long term success?
Check out Jeffrey Cohn's great piece on the subject, where he discusses the need for integrity, passion, courage, vision, judgement, empathy and emotional intelligence from our leaders.
Arguably, the job of an engineering manager is to hire and sculpt a development team that is not only highly productive, but also precisely resourced for immediate business priorities.
Easier said than done. Businesses are highly erratic organisms. Especially start-ups. From week to week our business environment changes and company priorities evolve accordingly. In response to this, so does the position of senior management on the best way to adapt.
Hiring Drupal developers is difficult. Hiring great Drupal developers in the current market often feels close to impossible. They are highly sought after and most of the people on the market, in all honesty, aren’t very good.
I’ve put together a list of the best Drupal interview questions that I’ve used over the years to screen Drupal candidates. Hopefully you’ll find them useful.
I recently had the pleasure of talking at First Capital's CTO summit. I hosted an interactive discussion on team building for around 100 CTOs and VPEs of small to medium sized, venture backed technology companies.
Here's how the audience voted on 12 critical questions:
#1: Should you hire specialists or generalists? (52 Votes)
I spend a lot of my time hiring. Recently I’ve streamlined my technical phone screening. I’ve defined a “Technical Bar” that focuses on seven skill areas.
Read more on my technical phone interviews blog
I loved the book (and the attack ad below promoting it). I spend a good deal of my time striving to hire world-class web developers, and much of what Jason and David had to say resonated with me.
I cracked a smile at the book’s opening assertion; resumes are ridiculous documents, beloved by the mediocre, filled with half-truths and exaggerations and perfect for spamming hundreds of potential employers. And my heart warmed at the suggestion that cover letters, on the other hand, are potential gems, written in the voice of the candidate and often specifically directed at the position in question. I always read the cover letter first.
Successful managers learn how to stay out of the way and let their teams work effectively and independently. Staying out the way doesn’t mean putting your feet up on your desk and playing Angry Birds on your iPad while your team does all the hard work. It means creating an environment where smart people feel empowered to recognize, own and solve problems.
Here are some ideas to help you as a manger. I’ve included a few quotes from General George Patton, since apparently even our great military leaders advocate staying out of the way.
Few people would argue the importance of great communication across a development organization. It’s vital that developers are aware of the work of their peers, not only the “what”, but also the “how” and “why”. Achieving this is easier said than done. Traditional approaches such as wiki documentation, meeting minutes, email lists and chat channels have value, but also have significant drawbacks.
Most companies with a shared refrigerator have a strict policy designed by a cunning admin to keep the fridge useful. A common approach is as follows:
- Ask employees to claim their items in the fridge by writing their name on it.
- Wait 1 day.
- Throw away any unclaimed item.
We had another couple of great external speakers talking at Digg HQ. The open-source master Doug Cutting stopped by the Digg office to talk about the growth of the Hadoop platform. He talks in detail about Avro. Avro is an RPC and serialization framework that has some interesting differences compared to the popular Thrift framework.
Digg's Andrew Bayer has just written a blog describing how we use Git, Hudson, Selenium, Puppet and Gerrit to manage continuous deployment at Digg.
Andrew describes how we get developer commits to production quickly and safely using a combination of automated packaging and staging, web based code review and automated testing (unit and selenium)
Read the full blog here.
André Maurois (1885-1967) wrote that "The effectiveness of work increases according to geometric progression if there are no interruptions." At Digg we struggle between the clear benefits of uninterrupted work and the need to be agile in our communication.
The last six months have been exciting for Digg's engineering team. We're working on a soup-to-nuts rewrite. Not only are we rewriting all our application code, but we're also rolling out a new client and server architecture. And if that doesn't sound like a big enough challenge, we're replacing most of our infrastructure components and moving away from LAMP.
the meetup discussed the limitations of traditional relational database technology at scale and the open-source alternatives currently available with similar functionality to amazon's dynamo google's bigtable.
findcommand to identify old backups and delete them. you should, however, consider doing something a little smarter than this.
amazon have just released ebs, the final piece of technology that makes their ec2 platform really viable for running lamp stacks stuck as drupal.
ebs, the "elastic block store", provides sophisticated storage for your database instance, with features including:
- high io throughput
- data replication
- large storage capacity
- hot backups using snapshots
- instance type portability e.g. quickly swapping your database hardware for a bigger machine.
recently i posted a couple of introductory articles on jmeter, a great apache open-source tool that allows you to measure the performance and scalability of a wide variety of services, especially web-applications.
i wrote these articles because although the online documentation provides reasonable reference material, it doesn't serve well as a jmeter introduction or tutorial.
things have changed a bit since then. the uk-based publishing house packt publishing were kind enough to send me a copy of emily halili's newly published book on jmeter, which is as far as i can tell, is the first book dedicated to the subject.
amazon are quickly rectifying these problems, and recently announced elasic ip addresses; a "static" ip address that you own and can dynamically point at any of your instances.
today amazon indicated that persistent storage will soon be available.
three weeks ago, zicasso.com launched a drupal-powered free personalized online travel service that aims to connect travelers to a global network of quality, pre-screened travel companies. unlike many internet travel sites which provide cheap fares or packages, zicasso is targeted for busy, discerning travelers who want to plan and book complex trips (the ones with multiple destination stops or activities).
zicasso chose to build their application using the open-source cms system, drupal to leverage the wide array of web2.0 functionality provided by the open source community.
the application was rapidly constructed by a small development team led by cailin nelson and jenny dickinson. the team took advantage of "core" drupal modules including cck, panels, views, imagecache, workflow and actions.
backups are boring, but we all know how important they are. backups can also be quite powerful when working with xen virtualization, since xen allows for convenient back-up and restore of entire systems.
i've recently been working on a flexible, general-purpose script enabling incremental backups of complete xen guests, optimized for secure, distributed environments;
xenBackup. if you're working with xen, you might find it useful.
xenBackup script leverages open-source components like ssh, rsync, and rdiff-backup to create a simple, efficient and functional solution.
in this article we get a sense of lamp performance on ec2 by running a series of benchmarks on the drupal cms system. these benchmarks establish read throughput numbers for logged-in and logged-out users, for each of amazon's hardware classes.
we also look at op-code caching, and gauge it's performance benefit in cpu-bound lamp deployments.
the previous article showed you how to set up jmeter and create a basic test. to produce a more realistic test you should simulate "real world" use of your site. this typically involves simulating logged-in and logged-out users browsing and creating content. jmeter has some great functionality to help you do this.
when making scalability modifications to your system, it's important to quantify their effect, since some changes may have no effect or even decrease your scalability. the value of advertised scalability techniques often depends greatly on your particular application and network infrastructure, sometimes creating additional complexity with little benefit.
apache jmeter is a great tool to simulate load on your system and measure performance under that load. in this article, i demonstrate how to setup a testing environment, create a simple test and evaluate the results.