… thinking long-term is a high status thing to do because smart people are better at it. Thus, being a long-term thinker signals that you are smart. However, as we might expect with status competitions this is overdone.
When we started developing CloudSwing we decided to develop CloudSwing as if quality actually matters. By quality i don’t just mean that the code functions as designed. High quality products also meet the needs of the business and customers.
In the past there has been a sense of disconnection between the business, QA and development parts of our team. (An all too common situation in my experience.) If quality actually matters there must be good connections between all the stakeholders and quality must be considered at every step of the process. We don’t have a product manager, or a large QA team2. That means that if quality is going to be considered at every step it is going to be because the developers are doing it, there is no one else at many of the steps.
Our solution is to acknowledge developer responsibility for all aspects of feature development. That unification reduces the chances of things being overlooked. It does change the workload of developers, though. Now developers must:
elicit requirements from all stakeholders
write testable acceptance criteria
develop automated acceptance tests
implement the feature
verify all acceptance (included pre-existing ones) pass
verify that the feature, as implemented, matches the desire of the champion
deploy changes to production
This has lightened the load on QA to the point that our one QA resource can keep up with four developers. QA still has a lot of responsibility:
verify the acceptance criteria make sense
verify the acceptance criteria is testable
verify the acceptance criteria cover all important variations of the feature
verify the acceptance tests cover all important variations
refine acceptance tests
verify all tests pass in a production like environment
We have been using this version3 of the process for a while now. I think is has worked really well. In fact, during our last retrospective our QA guy stated that he thought our quality management processes belonged in the “Good things” category. I think that is a first i have ever heard a QA person be so positive about processes.
Only time will tell if this approach produces significantly better results but I am very optimistic. So far it seems to have created a world of difference.
In practice the process is more fluid that it looks in the diagram. Developers are empowered to do what it takes to get the job done. Including not following the process. However, not following the process requires an affirmative defense when QA asks “WTF?”.
If the idea of deploying your applications on commercially supported open source stacks with built in application monitoring and cost management sounds appealing you should check it out.
I learned an immense amount, even though i have been using cloud computing for years. The view from inside is a bit different than it is from the outside. It has been a fun ride, and there is a lot more to come. (Including some more posts here about some interesting things we learned.)
My name is Peter Williams. I am a father and software developer. (I do a few other things, of course, but family and software are what I am most passionate about.) This blog is primarily a place where I can rant without scaring too many people, but occasionally I record things of interest to my family here.
