Ok, we may be a little obsessed … Can’t stop staring at these images of the Shuttle docked with the ISS; mesmerised.
“The spaceship hung in the air much like a brick doesn’t.” – Hitchhikers Guide to the Galaxy
NASA has just announced the end of the Spirit Rover mission on Mars after no successful contacts since it’s last communication on the 22nd of March 2010. Not a bad effort for what was planned as a 3 month mission starting in January 2004. There are some great lessons that come out of these missions.
1) Their goal was simple and easy for everyone to understand – “Wear the rovers out exploring, to leave no unutilized capability on the surface of Mars”
2) Their planning was Agile – As the rovers lasted longer and longer the mission team kept rewriting their play book and planning new experiments – “What we initially conceived as a fairly simple geologic experiment on Mars ultimately turned into humanity’s first real overland expedition across another planet.”
3) Sometimes the greatest discoveries come in the most unexpected ways. After the front right wheel stopped working it started to act as a plow when the rover went into reverse; This unplanned ‘feature’ dug up bright white soil enabling one of the most exciting discoveries of the mission, pure silica deposits just under the surface indicating that previously the conditions required for microbe life existed.
You can read more here about Spirit and Opportunity, perhaps NASAs most successful and cost effective missions ever.
Today I gave a reference for a long time colleague and friend, most of the time the questions people ask when checking CV references are barely more sincere than the standard 4 questions real-estate agents ask when checking potential tenants. It’s a fait accompli.
A real employment exam: this 1964 photo shows a NASA scientist testing astronaut John Glenn’s inner ear balance mechanism by running cool water into his ear and measuring the effect on Glenn’s eye motions.
This time was different, it took 20+ min and they asked deep probing questions. We quickly got beyond the basics of establishing my colleague was capable and moved into questions about the best environment, growth areas and how to get the best out of this person. These guys really cared about getting the right person, but also that the job was right for them as well. They also wanted to know how to make it the best possible engagement for everyone. For them hiring was a long and through process which required a significant commitment from everyone involved, myself included.
When you audition to join the Berlin Philharmonic Orchestra, widely regarded as one of the very best in the world you play the equivalent of a full recital in front of the entire orchestra. It’s very very hard to get in, but when you do, everyone knows how hard it was and knows you’ve earned your place. After all, they were part of the group that picked.
If you’re hiring staff, be ruthless – it should be hard to get in. Stop and think about how much time you spend with an individual making a decision which has consequences (good or bad) which both you and your potential employee will live with for many years to come. Is a 45 min interview with someone from HR and one manager really enough ?
I often hear discussions of how arduous the hiring process at some companies is, and how it turns people off from applying. Google is (in)famous for it’s complicated and exhaustive hiring process. Turning people away because the process might be hard is a good thing. As a potential employee if you’re not prepared to invest a few hours, maybe even a few days in finding out if a job is right for you, are you really excited enough about working for the company ? Wouldn’t you rather know that everyone who you might be working with has had to step up and deliver against the same set of challenges, interview and interrogations.
Getting a job should be hard.
This post is the conclusion to my series on creating Great Agile Workspaces, so if you just landed here, read these posts in order first:
Conclusions
Agile is a powerful methodology for building great software, but it’s just one part of the system in which we and our teams work. Space, communication and distraction have a big impact on the net productivity we can generate.
Space: Focus on building a physical environment that feels good, promotes team work and yet gives enough isolation and separation between individuals and teams – the best environments have diversity, including quiet space for problem solving.
Communication: Embrace high value forms of communication and work on your culture to weed out low value, or negative styles. Be intentional about how and when you communicate.
Distraction: Some distractions are inflicted upon us and some are caused by poor habits. Our capacity to create things once we get in the zone is amazing. The right space, communication culture and a lack of distractions are essential to enabling the zone.
Sadly the depth of field of a workplace is not controllable like the magic of a camera - all people are susceptible to interruption and distraction.
Essential References and Further Reading
Joel’s Field Guide to Developers – Developers and Workspaces
DeMarco and Listers’s seminal Peopleware – Teams and Productivity
Susan Maushart’s Winter of Our Disconnect – Distraction and Multitasking
A very basic agile workspace - high knowledge sharing, but high potential for interruption.
We tell ourselves lies about our ability to multitask and handle distractions, especially the younger generations. Things like, oh kids these days have grown up with all that technology, their brains are wired differently as they chat, watch youtube and do their home work. Our instinctive behaviours remind us that our brain rejects distraction. For instance, to really zero in on a faint sound in the distance we instinctively stop moving, shut our eyes, and focus entirely on listening carefully. Your brain does not multitask when it’s time to really pay attention.
I’ll often work from home when I’ve got something hard I need to just get done, it’s quiet and nobody can interrupt me (obviously if your home is full of kids, dogs and noise this need not apply to you). How often have you said or heard something like this ? “I come in early because that’s the best hour of the day” or perhaps “I come in late and stay back to get my work done” or simply, “I don’t come into the office when I’ve got real work to do”?
Email, Facebook, Twitter, Instant Messanger etc…
Donald Knuth has a wonderful webpage on his Stanford faculty webpage about email – this is my favourite section.
“Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don’t have time for such study.”
He goes on to describe how he likes to communicate in batch mode, once every three months. Three months might be a little too long for most of us, but do we really need to check our email every three minutes ? Come on, hands up if you click the send/receive button sometimes, even when your email checks every minute by default. Facebook, Twitter, Instant messenger and pretty much all forms of electronic communication can be a major distraction if we as users of them don’t manage and mitigate it. If you need to focus, turn them all off. Don’t be tempted to just ‘check in’ or you risk losing short term focus or worse, ending up chasing a tangent to the task you really ought to be focused on.
There is a culture in some workplaces of needing to be always online, in a chat room or IM, instantly available to solve problems. When there is genuinely an urgent problem – these systems work really well – but they command a high price in productivity, especially for developers.
Alistair Cockburn on Drafts
Alistair Cockburn has a great explanation in “Communicating, cooperating teams” to describe unwanted distractions created by co-workers in the office environment – Drafts.
“On the other side of their bank of cubicles sat the call center people, who answered questions on the phone all day. They also benefited from overhearing each other. But, and here was the bad part, the conversation of the call center people would (in his words) “wash over the walls to the programmers’ area.” There was a “draft” of unwanted information coming from that area.”
Beyond the nodes and contracts problems of large teams and large open workspaces, distracting drafts from other teams working near yours can be a major productivity drain. You only need to walk around an office, stand and listen to figure out if you have this problem. If you can hear more than one or two simultaneous conversations at any stage, I think you’ve got a problem to solve.
The Winter of our Disconnect
A book about a single mum and her kids in Perth turning off all the screens in their house for 6 months might seem like an unusual place to find an epiphany, but that’s what happened to me.
Susan Maushart’s book, the Winter of our Disconnect is part diary, part drama and part scientific journal on the topic of distraction. The stories of how addicted she and her kids are to being constantly connected, socially up-to date and online provides an uncomfortable mirror to most of our own lives. Please buy a copy and read it. It challenged some of my beliefs and cause me to face up to some deeper truths which I think I already knew were true about the cost of multitasking and distraction on the ability of our brains to perform. Seriously, just buy it and read it.
Ultimately there are three kinds of distractions
Necessary ones – communication by definition requires some level of distraction from our deep cognitive tasks. But … it’s also essential that we talk, design and work together to function as effective teams. So while we should be sensitive to others when we do distract them, we shouldn’t shy away from it.
Self inflicted ones – Email, Twitter, Facebook, instant messenger and the telephone. These are all things we can choose to turn off, ignore or just not have the first place.
Unnecessary ones – Cockburn’s Drafts, music, selfish co-workers and poor environments all generate distractions which don’t add value.
Focus on having the best necessary distractions and eliminating as many of the self inflicted and unnecessary distractions from your work environment. Finally, Conclusions.
There’s more to software productivity than the physical environment. Communication is equally important. A developer may be in the zone and writing perfect code, but if they are writing the wrong code because they’re isolated then we haven’t done anything to help productivity. Frequently sharing information is essential to every project, and there are quite a few distinct levels:
- Structured communication – Planned meetings, stand-ups and retrospectives.
- Information radiators – Agile boards, build status lights etc.
- Ad hoc but intentional conversations.
- Osmotic sharing, serendipitous or ad hoc but unintentional conversations.
- Tacit learning.
Experience, observation and research tells me the following two things are true:
- Writing Software, designing things, planning and strategy are deep cognitive tasks which require extended periods of focus to perform at a very high level.
- Communication is a distraction or interruption for deep cognitive tasks.
If we’re looking to create the best possible agile system, we need to consider carefully which communication modes we embrace, and what we reject.
We should encourage high quality forms of communication:
- Face to Face conversations.
- Group Stand-ups.
- Whiteboard design sessions.
- Team lunches, drinks, social events.
- Agile boards, build lights, progress success metrics.
While avoiding low quality or distracting forms of communication:
- Group Emails, especially email chains.
- Paper specifications.
- Instant Messenger.
- Campfire / IRC / Team Chat Rooms.
- General office chatter around workspaces.
Carefully embracing high quality serendipitous communication:
- Overhead snippets around your workspace.
- The ‘water cooler’.
- Adhoc group problem solving or design sessions.
The most effective team I’ve worked with had a strong, if unwritten code of conduct about the way team members interact and communicate, respecting the value of productive blocks of time as well as plenty of time interacting both professionally and socially – this code was firmly cemented into the daily routine, with periods of communication and periods of quiet work.
The day starts with coffee, email, jokes and then stand-up around the Agile board. Then there is a period of solid and fairly quiet work time until lunch; team members interact if they need too, but the goal is to balance distraction with productivity. Everyone eats lunch together and the conversation nearly always comes around to some problem on that needs solving on the project. Afternoon is solid for a while, but tails off at the end as people get tired and lose concentration – this is often a good time for group administration tasks like estimation. Very often there is a social drink a few times a week.
When I worked at Ericsson there was a deeply ingrained culture about they value of communication and the importance of being face to face. There were certain things that were acceptable to share via email, others required a phone call, but all important or personal interactions were expected to be conducted face to face – even when that often required getting on a plane. Not environmentally friendly, nor perhaps very cost effective, but it sent a strong single about the importance of being considerate about how we communicated. I wish I could say there was such a strong sentiment about senior staff turning up to meetings on time!
I don’t pretend for a minute that this is something new – Lister and DeMarco have been talking about this since they wrote Peopleware in the late 80s and XP talks about managing communication and space via Caves and Commons. Physical space is important, and communication is important – the final thing I want us to think about ties these two themes together, the price of distractions and multitasking.
The physical space we work in impacts on the way we feel, interact and how productive we are. Jan Banning has captured these wonderful photographs of Government Officials in their office around the world. Take a look at them and then stop for a minute. Imagine your ideal office … what would it look like ?
Perhaps your office reflects your culture ?
Or maybe your product ?
Our office at RedBubble
Or your design aesthetic ?
How about my ideal work space …
http://www.biscade.com/office/
From an Agile perspective office spaces have an impact on a number of key factors.
- How it makes you feel.
- How it encourages positive social interactions.
- How it enable communication.
- How it manages distractions.
- How it enables productive development.
Lots of communication and a high level of development productivity are often in tension and balance needs to be struck.
I’ve worked in nearly every conceivable office environment over my working career. I’ve had a number of private offices, massive open plan call centre style environments and I’ve also worked in the stereo typical startup garage. There is a strong trend, particularly at larger companies towards open plan offices. I believe this is a mistake.
Private offices are great when you need focused time to get hard thinking tasks done, or you need to make phone calls or have lots of adhoc meetings – in many companies they are also a status symbol reserved for senior management. Small collegiate workspaces, typical at startups or creative agencies etc are perfect for idea sharing, collaboration and create a fun and friendly workspace. But they can also end up being being loud and distracting when it’s time to put your head down and write some code. I’m not sure large open plan environments are ever a good answer and here’s why – It’s about nodes and contracts.
A team of 3 people, has to maintain 3 lines of communication, or three social contracts. As the team grows to 5 people, the number of person to person, or node to node interactions jumps up to 10. That means more time spent keeping everyone in the loop and up to date. As the team grows to 10 the number of contracts is more than 40. Quite clearly this style of person to person communication isn’t very scaleable. Imagine an open plan workspace with say 100 staff, the social contracts break down. You loose the benefits of lots of connected personal communication between everyone, but you suffer all the negative impacts of noise, interruptions and distraction generated by that many people. It also becomes necessary to resort to all hands meetings and so-on as it’s not practical to run a standup with that many people.
So what does the ideal environment look like ?
I think the answer is the smallest possible number of people in separated but accessible spaces that still allow everyone working on the same ‘thing’ to work collaboratively together. What does this look like in practice ?
Here’s one very successful setup for us at Lonely Planet.
This is how our Lonely Planet Operating System team of 20 people works. It’s broken into 3 major groups of people, each working on their part of the project, or their ‘thing’. We have one big long bench where 8 developers work mostly in pairs, and near by them are some of their primary customers, the SMEs. We moved all the product, planning and generally loud talky people away a little bit. These guys are not far away, but it’s a big improvement from when they were dotted among the development team. There are a number of small meeting rooms and a dedicated quite working space with a few development machines and whiteboards etc. Finally there is a dedicated planning / war room which has whiteboard paint on all the walls, it has a constantly changing view of ‘the plan’, ideas for future development and the day to day agile board on it’s outer wall. There is of course regular communication between all three groups, but the primary and constant communication is restricted to on topic conversations within each group.
So small groups of people working closely together, quite spaces and shared spaces. You might need to think carefully about how to break down some of your big ‘things’ to ensure the number of nodes and contracts is sensible; and that, leads nicely into my next theme: Communication.
This is a sneak peek at some of the ideas I’m going to talk about at Agile Australia 2011 in June (I’m open to ideas and feedback of course)
The core of Agile is all about communication. Its routines and rituals encourage teams to communicate and plan as well as tackling their issues and problems as they share lessons from their achievements and failures. Our physical environment, communication culture and our attitude to multitasking and distractions are less obvious levers which can have a profound impact on our teams and how effective they can be.
In my mind the whole Agile movement is really just one part of answering our key question, how do we build great software that delivers real value ? I think the answer boils down to creating the right team, process and environment; this requires four things.
“Be obsessive about only hiring the best talent” – Me
Motivate them through “Autonomy, Mastery and Purpose” – Dan Pink
Recognise that “Culture eats strategy for breakfast” – Peter Drucker
Now we come to core of my topic, something two of my heroes have been talking about since they wrote Peopleware in 1987:
Have the “Correct environment, method, and structure” – Tom DeMarco and Tim Lister
Agile is all about communication; routines and rituals which encourage teams to communicate, tackling issues and problems as well as sharing and learning from success. Our communication culture, physical environment and attitude to multitasking and distractions are less obvious levers which can have a profound impact on our teams and how effective they can be. I often have this quote from Deming rattling around in my head as I look at problems at work.
“95% of the performance of any organisation is attributable to the system and only 5% the individual”
So over the next few posts I’m going to look at three key parts of our ‘system’.
Jan Banning has captured these wonderful photographs of Government Officials in their office around the world. Take a look at them and then stop for a minute. Imagine your ideal office … what would it look like ?
There is more to software productivity than just removing distractions. Communication is equally as important. A developer may be in the zone and writing perfect code, but if they are writing the wrong code because they are isolated then we haven’t done anything to help productivity have we ?
How we Multitask and Manage Distractions.
Our instinctive behaviours remind us that our brain rejects distraction. For instance, to really zero in on a faint sound in the distance we instinctively stop moving, shut our eyes, and focus entirely on listening carefully. Your brain does not multitask when it’s time to really pay attention.
Stay tuned for some ideas and answers.
You are not a Software Engineer. You do not build skyscrapers. You do not build bridges.
You grow gardens.
You are a Software Gardener.
Do you try to plan your gardens in such detail that you know where each leaf will be positioned before you plant a single seed? Do people expect estimates (or are they promises in your organisation?) on exactly how many flowers will have bloomed in one years time? Do you have a bonus tied to that? Things that would be perfectly reasonable to plan for a skyscraper seem a little ridiculous when you are talking about a garden.
You probably have a good idea of what your garden should look like a week into the future. You might even have a rough idea of the shape you expect it to be in a year from now. But you have no idea of where each branch, leaf, stem and flower will be a year from now, and if you say you do then you’re really only guessing.
If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you. If you told me that you knew to some insane degree of accuracy how long it would take to get to ‘finished’ – I would believe you again. That’s how Engineers roll. Tell me the same thing about your garden and I’m gonna call bullshit. Tell me you are going to make it grow faster by hiring more gardeners and I’m gonna laugh at you.
So why do so many gardens fail, yet so many skyscrapers succeed? With a few exceptions, the technique for building a skyscraper is similar whether you are in Europe or you are in Singapore. Gardens do not work that way. Every garden is different because the environment it is in is different. Even gardens that are within throwing distance of each other can have wildly different soil. That is why the lowest bidder can probably build the same bridge as the highest bidder, but your company can’t grow the calibre of gardens that Google can grow.
Remember that time when someone in your company unsuccessfully used an Agile gardening methodology, and then went around saying that it was horse shit that doesn’t work? Well horse shit does grow gardens, it just wasn’t enough to save your garden. Your garden was probably dead before it started – a victim of the climate of your organisation. Were you trying to grow a rainforest in the desert? You can’t just plant the same plants as Facebook, Flickr or Twitter and expect them to take root regardless of the quality of your gardeners or the climate of your organisation.
Unlike a skyscraper, your garden will grow weeds. It will never be ‘finished’. Just because you stop spending money on it doesn’t mean it is finished. If you stop weeding your garden the weeds will eventually smother it, and soon a re-plant will look easier than a pruning. The environment around your garden will also always be changing, and a neglected garden will become harder and harder to keep alive.
In most countries, Engineers need a license to build a bridge. Gardeners have no such government-mandated quality control. Unfortunately, the quality of your gardeners is going to have a bigger influence on your gardens success than any other factor – so you’d better be good at picking the wheat from the chaff. Only an experienced gardener really knows another good gardener when they see them. Someone who has merely managed gardening projects will have no idea what they should be looking for (though they won’t know this). So if you are not a gardener, but need to recruit good gardeners, then quickly find an experienced gardener you trust to vet your candidates. You can’t learn gardening in a classroom, so remember to focus on gardens your candidates have grown before, rather than how much gardening theory they learned at school (which nearly always won’t be applicable to the climate you are growing in anyway).
The engineering metaphor has had its time in the sun, and maybe it even used to be accurate, but now it really only serves to help non-technical people have unrealistic expectations about how software gets built.
I am a Software Gardener.
So are you.
(From http://chrisaitchison.com/)
The True Size of Africa (A visualisation) – I can’t help but have a flash back to the organisation of cartographers for social equality on the West Wing.
Did The Microsoft Stack Kill MySpace ? – This post, plus the original case study by Robert Scoble is long but essential reading for anyone involved in a large technology project. If you can’t get through it because facebook, blogs, sms, twitter and the internet have destroyed your attention span then read this cheats version of the article instead, there is lots of important stuff in there though.
Tron Legacy Special Effects – Beautify imagery and effects for the movie with some insights into how they were made.
Most of the ideas we write about are well supported by research, leaders in software development and business or at the very least are well established as best practice. Instead today I want to write about a personal theory of mine, which is still very much developing but I think is important enough to share.
The training program for nearly any serious athlete these days is planned around the ‘season’ of their chosen sport, then their most important events and they work back from that to ensure they are in ‘peak’ condition at the most important times of the season. As they build up to these peaks their program will push them through a series of harder and harder training sessions, building up fatigue and forcing the body to adapt to support the increased stress (essentially driven by our fight or flight reflex).
The body doesn’t get stronger during the workouts though, it’s actually being stressed and broken down during these sessions. When an athlete stops to rest, eat and sleep the body has a chance to rebuild and adapt; because of the stress it’s been under the body adapts and prepares for the next time by building strong, faster muscles, etc.
It seems logical then that the best approach is to steadily increase the training load each session and over time get stronger and stronger and stronger. In practice this doesn’t work. Athletes stop improving, they burn out and become injured or sick from the constant stress they are placing their bodies under. There are two things at play here. The first is that by training hard enough to stress their body and cause the positive adaptation they are also building up a debt of fatigue which eventually becomes too much for the body to overcome causing sickness, injury and burnout. The second is that due to the consistent pattern of stress the body adapts, the workouts may become a little easier, but the athlete improves more and more slowly.
Enter periodisation, a process developed in the Eastern Bloc countries and now widely adopted by athletes the world over. With periodisation a year, the macrocycle, is broken into a series of blocks, often four week mesocycles which are then composed of a number of week long microcycles. Each mesocycle will include week long microcycles of training (increased stress), and most importantly a microcycle of recovery. This cyclical approach allows the athlete to stress their body, but also to have periods of recovery allowing their body to reach a new peak of performance as it rebuilds and sheds fatigue. This new peak then feeds into the next cycle, allowing them to undertake more stress, train harder and over the macrocycle increase their performance to levels unobtainable by a stead state training program.
Now let’s turn our focus to an Agile software development process; the routine and rhythms of a sprint process remind me a lot of an athlete’s training microcycle. Week in, week out we kick off the sprint, have daily stand-ups, write code, test code and have a demo and retro at the end of the sprint. Then next sprint we do it all again.
A common pattern I’ve observed with teams who adopt Agile is that around the 3 month mark they start to loose faith. At the start the buzz of something new, a different way of working and the rapid feedback and transparency let the team quickly improve their performance. But after a while the sprint to sprint performance increases slow, or even stop, and yet the team is working just as hard each sprint. Often times the team’s performance will even drop off as they grow weary of maintaing all the habits for no noticeable improvement.
Does this sound familiar to the earlier example from the athletes?
Why are intensely focused working groups (often conducted off site from your normal office) so productive and satisfying? If it works so well why don’t we work like that every day? Why is it that often the best ideas come at unexpected times, under the shower, out for a walk or on holidays for a week or two? Why do software developers seem to work so intensely sometimes and yet spend so much time going around and around on a problem getting nowhere, or surfing the web and staring into space ?
I think these things are just examples of accidental periodisation by knowledge workers and my theory is that the human brain is just like the human body in the way it can be trained and leveraged for maximum performance. While ad hoc training programs can work well for athletes a structured program will nearly always deliver a better, and more importantly consistent result. My hypothesis is that these same principles of training apply to the human brain and there are lots of practical ways to apply this for knowledge workers but I’m already overtime on this post… so I’ll save those stories for another day.
Akins has collected a wonderful set of laws for Spacecraft Design, most of them are equally relevant for other engineering projects. Just be glad that rule 40 doesn’t apply to your project.
1. Engineering is done with numbers. Analysis without numbers is only an opinion.
2. To design a spacecraft right takes an infinite amount of effort. This is why it’s a good idea to design them to operate when some things are wrong .
3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
5. (Miller’s Law) Three points determine a curve.
6. (Mar’s Law) Everything is linear if plotted log-log with a fat magic marker.
7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.
10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.
11. Sometimes, the fastest way to get to the end is to throw everything out and start over.
12. There is never a single right solution. There are always multiple wrong ones, though.
13. Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate.
14. (Edison’s Law) “Better” is the enemy of “good”.
15. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct.
18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.
19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you’ve screwed up.
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
21. (Larrabee’s Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.
22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)
23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.
24. It’s called a “Work Breakdown Structure” because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
25. (Bowden’s Law) Following a testing failure, it’s always possible to refine the analysis to show that you really had negative margins all along.
26. (Montemerlo’s Law) Don’t do nuthin’ dumb.
27. (Varsi’s Law) Schedules only move in one direction.
28. (Ranger’s Law) There ain’t no such thing as a free launch.
29. (von Tiesenhausen’s Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.
30. (von Tiesenhausen’s Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist’s concept.
31. (Mo’s Law of Evolutionary Development) You can’t get to the moon by climbing successively taller trees.
32. (Atkin’s Law of Demonstrations) When the hardware is working perfectly, the really important visitors don’t show up.
33. (Patton’s Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
34. (Roosevelt’s Law of Task Planning) Do what you can, where you are, with what you have.
35. (de Saint-Exupery’s Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
36. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
37. (Henshaw’s Law) One key to success in a mission is establishing clear lines of blame.
38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.
39. The three keys to keeping a new manned space program affordable and on schedule: 1) No new launch vehicles. 2) No new launch vehicles. 3) Whatever you do, don’t decide to develop any new launch vehicles.
40. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there’s no partial credit because most of the analysis was right…)
(source – http://spacecraft.ssl.umd.edu/akins_laws.html)
DevOps seems to be the new cool kid on the block lately, especially in Agile circles. New user groups are popping up and it’s a fashionable topic to talk about at conferences; Many of the more leading edge consultancies are working hard to establish themselves as having creditable practices in the space. Right now DevOps feels like Agile did 10 years ago.
Here’s the first paragraph from the top hit in google, it is of course from Wikipedia …
“DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA)”
… and it’s 100% wrong. DevOps isn’t a process; Unlike Agile, DevOps doesn’t have a neat set of rituals to build the habits and enable the right communication and feedback cycles – perhaps we need to invent some. There are definitely some things like co-location which help, and getting everyone coming along to one daily standup isn’t going to hurt. But, you can do those things and fail to create DevOps.
Here’s another thing it’s not, Continuous Deployment. Releasing your software regularly and having an automated build and testing pipeline is another good process, it creates good habits and it does create closer ties between your developers and your ops group; But it’s not essential to DevOps and it doesn’t ensure you’ll have DevOps.
So here’s what it really is:
- Developers caring about deployment and production systems.
- Ops caring about the development of new features.
- Developers with access to production systems, monitoring and deployment processes.
- Ops engaged with feature development from the start.
It’s about creating a team of engineers, rather than a team of developers and a team of operations folks.
DevOps is just a neat new word to describe how little companies have managed their development and deployment for years – If you don’t have many people and you don’t have lots of departments then your developers get involved in deployments, and if you’re lucky enough to have a dedicated ops person then you can be sure they will be working with the development team as well, usually on the database and back end parts of your system. In bigger companies it’s not as simple, bigger systems mean more complex platforms, more sophisticated network configurations and database clusters. As projects get bigger it’s only natural, even essential that within your engineering team there are specialist roles. UI/UX specialists, back end, API and model specialists and DevOps is about engaging staff who would have previously been part of your ops team.
Just like Agile, DevOps means taking a leap of faith and seeing how things work out. Here’s how to start, get a developer to sit and type all the commands to deploy one of your system with an ops person looking over their shoulder – I promise you they will be coming up with ways to automate your deployment by the end of the day. Next time you have a performance problem, get your ops folks to pair with the developer working on it, matching up data from your system logs and monitoring system with the active code.
Just today I enjoyed watching a ‘developer’ and an ‘admin’ working together to shave 20% off the run time of our full test suite in 30 min just by building a shared understanding of what was required and tuning the platform together.
“‘Devops’ is a movement of like-minded sysadmins and developers interested in bridging the artificial gap between our camps. It’s impossible for sysadmins to do their job without reading or writing code, and developers need intimate systems knowledge to scale their software.
The walls between us are being broken down — it’s time to start learning from each other.” – www.devopsdownunder.org
While Nigel has you thinking about how you govern your agile projects I want you to spend some time thinking about a man by the name of Melvin Conway. In 1968 he made this observation:
“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
I often paraphrase this as:
“Your system’s architecture will match your org chart”
Even with the flattest, non-hierarchical org structure the way you organise your teams, even the way they are physically situated leaves a lasting finger print on any technology platforms you build. If you have three teams which are fairly autonomously building a large system, don’t be surprised to find three different applications communicating via a series of APIs. If you have a geographically distributed team, expect to find highly modularised systems with lots of code focused on decoupling. If you have a large monolithic development team you’ll find a large monolithic application.
This is especially true of agile projects where decisions about your platforms are not taken by a command and control style group of enterprise architects but instead handed to the builders of individual components. Often when talking about org design I hear something along the lines of this … “There is no perfect org structure, so this one will do” … while I think the first part is true, take a moment to think if the org structure is going to breed a sustainable platform architecture before you decide if it will do.
“Any darn fool can make something complex; it takes a genius to make something simple.” – Albert Einstein.
Coal Marketing – Another insightful visualisation, this time via Seth Godin.
Jonathan Ive – The remarkable rise and influce of the man who has designed every major apple product since the candy coloured iMac made it’s debut.
HTML 5 and the Solar System – More and more great stuff is being built using nothing but HTML 5 in the browser – Flash … pfft who needs that old thing ?
We love the little curated lists of links on many of the blogs we read, so we wanted to do the same thing here at Luna Tractor. As a rule they will be relevant to the typical blog themes, but sometimes off topic things are just to interesting not to share.
The Angry Birds Story – I will confess to having played one or two level of Angry Birds myself. This piece from Wired looking at the development of the company and game has two important lessons to pick up from Rovio’s success. 1) Watch people using your products. 2) Distribution is really important.
Radiation Dose Chart – I love data visualisations and am quite addicted to charts like the Billion Dollar Gram from Information is Beautiful. Randall from XKCD has done a bunch of great ones over the years in his own style. This most recent one compares radiation doses from a very wide range of sources and does an excellent job of putting the Japanese nuclear issue into context.
Shuttle Discovery’s Final Flight – I promise we’ll try not to overdo the space theme here, but these pictures from the Big Picture Blog are too good not to share. Sit back and marvel at the wonder which is manned space flight.
In product and software development organisations there is very often a deep sense of needing to justify all the time we spend working on things. I catch myself doing the mental arithmetic: is what I’m doing now really ‘adding value’? This is not such a bad thing; we should be striving to create value and generate profits… But I think there is an unintended side effect. Often this desire leads to product development and governance processes that can make development feel like a carefully planned military exercise. Orderly, neat, no colouring outside the lines but probably not how you would choose to spend your weekend.
Street Performers in Trafalgar Square - People are amazing, unlock their creativity and see what's possible
A Hack-A-Thon (Fed-Ex Day, 20% time or Howhardigras) is a great way to break this culture and remind yourself that passion and invention are powerful and yet often intangible forces that really should try and tap into. Here’s how you do it:
The Rules:
1) Everyone gets 24 hours.
2) At the start everyone has to give a 1 min pitch of what they are going to try and do.
3) At the end everyone has to give a 5 min presentation of what they made or learned.
4) (optional) Beer and pizza should be served.
Simple eh! Now this is the bit where you’re going to feel uncomfortable. Don’t have a theme; don’t try and guide or cajole your crew to work on things with a ‘business value’; please, please do the opposite. Encourage your team to experiment with things that have nothing to do with their day job or write something in a language your company doesn’t use. Trust me on this and trust your people.
Having done this with countless teams I am still surprised each and every time at just what is possible in 24 hours. Sophisticated iPhone apps with backend integration finished and ready to upload into the iTunes store. Sysadmins teaming up with UI developers to overhaul interfaces based on what the admin knows from obsessively watching web-server logs. Developers learning a completely new programming language and writing significant applications with it. Product features which would never get through the rigours of a regular governance process and yet go on to be hits with internal and external users.
Allow your teams 24 hours, set them free and you’ll be amazed what they can do.
When you put a volt meter into an electrical circuit to measure the voltage difference between two points the internal resistance of the meter itself changes the circuit and impacts the reading. The best volt meters are designed to have very very high internal resistance, but in all circuits the resistance of the volt meter changes the circuit and impacts the measurement (circular yes!); in sensitive low voltage circuits where accuracy is most important the impact is greatest.
One of the agile development teams I’ve worked with decided that they would use the number of cards as their measure for planning, velocity and by implication productivity. Each iteration the cards from the last release were proudly pinned to the wall and counted. An interesting pattern emerged over a number of iterations: the number of bug cards completed went up, and up and up.
We spent a great deal of time trying to work out where our development, testing and release process was going wrong that we were seeing so many old bugs. Were we finding old issues with more thorough testing? Were the developers being lazy? Or was the work we were tackling just much tougher than previous projects? It turns out that the explanation was in fact very simple. Previously developers found and fixed bugs as part of their development tasks (this is quite normal), now they were writing these up as cards and running them across the board through the full prioritisation and QA process. Consciously or subconsciously the developers had been sent a signal that the number of cards was being measured, and thus they responded to and optimised their process to meet that benchmark. Issues which would have been fixed quickly while the developer was deep in their context now became tasks of their own, a much more expensive and unnecessary process.
Perhaps a better title for this post might be ‘Only measure what you truly wish for’. This is a topic which we’ll surely return to again and again, but I’ll leave you with a quote I write into the front of every one of my notebooks to remind me of a valuable truth.
“Not everything that counts can be counted, and not everything that can be counted counts.” – Albert Einstein.