To follow on from ‘How to Make work-life balence work‘ video Alison Morris from Online MBA has a pretty interesting inforgraphic regarding the effect of the current trend in America to work more than forty hours a week: it is pretty sobering stuff!
While Europe tends to better at work-life balance than North America there is still room for improvement on both sides of the Atlantic. I believe it is in an employers best interests to not over work their staff if they want to get the best quality of work.
Software Engineering Radio’s recent podcast about Distributed Scrum was pretty interesting.
The most memorable comment from the while discussion was that a remote/external team is on that is more than thirty metres from you team. This would mean that many other scrums team that would normally be considered internal teams would actually be external teams e.g. two teams could be in the same building but could be external to each other.
Another interesting idea was instead of having each separate remote group work on sperate tasks or features was to instead split development between the different teams. The idea is that this will force communication to occur much more frequently than the traditional approach of having each team work in a separate siloed task.
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.”
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.
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.
“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.