“Code Reviews Are More Important Than TDD”
Dr. Venkat Subramaniam
Don’t get me wrong: Test Driven Development is great and it helps with a lot of things: Good quality, maintainable functionality, repeatable tests and much more. We did a survey at conferences that showed us that around 70% of all developer teams are practicing some kind of TDD but just 30% are doing regularly code reviews. Why is that? Here are some explanations why test automation is so much more common:
- It’s automated: Developers love to automate things. You can use a fancy build server and show that your code is running.
- It’s an easy to follow process: You write tests, you write the code, you run the tests. Easy to follow for each individual programmer.
- You do it on your own: There are no dependencies: Developer don’t have to wait for other developers to write tests, no social interaction is needed, the machine tells you if your code works or not.
The benefits of Test Driven Development are obvious, but here is why I think code reviews are more important:
- Better code quality: Reviewing the code by a team member can maybe not catch all functional bugs but it can catch obvious mistakes, correct bad variable, method and class naming and it improves the readability of the code (and we all know that we read code way more often than we write it).
- Learning: When reviewing code developer can learn from each other to write better code. Even intern can give senior devs a new perspective. This is also recommended practice for book writers: Read! But it also helps to understand the whole code base and not only the parts you are normally working with. You will review code from other parts of the system that you maybe were afraid to touch yet.
- Feeling better: Having another developer looking over your code before it goes into production can make you feel better. You don’t feel that you’re the only one responsible for a potential bug. There are others that haven’t seen it either!
Code Reviews with less meetings & better tools
So what’s the problem with code reviews? Why are not all teams doing them? First we should all agree that the time reviewing code is well spend! Some teams practicing a meeting every week to look at the code written the last 5 days or at a special feature. These can be a painful sessions for various reasons.
Make reviews less painful with tools.
When we discuss code in front of the whole team it can be hard for the author: Everybody is staring at his code and give comments. I’m not saying that it can’t work, but here we have the same social problems as we see with Pair Programming (and there’s just one guy looking at your code). I’ve seen people not showing up or coming with stomach problems to work because his/her code was on the schedule for the code review meeting that day.
A tool like Gerrit, GitHub, Bitbucket, Stash or Crucible can help because the author has more time to about the feedback and don’t feel like going into defense mode right away. In code review tools authors can invite other developers to participate in the online review. You see the code changes and add comments to the code. Developers with strong opinions won’t take over the review in tools that easily and others that may be a bit more shy have a lower barrier to participate in the review. But the same rules apply also for online reviews: Be gentle!
Make the review part of your process.
Don’t make code reviews an end-of-the-project event. Reviews can get long and boring. Keep them small. For people that already uses Git with feature branches this one is easy: If you want to merge changes back to the main branch you can create a Pull Request. Git tools like Bitbucket, Github or Stash have a visual interface to make comments. No change will touch the main branch without a review (if you want). Just make it a natural part of your process: If you have a change, it needs to be reviewed. Keep changes small so people are not afraid of reviews. A task is not done if the connected code review is still open.
Some tools also offer the ability to see the code changes in context. What’s the problem these changes should solve? Most code review tools let you connect to an issue tracker to be able to jump from the review directly to the issue.
If you still prefer review meetings do them regularly, so people get used to them. I think once a day would be best but at least two days a week. Never cancel the meeting because of too much work and try to review every change. If you can’t run through all changes split the group and rotate the group members.
Review code when it fits into your schedule.
That’s a problem with another meeting on our schedule: They never fit into our personal flow. If you do code reviews in tools you can do them whenever you got time: In between programming tasks, first thing in the morning or after the lunch break; independent from team mates and their schedule. Also: Don’t expect every reviewer to finish review your code. Someone will always not make it within one or two days or gets sick. Have a rule that you invite maybe 4 people and mark the review as finished when 2 people have approved the review. Just make sure that it’s not always the same people that are not reviewing the code.
Products these days are complex. If you think about how many people are involved to gather requirements, to discuss priorities, to write the software, maybe create hardware, to test each feature, to come up with a great design and to operate or distribute the products… not talking about marketing, finance & controlling here… Building great things is a team effort nowadays and communication is the key for success:
40% of creative teams productivity is directly explained by the amount of communication they have with others to discover, gather, and internalize information. [source]
How does information flow? Another statistic tells us that 70% of the information exchange is driven by the team lead and only 30% inside the team. The boss is a bottleneck: Information should flow freely inside the team. How can we change this situation and foster more collaboration inside and in between teams? Here are my thoughts for a collaboration revolution:
Problem: Physical isolation
A lot of workspaces are not designed for collaboration: A hallway with some doors left and right… How should information flow here? Open space offices foster collaboration. You can see who is there and start a direct conversation. Putting up open workspaces with couches, arm chairs or bean bags are great to work somewhere else but at your desk and have spontaneous discussions. When I’m in the Atlassian office in San Francisco I use these places to show that I’m not working on a very intense task that need all my concentration but be ready to be disturbed. On the other hand you should have mechanisms to show people that you don’t want to be disturbed because it will destroy your current flow of work. Some teams are indicating that by using headphones, even though they’re not necessarily listen to music or having a dedicated person on the team that is answering questions for the whole team (doing kind of support).
There is also a need not to isolate specialist. We know that cross functional teams are a great idea. Having a designer in the team when working on the new user interface is making decisions fast and understandable.
Problem: Communication barriers
Three communication barriers are making communication hard: Places, people and timing.
Places: It’s hard to get the right information when you work in a remote team, in a coffee bar or at home. But if you want great people, you probably won’t find them in your town and it’s hard to move them because the competition are already offer them working remotely (do you hear me Marissa Mayer?).
People: Employees keeping information on their hard disks, in Emails or in their own heads. Information are exchanged on hallways not accessible for all employees.
Timing: Meetings are a killer for individual productivity. They have to fit in everybody’s schedule. We also don’t work synchronized anymore! When someone is doing a coffee break another one just works on a great idea she just had at the same time.
We use our collaboration platform Confluence for tearing down the communication barriers. We once had a post on Confluence where our support expressed their feelings how unhappy they are with the work load and conditions. Independent of place, role and time zone other employees from Atlassian were commenting on that post adding arguments and trying to find solutions. After one week we put together a program for better work conditions in our support. We wouldn’t have accomplished the same results by inviting stakeholders to a local meeting.
Also chat is helping a lot when hitting a timing or place barrier. One team can start a conversation in a chat room during day time on this side of the globe and another team on the other side can join the conversation 12 hours later during their day time.
Problem: Foggy goals
If goals are not clear, how can we work as a team? I’ve been working with yearly goals that were obsolete after 3 month. But there was no mechanism to redefine those. Also I was missing a frequent check if I’m on a good way reaching my goals or on changing tactics how to reach those . I’m now doing a bi-weekly check on my 3 month goals that reflects our yearly team goals. Goals can be changed easily if the company focus changes.
Goals should also be transparent. What’s the reason that I don’t have the possibility to find out the goals of other team mates and other departments? It’s so important to align your goals to those other teams have.
Problem: Impersonal environments
Definitely the most important part of the collaboration revolution. If we have a good personal relationship to our team mates we know our strength and weaknesses and how to effectively get the work done! But more important: If you have friends at work it’s so much more fun. So what can we do? First have a good onboarding system. At Atlassian everybody needs to write an introduction blog post in their first week. People can make comments on it and learn some personal things about the new employee.
When your organization is growing it’s hard to know everybody. Hubspot is trying to solve this problem with an electronic wallboard in the hallway, showing faces of people and their name. Watch the video and grab the source code.
A few weeks ago I did a presentation on this topic. Here are the slides and a video on German.
The last 48 hours people were tweeting their tech horror stories in five words. This really made my day… but the scariest thing is: I’ve heard most of this quotes in real life! These are my Top 20 tweets:
My nephew creates web sites #fivewordtechhorrors
— Jason Bock (@jasonbock) December 11, 2013
“Who wrote this?… Oh. Me.” #FiveWordTechHorrors
— Liz Keogh (@lunivore) December 11, 2013
Yup, We Need Another Meeting #FiveWordTechHorrors
— Dion Almaer (@dalmaer) December 11, 2013
Weird. That worked in staging. #fivewordtechhorrors
— beerops (@beerops) December 11, 2013
It is only test code. #FiveWordTechHorrors
— Martin Thompson (@mjpt777) December 11, 2013
We are switching to PHP #FiveWordTechHorrors
— Viktor Klang (@viktorklang) December 11, 2013
“It works on my machine” #FiveWordTechHorrors
— Johanna Rothman (@johannarothman) December 11, 2013
“It’s too complicated to test.” #FiveWordTechHorrors
— Andy Hunt (@PragmaticAndy) December 11, 2013
We have to support IE6 #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Oracle has acquired Sun Microsystems #FiveWordTechHorrors
— Steve M (@shmick) December 11, 2013
The coffee machine is broken #FiveWordTechHorrors
— Arnaud Héritier (@aheritier) December 11, 2013
We’re going to use SharePoint. #FiveWordTechHorrors
— Simon Brown (@simonbrown) December 11, 2013
We need a Devops team #FiveWordTechHorrors
— Gareth Rushgrove (@garethr) December 11, 2013
— Andres Almiray (@aalmiray) December 11, 2013
It can't be tested yet #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Let’s update the stored procedure #FiveWordTechHorrors
— Sam Newman (@samnewman) December 11, 2013
Fixed it with global variables #FiveWordTechHorrors
— Seriouspony (@seriouspony) December 11, 2013
95% done, you finish it. #FiveWordTechHorrors
— George Dinwiddie (@gdinwiddie) December 11, 2013
We can add security later. #fivewordtechhorrors
— James Turnbull (@kartar) December 11, 2013
We wrote our own encryption. #fivewordtechhorrors
— J Wynia (@jwynia) December 11, 2013
“The original developer left us.” #FiveWordTechHorrors
— Lou Acresti (@louroboros) December 10, 2013
git push -f origin master #fivewordtechhorrors
— Jonathan Nicholson (@jonathanichlson) December 9, 2013
I guess every company wants to have productive and efficient employees that comes up with bright ideas and can execute, track and deliver them. This employee should smile all the time, doesn’t need a lot of attention and works always for the company goals. This is a nice wish, but in reality we need to do more to make sure that every individual developer gets freedom, runs in the right direction and is happy in what he’s doing. These are just 6 random things that will boost the performance of knowledge workers like programmers:
1. Set monthly goals & check frequently
I never understood the thing about annual goals. 2 month after I agreed with my boss on them some were already obsolete and didn’t make sense anymore. Things change too fast nowadays and annual specific goals makes us inflexible. Sure, we should have bigger goals and track the way that leads to them by agreeing on short term goals. I can concentrate better on a goal when it’s smaller and the due date is closer. It’s like running a year long sprint in Scrum. Doesn’t make sense! But: Track also your long running goals (like Epics in Scrum).
Short running goals lead actually to frequent checks with your boss or even better: with your team. You should meet weekly or bi-weekly, discuss the current state of your goals and update them. It worked for some teams to define team goals and personal goals (1:1 with your boss). Try to avoid mixing those.
2. Establish short positive feedback loops
If someone did a great job, you should have an easy mechanism to appreciate that publicly. That way people think feedback isn’t something awkward. We at Atlassian can give Kudos to other team mates just by raising a ticket in JIRA. The talent department sends a small gift with a card to the receiver of the Kudos. Everybody at Atlassian can start this, so it’s very lean and effective.
3. Freedom for developer
All knowledge worker know that innovation doesn’t happen between 9am to 5pm. Give people freedom to work wherever and whenever they feel motivated and productive. Give them the tools they need. Give them time to work on their innovations. At Atlassian we have tools like 20% time and innovation weeks. A special time where our developers are not working for planned features but on own innovations that improves our products or tools that makes us more productive. It motivates the developer to work on their own ideas and show them later to their team mates and maybe integrate them in the core products. There are lot’s of examples at Atlassian where projects from 20% time made it in the product… but also some that didn’t.
4. Don’t overlook the small things
Talking about the performance of developers: It’s not always the smartest to work on a big new feature. There are so many overlooked ‘low hanging’ fruits in most products that will improve the software with less effort. My collogue Benjamin Humphrey has written an excellent blog post about this. But I want to touch on the human side for this one: If the developer fixes two of those small improvements each Sprint the satisfaction level will raise. He will get fast (and hopefully positive) feedback for the small change.
Let people know what the big company goal really is. Let them know how good or bad sales are performing. Don’t treat devs like small children and hide things from them. It’s so demotivating and costs so much energy to hear and discuss rumours on the hallway or just don’t understand the overall goal. Give people an opportunity to ask questions (not just in big CEO announcement in front of 500 people). At Atlassian our founders are giving us regular updates about goals and performance in a blog post. We can comment on that and ask if we don’t understand a new goal. It’s important that everybody in your organization is on the same page with the companies vision.
6. Forget about specialists
I’ve been working for a company that was hiring specialists. I never understood why. Yes, of course we can all do special things in the team: Someone speaks fluently SQL, the other one is good in presenting and another guy is good in design. That shouldn’t stop us to try out other things. The specialist thing is getting weird when people don’t feel responsible for other peoples specialism. I’ve argued with some people in my career that didn’t feel responsible to do support or getting the requirements from the customer, just because it was someones else’s responsibility. Here is what’s really important:
“Go build awesome shit”
Mike Cannon Brookes (Atlassian Founder)
No more and no less!
Ideas drive our businesses. We all know that it’s important for our products to fill them with innovation so the users love to use them and we differentiate us from our competitors. But we as knowledge workers also have some small ideas. How often did it happen to me, that I was thinking hard about a solution for a problem at work, went home and had the answer somewhere between leaving my desk and entering the office the next morning.
So let’s face it:
You can’t plan for really good ideas
Where ideas happen
I’ve just been on vacation for a few weeks. Before that I had so much work stuff in my head that I couldn’t focus on new blog posts… But just by sitting at the pool for a few hours opened my mind and I had lot’s of ideas for new posts or talks. I think everybody has experienced this kind of innovation boost. I’ve spoken to a lot of people and this are my TOP 3 places for innovation:
Under the shower
I don’t know what it is? But all people I was talking to agreed with this one.
In the gym
I use to listen to technical podcasts or watching presentation while running on the treadmill. My mind fades sometimes away from what people are saying and create it’s own innovation path.
No matter if I just sit at the pool, the ocean, the river, drinking wine at a nice spot or just lay a little bit longer in the bed: I come up with new ideas that I want to try out when returning to work.
Those are not magic places where a fairy appears and whispers you the innovational idea into your ear. I’m normally starting thinking about a problem I have and float with my ideas.
But: Did you recognize something here? None of these place is really where I get my work done. It’s most of time when I’m away from work.
Innovation doesn’t happen between 9 & 5
So here is what you might do if you want your employees to come up with new awesome ideas:
– send them on vacation
– give them the freedom to work whenever they want
– maybe encourage them to do some work out
BUT: THERE IS ONE BIG PROBLEM WITH THIS APPROACH: How do you capture the idea?
It happens so often to me… I have a great idea in the gym but when I return home I’ve already forgotten it. I used to carry a notebook around with me but now I capture my ideas quickly with Evernote. I have it on my phone (for the gym and vacation) and on my laptop to look through my ideas later. But I guess any online synching note program will do the job. I don’t know how to solve the shower situation…
Make your ideas social
It’s just my idea… Is it good?
What looks to you like a brilliant idea might look very stupid for others. At Atlassian we use the blog functionality of Confluence to share our ideas with the whole company. We have a very collaborative culture, so people write lot’s of comments to your post. In about 24 hours I can get so much feedback for my idea (especially if I was totally wrong).
The path to good ideas
- Find your innovation places (It’s not your desk)
- Start thinking about a problem or possible solution
- Write it down
- Spread your idea and get feedback
So it’s September and the conference season starts again. I actually wanted to do a little bit less travelling this autumn, but looking at my schedule for the next months I can forget that. So if you want to meet me here are the places I will be:
10th – 12th September: Oslo at JavaZone and Atlassian User Group
25th September: Berlin at Berlin DoSE
At Berlin DoSE I’m gonna do the closing keynote about “Kick-Ass Software Development (TM)”. After the talk we gonna throw some drinks for the attendees.
1st – 3rd October: San Francisco Atlassian Summit
That’s very exciting for me, because I’m gonna speak for the first time at Atlassian’s own customer conference about ‘How to make good teams great’.
19th October: Kiev at Javaday
The Javaday in Kiev is a community event and I’m gonna try to Kick-Ass there with my presentation.
21st – 23rd October, Zurich at Jazoon and Atlassian User Group
I will be at a user group meeting on the 21st and talk at Jazoon about how to do better software development by kicking ass one day later.
7th November: Wiesbaden at Tools4AgileTeams
I will talk about how teams can use Git for better development workflows at Tools4AgileTeams.
11th – 15th November: Antwerp at Devoxx
I guess Devoxx is Europe’s largest software development conference and I will do 2 presentations this years. One on Kick-Ass Software Development (TM) and another short talk about not using Git!
21st November: Frankfurt JIRA & Confluence Community Day
I’m gonna do the keynote at the Community Day about the Collaboration Revolution in companies.
I still have some options out there and I will probably do some Drink Ups in some of these cities to meet with customers. Contact me if you would like to meet. See you somewhere this Autumn!
I was recently asked to join the program committee for a medium size conference in Switzerland named Jazoon. I had to review around 30 submissions and found out, that this is a really tough job. I learned so much about helping the program committee to decide if your talk should be accepted for the conference program. So here’s what I learned (and have to apply to my own submissions in the future):
Picking a topic
- look around what is currently hot at conferences
- the program committee is trying to find new and unique topics like “functional programming”. Older and not so funky topics like OSGI or SOAP are more likely to be rejected
- check the tracks and themes of the conference. Your submission should fit into those… the more the better
- be focused but not too focused – the topic shouldn’t be so broad like “Agile Development in practice” but also not like “Agile Development for left handed build managers” (I know this is a stupid example, sorry for that)
- should be interesting like “The dark side of project management” – there are so many talk submission (Jazoon had over 200 submissions for 50 slots) and compelling titles stick in the mind of the committee and the attendees
- the title should contain the information what your talk is about. Don’t shy away from buzz words like Agile, Scala Testing… so you don’t leave people totally in the dark just to sound cool (like “Huston, we have a problem”)
- a “list talk” is always great like “10 things: How to write a killer submission for conferences”
The abstract is the hardest thing and the the most important thing for the program committee. Always think about what the audience needs for deciding if they should go to your talk or not. So here are things that your abstract should contain:
- what is the problem you’re trying to solve
- why is your solution interesting?
- tell a little bit about your solution – This is the most common problem I faced when reviewing submissions. The program committee has to decide whether your solution is interesting and new for the attendees or if you will tell already known things.
- don’t tell everything about your solution; You need also to surprise people in your talk 😉
- don’t make it sound like a product demo
- try to close with why you think people should come like… “We will present tools and teaching material that you can take directly into a school or programming club to get kids to start coding.”
- Be concise: Your abstract should be maximum 250 words
- check the grammar: Show your abstract to someone else, especially if you’re not a native speaker like me!
- 1-3 paragraphs
If you’ve already have spoken at one or more conferences tell this fact to the program committee. There is often a field you can fill out like “message to the committee”. If not: consider to add it to your bio. Sounds lame? Maybe, but the committee knows that you’re able to do a presentation and other conferences have already excepted you in the past. If there are videos of your talks, send the links!
If you don’t have experience in public speaking, take a video cam and shoot a 5 minute video of you presenting. Add the link to your submission!
And Now: Good luck and see you on the next speakers dinner 😉
I never understod why companies are building a strong management driven culture and destroy the creativity of the developers. We need freedom to build awesome software with great quality fast. That’s why some people see us as the prima donnas in a company. When our management gives us the freedom of choosing our own tools and processes we have to turn that trust into productivity and quality. We have to find a great development culture that we live and breathe every day. Culture is so important:
“Culture eats strategy for breakfast”
These are my 7 points how to build a great development culture and give the power back to the developers. It may not be complete but things can’t go really bad if you can follow these things:
1. Find a way to deal with customers
Customers suck! They find all the bugs and call you in the middle of a great pair programming session and destroy your mojo. It’s not a good solution to let just the support or some product managers deal with customers. Try to send developers to your users. Let them see how the tool is used that they are creating day in and day out. It’s not easy to find the right balance between “Getting things done” and learning the needs of the business. But your culture should make this absolutely clear: Everybody has to be at the front line and know what’s going on in the real world. Do daily stand ups and discuss customer requests. Meet customers frequently. This gives us the power to build the best software from a technical and a usability stand point.
2. Don’t be evil to your software (and don’t let other people tell you to be)
We all had this situation: Your boss or your customer asks you to do a quick hack. Just a small change that will drain your quality or it will just look bad. We want to please the people that are responsible for our payment. BUT: We have standards. We have to deal later with the technical dept. We have problems with scaling the software. Stay true to your principles. Say: NO! ..and at the same time try to educate your boss or your customer why this is a bad idea and why it’s important to hold your software development values high.
3. Show people why they are important
Why do people go to work every day? Yes, to earn money. But this kind of motivation is losing more and more traction nowadays. If you earn a certain amount of money, rewards doesn’t motivate you to be more productive in the long term. People want to get appreciated by humans for what they are doing. Not just once a year when you have your yearly conversation with your manager. Do it whenever you think: “Cool, that was great”. I had a great experience when I’ve send one guy from the team to the customer just to see how they use our software. He came back and said: “They really are productive using our stuff. They love it”.
4. Do your own thing
There are so many good ideas out there in the world. Don’t follow all of them. You should just pick those, that makes sense for your team. Don’t try to implement Scrum by the books. See what works, what doesn’t, get your own ideas and try them out! Don’t follow blindly another Guru that is trying to teach you the right way.
Developers should have the right to decide what works best for the team. But we’ve been studying for years, we fix problems every day and can’t decide how we work best? Developers should be treated like grown ups, not like 13 year old school boys. If we think a tool makes us more productive, let’s buy it!
5. Learning is everybody’s own responsibility
The company can send you to conferences or workshops and they can buy you books. But lets face it: You won’t learn anything from a 45 minute talk or if a book is just laying in the shelf. You have to take action! Nobody can help you with that, it’s your own responsibility. And we have to learn if we want to know what’s going on. Yes, there are some things to do together like coding katas or brown bags. But also here: It’s still the decision of each employee to take that power and use it for something good.
6. Change is the only constant
Do I have to say more? Think constantly about what sucks in your software development and change it! Don’t be afraid of new things or to pull the plugs on things, that have just currently been implemented but really doesn’t work out. Change and improve constantly.
7. Focus on quality and dev speed
Depending on the product you’re developing one or the other is a little bit more important. It’s sometimes hard to find the balance: If you put too much effort in quality, your deliver speed will slow down. If you’re delivering like a maniac, your quality will drain from that (you will see it in the long run). It is really important to always keep thinking about these two factors and to talk about them in your development team.
Credits for the pictures:
Couple designed by Jens Tärning from The Noun Project
Electrical Shock Warning designed by Travis Yunis from The Noun Project
Blindfold designed by Luis Prado from The Noun Project
Approve from The Noun Project
Interchange designed by Laurent Patain from The Noun Project
Speedometer designed by Olivier Guin from The Noun Project
I just got reminded, that I work now for almost 2 years for Atlassian as an Ambassador. First I was very concerned working for the dark side (the Marketing departement) from a developers view. But it turned out that it’s pretty cool to be a bridge between the 2 worlds. Even though I would love to do more coding I enjoy the job so much! I know that a picture says more than 1,000 words so I created a video with a lot of pictures… what would be worth a 100,000 words. So here is my life the last 2 years in 3 minutes.
I learned a lot the last 2 years, more than I can put in a blog post. But here are some things I discovered to be important.
5 tips for becoming a kick-ass evangelist
1. Create slides that rock
Yes, your presentation style and your message is the most important think for a talk…. but a lot of people look at your slides and watch them later on slideshare. (6,600 developers saw them on a screen, 30,000 on slideshare). I discovered that creating great slides is my thing and I can spend hours working on just the details.
2. Practice, practice practice
…and if you think you are good and are sick of trying your presentation again: It’s time to practice more! Yes it takes one hour to do a total test… but if you speak in front of let’s say 300 people you better be really good prepared and don’t waste 300 developer hours!
3. Prepare your travels
Travelling is sucking your performance. Use time in buses, planes and train stations. I prepare my travel by downloading everything I need to get the job done on my laptop. Internet sucks normally everywhere, but at home or in the office. I normally do translation stuff, blog posts and abstracts for talks during travelling.
4. Make connections
Instead of waiting for the Internet to work at a conference, use the time to talk to people. Hang out in the speakers or attendees lounge, go to the speakers dinner and attend conference parties. I met so many awesome people everywhere I go, it’s amazing. The conference world is small and you will definitely meet people elsewhere. Try not to be shy to talk to your idol…
5. Use the power of social
I was amazed how a message can spread when I wrote my most popular blog post “Don’t use git” (20,000 views in one week). I don’t know which channel was the most successful or which retweet started the domino effect. I just post a new blog on LinkedIn, Xing, Google+, Twitter you name it. And I guess I’m missing also some opportunities, because I’m not aware of them.
Here are some statistisc from the last 2 years:
- I created 28 different slide decks
- I delivered 40 presentations
- I spoke in person in front of 6,600 developers (incl. 2 conference keynotes)
- I reached 4,000 online video views
- and 30,000 on slideshare
- I wrote 3,000 tweets
- I did 115 personal blog posts
- I had 70 flights
Thanks Atlassian for creating my dream job and my kick-ass team for helping me becoming a better ambassador!
Sometimes you don’t know where your team sucks. Here are some smells that can destroy your team culture:
1. Non Coding Architects
If you have these type of job position in your organization you should really think about getting rid of it. The team should define the architecture together. If it comes to cross team architecture, send one or two people from your team to a meeting with other teams. It’s just a waste of resources to have a guy that makes the theoretical discussion that got later overruled by the reality.
2. Committee Driven Development
Some organizations have a committee of stakeholders that decides what to do next. This smells like you don’t finish things probably. You run to the next project without finishing up the old one. If you have delivered a new feature or even a project we all know that the real work begins after that. You need to fix bugs and improve the new feature by collecting feedback from your customer. Involve the team in decisions not just a committee!
3. Developer Primadonna
Do you have a primadonna on your team that thinks technology decisions are more important than customer features and works on implementing the newest framework which is not planned for this sprint? These ego manias concentrate more on the solution then on the problem (if there is a problem at all!). Look out for those guys, they destroy your team culture. Attention: Sometimes it’s hard to distinguish between a primadonna and a passionate developer.
4. The Perfect Software
You have to release one month later, because the software is not ready? You need to test more? You want to make the feature to be perfect? Looks like you’re afraid to release your software! It’s not that hard anymore to fix bugs after a release: You don’t have to send disks around, just push the changes to the servers or have the possibility to auto-update a desktop application. Concentrate more on deliver things than deliver perfectionism.
5. Quality is the job of the QA
In bigger organizations you have a QA department which is testing the software. Developers think that bugs got found by the QA and they just have to fix them. WRONG: It’s the developers job to make sure there are no bugs in the features! That’s why testers should just help with testing, creating test data and maybe help with automation. Quality is everybody’s responsibility. The developers should be accountable for their work!
6. No Shared Vision
The team has a different or none opinion how the software should look like in one year. Start asking around in your team if they have the same vision of the product. You all should have the same goal, otherwise you can’t be passionate about what you’re doing every day. You know if you’re back on track if you could send every team member to a board meeting or to a customer in order to talk about the future because you share all the same vision.
If your software has a lot of features and it’s very flexible, but hard to maintain you probably suffer under Featureritis. If you fix something in one end you brake something in another end. Maybe you can’t say ‘No’ to your boss or your customers. Please try to concentrate to do a few things right than doing a lot of things just alright. Try to branch your product and learn to say ‘No’ , but maybe you’re also missing a vision (see point 6)?
8. Addiction to Final
Your team can’t estimate anything until everything is sketched out in detail. Of course, they should know the whole story but they should also be able to estimate parts of the story. If this is your problem you’re probably still in love with waterfall. Gain confidence inside your team that you just concentrate on a small feature set right now and see if the rest is really needed at the end.
9. Legacy Team
You still stuck with the same process than 5 years ago? You haven’t changed your development tools in years? Looks like you are afraid of change. If your team becomes legacy and can’t see the problems anymore or don’t know how to change things you should do something. Software development has changed dramatically in the last 5 years, tools are in the cloud, we have the technology to release quickly and working from home to get things done. Get out of your comfort zone!
10. Process after process
You have too many restrictive processes if you need a signature to start with a feature. If you just added some getters and setters that has to be reviewed before the deployment or you your cool new idea will take 1 week of development but 2 month of justifying. These processes are killing your development speed and stopping you from doing great work. You should just switch some processes just with rules to follow.