The Rands Test
Rands has posted his own ‘Rands Test‘ in the style of Joel Spolsky’s famous ‘Joel Test‘ for telling if your company is screwed or not. Rand’s test is focuses on communication while Joel’s original test focused on engineering:
“There is a higher order goal at the intersection of the two questions The Rands Test intends to answer: Where am I? and What the hell is going on? While understanding the answers to these questions will give you a good idea about the communication health of your company, the higher order goal is selfish.”
Embracing chaos
Last week there was a very public service outage in Amazon Web Services (AWS) cloud infrastructure that took down a large number of web sites and services. This post at the High Scalability blog is a very comprehensive list of articles and posts covering the AWS outage from all possible angles.
So many great articles have been written on the Amazon Outage. Some aim at being helpful, some chastise developers for being so stupid, some chastise Amazon for being so incompetent, some talk about the pain they and their companies have experienced, and some even predict the downfall of the cloud. Still others say we have seen a sea change in future of the cloud, a prediction that’s hard to disagree with, though the shape of the change remains…cloudy.
Particularly interesting is Netflix’s Chaos Monkey (see point 3) and how it has been credited with helping Netflix stay online during the outage.
One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.
Deliberately destabilising a live system to improve its robustness is counter intuitive but it seems to have paid off for NetFlix.
Why Scrum fails…
My biggest issue with Scrum is not the methodology itself which I believe is very effective for software engineering, it is how Scrum is typically adopted by development teams. In my experience most teams that are new to SCRUM seem incapable of trying to use and understand Scrum without first modifying the Scrum process to ‘suit their unique development culture’.
These modifications while being well meant usually distort the Scrum process sufficiently to doom the process e.g.
- The scrum master is also the product owner.
- Assigning each programmer to multiple scrum sub-teams.
- Weak scrum masters that are unable to control a stand up meeting.
- Scrum teams of 20+ programmers.
- Stand up meetings with chairs…
- Stand up meetings taking 30-60 minutes due to meta-discussions.
- Not reviewing task estimate accuracy.
- Not tracking all work being performed e.g. bug fixing, training, holidays etc.
- Not engaging stake holders.
- Not having daily stand ups.
I think Scrum is a very useful methodology when its applied correctly as it constantly captures, measures and responds to changes in the project. However Scrum seems to have a fairly unique problem that its very hard to stop teams tampering with the methodology before they really understand the implications of their changes.
Making better bricks
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” – Albert Einstein
I have found the same should be the case for components in a program, each component should have:
- A single purpose.
- The minimal functionality required to serve its purpose.
- The simplest interface possible to successfully use the component.
Keeping the components as simple and focused as possible is the difference between building a model using individual lego bricks or (complete) lego models. The lego bricks fit together easily due to their singular purpose, simple shape and consistently simple interface. You can build pretty much anything out of simple lego bricks. The lego models despite being made out of lego bricks are much harder to build with as you have to compensate for their varied purpose, irregular shape and correspondingly more complex interface requirements.
By keeping components simple, focused and easy to use we can increase the flexibility and reusability of our software.
NetFlix’s Culture
An lengthly but interesting series of slides on NetFlix’s cultural philosophy.
- 6 a point well made about values vs reality.
- 10 to 18 interesting core values: especially Curiosity!
- 26 and 27 are eye opening and challenging.
- 33 and 34 going against the flow.
- 41 to 59 ’freedom vs process’ friction.
- 86 to 91 focus on performance and agility.
- 106 higher salary vs bonuses and stock options.
- 111 not a common corporate line.
- 120 to 125 why culture means so much…
They sound like a pretty interesting company to work for!
