The development can be driven by a lot of things: TDD (Test Driven Development), MDD (Model Driven Development), FDD (Feature Driven Development), BDD (Behavior Driven Development) and much more. Do we really need a new kind of development? Yes! All other forms are describing the workflow during the development. With Blame Driven Development just the result is important! How a single team member reaches the result is not defined and can individually be chosen. Blame Driven Development encourages the competition between coders. The goal of BDD is to frighten programmers not to be the worst one with the most mistakes and bugs.
How does Blame DD work?
Here are the rules:
- Every developer has a personal account of finished story points.
- There is just one developer responsible for a user story. The finished story points per sprint gets added to his account.
- If somebody finds bugs in a finished user story some points got subtracted from the authors account.
- Instead of planning the sprint with an average velocity of the last sprints the team plans double as much points for the next sprint. That encourages people to work harder and most likely someone can be blamed at the end of the sprint for not reaching the goal.
- The developer with the least amount of points at the end of the sprint has to explain at the next board meeting why the development is so slow.
Here is how you implement Blame DD
- The customer or product owner is just allowed to write the story with just 140 characters. If the story hasn’t been implemented to the customers satisfaction story point got subtracted from the programmers individual account. This encourages the coder to be creative and he need to think more like the customer. Developers that are practicing Blame DD are understanding the customer much better. In addition to that, the coder fears to do something wrong and that pushes him to a better performance.
- The Scrum Master reads out loud the reached points for every programmer during the daily stand. That motivates the individuals to become the best developer in the team. Pro Tip: Doing the Stand Up in military style let the team members understand that it’s not a game and the development is a critical part of the business.
Reduction of Points
- Testers are called inspectors. They maintain a checklist and are subtracting a point for every found bug.
- You can also use one person as a code inspector. He is allowed to subtract points for bad variable naming, not folling coding conventions etc.
- A good ratio of inspectors to developers is 1:1
- It is also possible to have negative points (this is actually the norm in Blame DD)
- Every subtraction of points should be discussed in the daily stand up. It should be possible to blame somebody else for the mistake.
- If a bug is found in the production system, everybody has to stop working and find the guy who is responsible for the bug. He will be blamed on the web page publicly. It is not so important in Blame DD when the bug actually will be fixed.
Pro tips for Blame Driven Development
- If you reached a certain amount of story point for a sprint you should concentrate to find bugs in team members code.
- Use a tool that checks in the code under a different name. Just implement an infinitive loop and merge it into the main branch with the name of a team member. It’s so much fun to see people trying to defend themselves in the daily stand up.
- Don’t do pair programming. It has been shown, that the pair programming partner will smuggle in buggy code when you just visit the toilet for 5 minutes.
Fear is such a good motivator for pushing people to better performance. Let’s blame the ones, that are not performing! I love to hear your experience or ideas about Blame Driven Development. Use the comment function to give me feedback and share your thoughts with the big Blame DD community.
In my last blog post I was mentioning 6 arguments why you shouldn’t use Git. While 5 arguments were obviously meant to be sarcastic (who can really think that slow operations like searching the history in SVN can be an advantage) there was doubt about one argument that can be tricky:
Git destroys the idea of continuous integration
In Git you are using branching heavily. Let’s assume everybody’s working on feature branches. Then somebody is renaming a widely used interface or class and checks the code into the mainline. If you don’t integrate your feature branch early this can result in lot’s of conflicts.
Some people favor solutions with an integration branch. People integrate the changes from their feature branch on an integration branch. If the CI-Server has build the software successfully and all tests passed, the changes get automatically pushed to the mainline. That way the mainline stays always deployable and green. I don’t like this solution: The integration branch is basically the mainline. But if a build fails, it is not so important to fix it. Not my understanding of continuous integration.
I stil prefer the SVN statement: “Commit early, commit ofter” what should be translated for DVCS into “Push early, push often”.
Solution 1: Making the mainline the communication point again
Switch from SVN to Git and work as you have before. Don’t branch, just push your changes to the mainline on your central repository. You still benefit from fast history searching, offline capabilities and much more. Just beware that if you once started with Git, you’ll probably come to use also the awesome branch features, that drags you into a different workflow.
Solution 2: Promiscuous Integration
Martin Fowler has written a great and much more detailed blog post about Promiscuous Integration. Basically people talk about changes and integrate the changes from feature or personal branch to another. The way changes got also continuously integrated in each others feature branches. When it comes down to pushing changes back to the mainline, you won’t experience lot of merging pain: Changes have already be integrated. Martin is pointing out, that this requires communication between developers and this can go wrong. There is no clear rule which changes you should integrate into your personal feature branch.
My favorite solution: Feature Toggle + Task Branch + Automatic Push!
With Feature Toggles you design your software that you can turn your feature on when it’s ready. When currently developing the feature is usually off so you can deploy the software immediately. A feature can consists of many tasks. I like the idea to have a branch for each task and push changes to the mainline when your task is done. I assume a Task Branch doesn’t live longer than 2 days. That way you still continuously integrate your changes and work focused on your branch.
You could combine this with a feature Atlassian has build in their Continuous Integration Server Bamboo: Automatic Pushing. If the mainline changes and the build went good, Bamboo is trying to push the changes automatically to your task branch. That way you have always the latest changes in your branch. I guess there is also a plugin for Jenkins available, I just couldn’t find it 😉
In my opinion this is the best of all solutions: The mainline is your communication point, you recognize conflicts very early, merging is not to hard and you have done some things to keep your mainline up-to-date and your builds green.
Another thing that your CI-Server can help you with is running a build of a potential merge. Before merging for real you can see if your build will succeed or not without pushing your changes already. Jenkins with Gerrit or Bamboo with Stash can be set up for such a workflow.
These are just my thoughts. I would like to know what your experience are with CI and Git. What works for you in your organization?
Everybody keeps telling you that Git is better than Subversion. You keep hearing Git has better workflows, offline capabilities and is faster. But should we really jump on every new technology that is coming around the corner? Your source code is the heart of your software developement and you want to store it with a tool that is working. Here are 6 reasons why you shouldn’t use Git at work.
1 – Git destroys the idea of Continuous Integration
Git encourages you to use branches for your development. But when you work for 1 or 2 days on your branch, you’re not continuously integrate your code changes with those from your co-workers. You don’t know if someone changed something important in between that collide with your changes. And if you want to have your build server automatically build your development branch you need to copy the project for each new feature branch.
2 – Developers can be offended
SVN has this great feature that if you merge a branch to the trunk you lose all commits of the branch. This is great because the developer that has merged the changes is the one that is responsible for the changes. The dev manager can not blame you for a bug. Git keeps all the commit information from a branch when merging to another branch. You can blame the programmer directly. There is no technical protection for developers anymore.
3 – Git destroys the team experience
With SVN merging a change into the trunk is a real team experience. When you see conflicts you have to talk to the two developers that have changed the same code and find a solution. Because of the fact that merging with Git is different you end up with less conflicts and less possibilities to discuss the code changes directly with co-workers.
4 – Developers have too many options
1. You merge your local changes with the trunk on your machine.
2. You commit the changes.
I will not mention the second workflow (branching) because there are lot’s of discussions not to use branches in SVN. We have one simple workflow that everybody understands!
Git gives you the opportunity of lot’s of different workflows you can adapt and even combine: Having a Gatekeeper for your main branch, do cherry picking or let everybody pull and push to everybody’s development branch. What a mess!
5 – Git makes people work overtime
Subversion requires a server to search the history, create a branch or commit code changes. Git stores the wholes repository on your hard disk (what a waste of disk space). This makes it possible to work without network connection with the same possibilities as if you are in the office and connected to your SVN-server. It’s the perfect argument for your team lead to ask you to work over the weekend from home to hit the deadline of the current project. Don’t use Git and let this happen!
6 – Git is unsocial
Subversion gives you time to socialize when creating a branch, checkout a branch or even switch beween branches. You get some time to chat with co-workers, go to the kitchen and grap a cup of coffee or to write comments on facebook. Git changes the game for the worse: Due to the fact that you working just on your hard disk to do all this tasks in Git, it is faster and you lose the natural social time. It’s good for your dev-manger but bad for knowing what’s going on.
It is pretty clear that we shouldn’t use Git at work. Why should we change at all? SVN is a mature technology that has been around for more than a decade. There is no reason to change to a just 8 year old repository technology. Let’s face it: It’s great for open source but in a corporate environment offline possibilities and advanced workflows are not so important. We have been working for ages with centralized version control system. Think about the knowledge that is in the SVN community. Some people will be out of jobs if all companies switch to Git.
Don’t let that happen. Don’t use Git!
UPDATE : Did you git it?
Due to the confusion people have whether this article is meant to be funny or sirous: I love Git and I think it helps teams to do a better job. It solves a lot of problems that we have with SVN. Don’t let our children grew up in a world of Centralized Version Control! Just to be sure you realize that this is just a sarcastic blog post. Hope you had some fun reading it!
Finding people that can kick ass (if you give them the freedom to do so) is not an easy task. Kick-ass developers are not the norm. They constantly think how to improve things, they are passionate about what they’re doing and they have brilliant social skills. How can you find these special kind of people?
At Atlassian we want kick-ass developer to find us. So the first step is to raise some interest in Atlassian as developers paradise. We need to be honest when doing that. If the right candidate has found us, we don’t want to loose him again when he finds out that we didn’t tell the truth about working at Atlassian. From 77 applicants we hire one.
Spreading the word
We try to attract people by giving them holidays before they even have started working for us. We want people to be fresh and prepared for the job so we give them a voucher for spending a weekend in a hotel with the family. We also encourage our developers to speak at conferences and tell other developers how awesome it is to work for Atlassian. Employees should also blog about their cool framework they are working on, what they learned by using a new technology or just what fun side project they’ve created. It sounds more honest and real if our developers tells that stories to possible candidates.
It is cheaper for us to make people find us instead of trying to find talents through traditional job offers. We got the best people from recommendation from other developers. That’s why we’re giving everybody a flight to a destination of their choice for a recommendation that we have hired.
Finding the kick-ass genes
On one hand you need a system that scales, on the other hand you want to look at each candidate if they have some kick-ass genes. We have developed an online coding test for candidates. Instead of looking for right or wrong answers we’re trying to look for good potential. So if we see some innovative solution to a problem that don’t lead to the 100% right result, we are still interested in speaking to the applicant. One of the first interviews the candidate is doing is with a technical person. If we found a good developer through interviews and pair-coding sessions we are checking if the candidate fits into the Atlassian culture. This is the most important thing that differentiate between a good developer and a kick-ass developer.
Onboarding and ruining developers
Here is where most companies suck: They give you a desk and a computer, maybe a 2 day course and a monthly salary. So why should you complain?
If you have put so much effort in finding the one developer that fits into your team, you should do everything you can to bring him up to speed so he can kick-ass. At Atlassian every employee is doing a boot camp where he learns how the different teams are working, how development is organized, basics about design, testing, product management and so on. The classes are happening in the morning and the new employees are working together with their team in the afternoon. After the 4 weeks of boot camp people are ready to really kick ass. Whoot!
For graduates we have a special program: They are being send to our hack house: One week at a beach with some bootcamp classes, coding sessions and lots of fun to get to know our culture. They are learning how we collaborate, our focus on shipping and what our 5 values means for us.
One of our goals is to ruin our developers so they don’t want to work anywhere else. We put a lot of effort in creating the best place to work. To find out the actual mood of our employees we’ve developed an iPad app. Employees can easily tell us their mood just by tapping on the screen when they leave the office. This way we can react just in time when the mood goes down. Our open culture allows everybody to blog about things that don’t went well. It’s amazing to see how people react and jump in to help, if somebody sees a problem.
It’s the people, stupid!
The secret of attracting and keeping kick-ass developer is to be picky in the hiring process. Great talents likes to work together with other cool devs, so they can keep learning from each other. You want to make their work environment as great as possible so other kick-ass developers will be attracted by that. Measure the mood of your employees constantly not only through apps but also through personal interviews. Give your employees the confident to complain, the best tools in the world to get the job done and the power to change things. That’s the only way they can really kick ass!
If you want to be a Kick-Ass developer you care about the quality of your software. The QA shouldn’t be responsible for finding your bugs. At Atlassian QA means Quality Assistance. For each 13 developer there is one employee working in QA. And we think this a great ratio! Sometimes QA departements see themselves as the quality keeper of the company and often they are a bottleneck within the organisation. Features are new Versions are waiting for the approval to be released.
Developers are Tester
..or as we call it at Atlassian DOT -> Developer on Test! We want our developers to test the features they produce to raise the awareness for quality. We want to move fast so we have a passion for quality but are not obsessed with it. So Developer picking tasks from other Developers and test them. This way developers are feeling more responsible for the quality they produce. It helps them focus on quality when they implement the code. There is not a QA that will find the bugs, just the person next desk. The QA is focusing on providing the Tools for screenshots, picture comparison , test automation frameworks, data generation and so on. Some features are still be tested be a QA employee. These are normally the risky features, that require some more attention and test knowledge.
More Test Awesomeness
To make DOTing really rockin we implemented some more things:
Training: Every developer get some training lessons from the QA about how to test and what to look after.
Pairing Sessions: A developer and a Tester are pairing. This is also part of the DOTing education. The developer is doing the actual testing and the QA person is giving tips and tricks how to become more effective. This helps also the QA team to get a better understanding of the developers mindset.
Split Sessions: In split sessions a developer and a QA employee is testing the same feature at the same time but separately. After the split sessions the two come together and discusses what they found. This way the testing becomes a little bit of a competition where everybody wants to find the most issues and the developer can become better by learning from the QA person.
Blitz Test: In Blitz tests our QA is inviting developers from all over the company to participate in a time boxed test session. The more the better. We are normally testing new features of our software. Some people get the task to test something specific like different browsers others just have to try to break it. The best tester (decided by a jury) gets a cool Blitz Test winner shirt.
Test Recipes: After educating so many great tester the QA employees start writing a test recipe for a feature. It tells the developers what the QA recommends to test. These are done in Bonfire test session so the documentation of test is directly connected to the feature in JIRA. At the moment this is the holy grail of our testing strategy. The QA is only involved in giving advices and it scales quite well. We don’t need an army of QA employees.
Bug Hunter: Another thing we’re currently trying is to implement a bug hunter in the team. Each day or second day one person from the team plays the bug hunter. His task for the day is to find bugs in the currently developed features. This raises the awareness for quality even more.
More Awareness for Quality
The goal of the QA team at Atlassian is it not to get more people but to be more efficient. With Developers on Test the QA gets more time to work on strategy and it scales way better than doing all tests themselves. They can work on cool tools like a “Flaky Test Detector” or QA plugins for JIRA. For developers it raises the awareness for quality. Before we started with DOTing 36% of fixed bugs got rejected. No we are down to 7%!
Kick Ass software developer
- are accountable for the quality of the software they produce
- care about good quality but are not obsessed with it. Speed is still the key for Kick-Ass software developement
- love the idea to test the software themselves and don’t have to rely on the time schedule of a QA person
- are willing to learn how to test better and faster with more fun
This one is maybe Atlassian specific but I guess it happens in lots of engineering driven companies: You start with a small team of developers and as you grow you add more developers. Maybe at some state you add a bunch of tester. But what about designer? Developers can do a little bit of design themselves, right? Or they think they can. Design is also an easy thing to outsource. You let your interface design by an external designer and then the developers are iterating on that. The result of all of this can be seen in some older JIRA versions. Great product, but no holistic design or a great user experience.
Starting with Design
The first designers that came to Atlassian had a lot of things to do. When they looked at what the developers have done, they found 60 different implementations of a drop down menu. They all looked different. Our designers jumped into the teams and helped them with the design problems. One of the first things they did was to work on design guidelines. A paper that explained how a button or a menu should look like. Developers are smart people and they learned fast. Every time a designer broke a rule of the design guidelines a developer noticed that and told the designer. That made us think, because we still had problems to find good designers. Why not educate our developers to become designers?
Developers are Designers
Every Atlassian employee need to do a bootcamp class in their first weeks called “Think like a designer”. That helped a bit. But we wanted some design advocates inside the development teams. So our designers recruited the best talents (mostly the front end developers) and taught them for one week the basics about design. We didn’t want the developers to become designers but just that they can help out with some smaller tasks. That helped our design team to get more time on the holistic design, the usability tests, and some more advanced designs. On the other hand it speeded up the development: The designer is not the bottleneck anymore.
Designers are Developers
Designers are Team Members
One designer at Atlassian didn’t like that team members interupted him just to see the new not finished designs. He set up his desk in the corner of the office so nobody could see his screen anymore. That was a horrible experience for him. He felt disconnected from the team. After 2 weeks he decided to have his desk in the middle of the office. If we have a design task, we need to have opinions from every angle: The product manager, the front end developer, the back end developer and the designer. That way we come up with the best solution. We also set up a design wall for the team where our designer can put up the newest ideas. Everybody in the team can comment and correct on designs just by using a pen. The whole team feels responsible for the design.
Kick-Ass Software Development Needs Great Design Fast
Kick Ass developer need to work closely together with designers and even do design tasks. Kick-Ass developer
- knows that speed is the key. Not everything has to be polished (but you have to know when)
- with design skills are helping designer, so that the design is not becoming the bottleneck
- are helping designers to work on code, so you reduce the steps between design and code
- help designers to become team members and are trying to understand their pain
As a Kick-Ass Developer you should automate as much as you can, so you’re able to do more coding. Looking at the development cycle the most obvious automation are your builds. Nowadays I don’t know many teams that are not using a Continuous Integration server that kicks off a build after every check in (in fact I just know one). But how much effort did you put into to making your builds Kick-Ass?
If your builds can execute fast, your developers can react directly when the build fails. They maybe haven’t even started with their next task, so there is almost no context switching involved. The changes are fresh in their mind and they can fix the problems fast. So we want fast builds to shorten our feedback loop. We want to fail faster. Do you know if your build scripts and concepts are effective?
Here are 5 lessons we learned at Atlassian to make our build pipeline kick-ass again:
Kill hung builds automatically
First we start with an easy Kick-Ass advice, that you probably can implement in a few minutes. How do you currently find out if your build is blocking? Well, I guess you have to look at your CI-Server UI if you haven’t set up a notification on build success. If a build hangs for hours you will end up with a lot of build requests in your queue. All modern CI-Server are capable on killing hung builds. Just define a time and automatically rerun the built. If it hangs for a second time you can setup a notification and have a look at it.
Pass the artifact
This is easy and short: Pass your artifacts like JARs, EARs and WARs. You can use something like Artifactory to check in the artifacts you are building or just put them on a file server and grab them from there. Reuse your artifacts if you’re running UI tests or Integration tests instead of building it all the time from scratch. Sounds obvious. Yes, but look how much the JIRA team cut down the build time since we passed around the artifact.
Run tests in parallel
Another way to make your builds fast is to split your test suite into batches. You normally don’t have to run them in sequential order. Take some tests that belongs together and run them on a different server in parallel to other tests. Most of the modern CI servers allows you to install build agents that can be triggered and run the tests on their own. Some tools (like Atlassian Bamboo and Teamcity) allows you to aggregate the test results in a single build result. Atlassian had some awesome success when splitting up our tests and distributed them on different servers. If something goes wrong, we find it out fast.
Have a build strategy
Let’s face it: Even we’re trying hard to make our test fast, there will still be some tests that takes a long time. At Atlassian we test against different databases that works with JIRA. We also have tests for different operation systems and for different browsers. So you can imagine if we automatically test all the combinations it will take some time. But as a developer you want to have fast feedback. You don’t want to work for hours on the next task and get interrupted by a build you broke with your merge 2 hours ago. Also if you have 20 developers each checking in code every 2 hours, you have to start 10 builds per hour. You need to have a lot of hardware to support this or you have a long queue with builds waiting for execution.
We operate in different loops:
- inner loop: This is starting a build for every commit. We’re just checking out the code, compiling it and run the unit tests
- middle loop: This is timed (every hour). We take the last successful build artifacts and run some UI tests for the most common browsers
- outer loop: We ran this every night. A full integration UI test and smoke tests.
That way we tightened our feedback loop. When the middle loop fails things are still fresh in mind. Of course this is the pay off you have with long running tests but we think it is a good compromise.
Look at your stats
Find your very own bottleneck to kick-ass with your Continuous Integration / Delivery / Deployment. Which test takes so long? How often do we checkout the code for a build? These and more statistics can tell you where your bottlenecks are. If all of sudden your build time goes up, you might want to have a look at it. Normally your build server just sits in the corner and works silently. But it is a good time investment to have a look once in a while at the build time statistics.
Use more robot power!
As a Kick-Ass Software Developer you:
- have short build feedback loops to avoid context switching
- know how long parts of your builds takes
- constantly work on improving your builds
- make sure all builds stay green, otherwise you stop the current work
Collaboration on code is important. If we want to do Kick-Ass Software Development we need to get our changes fast, easy and without a big process into the code base and keep the code quality high. I start with 2 problems I’ve seen in software development teams.
Code collaboration problems
The indispensable developer
If you’re a developer that works just in your own codebase without anybody else touching your code, you are in a very unique position. You can commit code changes and apply patches for older versions without notifying anybody else. It’s just you, that have to know the code. But I’ve seen this behavior also when people work together in a team. Especially developers that are working for a long time on the project can have the tendency not wanting to share their code with the rest. These people do it because of two reasons: They are afraid that they got criticized and they want to save their job and position by making themselves indispensable. This person is a big risk for the company and destroys the team.
The control freak
In other projects you have one or two senior developers. They are so smart and they know the code that well, that every change by someone else needs improvement by them. The other developers in the team (let’s call them shitty developers) have to get their code reviewed by the senior people. If they reject their changes the shitty developers need to change the code again until it looks right in the eyes of the smart developers. Sometimes it takes over a week until a senior person can review the code. They have all tons of other more important stuff to do. You can indicate these “developers” easily when looking in their meeting schedule. Smells like a big unnecessary bottleneck to me.
Kick-Ass code collaboration
With Kick-Ass software development everybody can change every line of the code. There is no code ownership. When somebody sees a bug, he has to fix it. We share our code to learn from each other. We want to get our changes fast into the master with high code quality to start with the next code changes.
A branch for every task
We use the power of Distributed Version Control Systems like Git and Mercurial at Atlassian. We’ve implemented a simple workflow to avoid having a bottleneck in our development and move fast to the next task. Kick-Ass software developer create a branch for every task. With DVCS this doesn’t cost anything. When the task is done the developer can merge the changes back into the master branch. A task-branch doesn’t life longer than 2 days, so the change set for a branch is small and we can keep the overview. You don’t get lost when looking at the changes. This approach kicks ass because it’s fast, easy and it makes the developer to focus on a small set of work.
Don’t loose the power of CI
We’ve set up our continuous integration server to find all new created branches and apply the built plan automatically to the new branch. So we have an automatic build for each task branch. The developer doesn’t have to care about this. He just gets notified when he broke a test on his task branch. The CI server even deletes the plan automatically when there is no activity on the branch anymore. We even can do a built on a virtual merge: If our developers wants to find out if they will break the built after they merged the code back to the master they can do that without doing the actual merge. This helps us to avoid broken builds on the master branch.
Code quality and sharing with Pull Requests
What about code quality and collective code ownership when everybody can push changes to the master? Oooops, I forgot a detail here. Of course we’re doing code reviews. In Git code reviews are done with Pull Requests. The code author asks some reviewers for their feedback on some recent code changes. The changes are not very big (short living branches) so it doesn’t take long to go through the changes. The task based approach makes it pretty clear what the code change should do. If two reviewers are ok with the changes the author got notified and merges the code into the master. We normally pick three or four reviewers for a Pull Request just to avoid bottlenecks. Every “approve” counts the same, no matter if it was an expert or a newbie. The advantage that Git gives you over Subversion or CVS: You don’t have to merge the code before your code review has been approved. Your master stays always clean!
Kick-Ass Developer share code
The most important thing on code collaboration is the sharing part. We can learn from each other and we got to know all parts of the code base. Here are some points to keep in mind on Kick-Ass code collaboration.
- Kick-Ass Developer are happy to share code with others.
- Kick-Ass Developer are gentle to each other when commenting on other people changes.
- Kick-Ass Developer use automation to keep the code quality high and catch problems before they stop the whole team.
- Kick-Ass Developer trust each other that they won’t harm the code.
- Kick-Ass Developer can also communicate face to face when an online conversation takes too long
- Kick-Ass Developer don’t have complicated workflows or processes: branch – code – share – merge
Tools we use:
Since one decade the agile coaches keep telling us how to organize our development. How the awesome agile process gives developers better results and that it will make us happier. People were writing excellent code and delivered good software before we had processes called Scrum or XP.
I visited Devoxx in Antwerp last week and saw a few talks heading into this direction: We keep talking too much about how to organize our software development than caring about our software. There is some truth in that: Every time we are following a new methodology we think this is the holy grail. It’s newer, it’s better, it makes us happier. Does it? It takes time to learn it, to implement it, to follow it and sometimes you need a certification to become a master. It’s process overhead and we should get rid of it.
Here are some programs that want to guide us torwarts a new more programming centric approach:
The Diabolic Developer
Martijn Verburg shows in his diabolic developer talk how much methodologies suck, how collaboration is bad for our career and how we get rid of tester by just shipping the product. It is very funny to see Martijn ranting on well known agile practices. But he has some point in what he’s saying. We’re hiding behind processes that doesn’t help us move forward. You should watch his hilarious 5 minute video from this years OSCON!
“We must destroy these methodologies that get in the way of…Programming, Motherfucker.”
The’re also using the agile manifesto and replace every value with “Programming Motherfucker” and they offer a pretty cool t-shirt.
Dark Manifesto for Agile Software Development
“We are uncovering the only ways of developing software by teaching others. Through this work we have come to value:
- Individuals and interactions
overand not processes and tools
- Working software
overand not comprehensive documentation
- Customer collaboration
overand not contract negotiation
- Responding to change
overand not following a plan
That is, since there is no value in the items on the right, we value only the items on the left.”
Andreas Janes and Giancarlo Succi explaining in their manifesto white paper that Agile has followed the Gartner Hype cycle and that there is room for improvement.
So, should we shoot Agile in the head?
The great thing is, that people keep thinking about Agile software development or development in general and doesn’t want to follow just a new methodology (but having fun creating a new one). We don’t want to be controlled by smart consultants that tells us how we should develop and after two weeks they leave again leaving us alone with a Scrum Master certification. Don’t get me wrong: I love what Scrum has done for our industry. It helped us a lot to have a more team centric approach, more interactions with the customer, constantly reviewing and improving ourselves. It was great and I loved Scrum from the very first days. Now it’s becoming common sense. We should move on. But instead of creating a new methodology and a leader to follow (can you hear me Uncle Bob?), we should look out for what doesn’t work in Scrum or Agile and fix it. We should concentrate more on development than on methodologies. I call this Kick Ass Software Development. This is not ment to be a new methedology but just some things to consider, that can be changed in your software development. In the next few weeks I will write a couple of blog post with some topics that helps making Agile even more awesome, and fixes some process restrictions.
Let our software development and our products Kick Ass again!
Exactly one year ago I did my first talk at a public conference. I wrote an abstract about my experience how to clean up the code of a legacy system. Three weeks before the talk I totally panicked because I haven’t done one slide and didn’t know if I could fill a 60 minute slot with information. I freaked out even more when I saw that I have to speak in the big keynote room with 700 seats. Don’t get me wrong: This was always my dream it was just so comfort in my comfort zone only consuming great talks. Anyway the talk went fine, I felt well prepared and didn’t throw up on stage.
One year later I’ve done some more talks at large and small conferences. It’s not rocket science. If you think there is no story you can talk about, you’re probably wrong. I was thinking the same. But when I told people what we’ve been doing at work, how we ran our team, how we tried constantly to clean our code, I got a great response. People like to hear real stories and want to get inspired by others. It’s a great experience. Here are 5 tips for people who also want to start talking in public:
1. Learn from the masters
There are some great talks out there. My favorite speaker was Uncle Bob. I saw him speaking at Devoxx a few years ago. He just had one sentence on each slide an talked about the topic for 10 minutes. I think this is a great presentation style. But instead of copying him, I tried to develop my style. If you watch different speakers you can get inspired by each of them. Take bits and pieces (gestures, slide design…) and tie them into your style.
If you visit a conference just don’t look for interesting topics but also for good speakers. You will definitely see things that you don’t like (like reading out loud a bullet point list) you should learn from that, too. I saw some great presentations from famous speakers but also some that really sucked.
That said, you should not forget point 5!
2. Preparation takes time
I’m surprised every time how much time it takes to write a talk. Developing a 30-45 minute talk takes me about 40 hours of work (incl. practice sessions): Getting the messages right, finding great examples, looking for more data on the web… and designing the slides. You should put some efforts in designing your slides: FInd good pictures that underlines your message, find the 3 -5 words that tells your message, find a cool color scheme and a good font. It doesn’t matter if you tell your story in 10 or 100 slides. I saw great talks with just a few slides and awesome talks with slides each 30 seconds. It depends on the talk and the presenter (see point 1).
If you’re done with everything you should practice your presentation at least 4 times! Do it loud. You can use index cards for the first run but you should avoid to use them on stage. After my first practical run, I need to change a lot of slides, remove some and add some more. Before I deliver the talk for the first time at a conference I try it out in front of a real technical audience (thanks to my old team mates at REpower Systems SE to listen to it and giving me advices). They can give you real valuable feedback.
You should also record your talk with a screen capture tool for two reasons: One is to listen to yourself and see where you are boring and how you sound to other people. Reason two for recording the talk is to document what you’re saying. I suck updating my speaker notes when I tried the talk 3 times. The talk changes. When I do the talk for the second or third time I just listen to it before and I’m up to date. You can also release it that way on YouTube. You will reach a lot more people online than at a conference.
3. Interact with the audience
It is the first few seconds when people decides if they like you or not. I don’t say that everybody should like you and what you’re saying but it helps if you get a connection to the audience at the beginning. How are you doing that? Start your talk with a story of your own. Get to know the audience. Ask questions. Interact with the audience. Be yourself.
You should also try to be funny. Entertain the audience. I guess, this is the hardest part. I’m not good at telling jokes. I’m even not good at entertaining people at parties. I always try to put in funny pictures that underline my story or say something provocative and smile. At some conferences that works, at others it doesn’t work. If your audience is not reacting or showing any emotion make a pause, give them some time. If there is still no reaction just go on.
4. Adjust your talk
If you’re a public speaker you will probably reuse your material for multiple presentation. There is actually nothing wrong in giving a talk 10 times at 10 speaking events. It’s like a concert: It’s a new talk for the audience… But if you noticed that you stuck with some slides or the talk doesn’t flow don’t hesitate to change something. Improve your talk after every presentation. Don’t hesitate to throw parts away. If you get the same key message to the audience in shorter time, that’s even cooler. BTW: I don’t have problems finishing the talk 10 minutes before the conference schedule.
Probably some people will show up to talk to you after your session. Take the feedback seriously. Think if you can use it for the presentation in order to answer the questions during the talk.
Try to adjust your talk to each audience. Let the people feel like you did this talk just for them. If you’re in another country, put in some local content. Don’t look like a rock star that doesn’t care in which city he is playing. Care about your audience.
5. Be yourself
Maybe the most important thing if you’re doing a presentation. Don’t try to play a role or copy an awesome speaker you’ve just seen at another conference. Tell a honest story from your experience. Also tell how you failed. Don’t look like an untouchable super hero that does everything right. People will feel more connected to you and your content if they see, that you’re a guy just like them. If it comes to Q&A don’t shy away from saying “I don’t know”, if you don’t have an answer to the question.
If you get feedback for your talk, be prepared that not everybody will love you. I like to do talks where I keep pushing the envelope and being a little bit provocative to change peoples mind… Some people are just not prepared to do something new or come out of their comfort zone so they don’t like what I’m saying. That’s alright.
Christian Heilmann has written a blog post with some great advices for people that start to speak in public and want to train in a comfort zone like Power Point Karaoke and regular Lightning Talks.