Sven Peters

10 Development Culture Smells You Should Change

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.

7. Featuritis

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.

Blame Driven Development – finally a methodology that works

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.

Additionally

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.

Git & Continuous Integration – Does that work?

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?

Don’t use Git

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

With Subversion you have a simple workflow for adding your code to the repository:

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!

Hiring Kick-Ass Developer

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.

Navigationsgast Hauptgefreiter El Jarraz mit Fernglas (DF)

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.

developers stay

mood_app

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!

Kick-Ass Software Testing

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.

Training

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.

bug_hunter

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

Kick-Ass Development Needs Great Design Fast

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.

Designer & Developers

Designers are Developers

But also designers can help the developers to speed things up. The good old design tools like Adobe Photoshop and Illustrator are pretty static and have a hard time adapting all the cool HTML 5 interaction stuff. It is way easier if the designers can come up with their designs already implemented in code. Why should’t a designer not do a pull request with a new button design already written in JavaScript/CSS? When a designer understands some JavaScript, they can edit the code and make some corners a little bit more round. This saves a lot of overhead time. There is a great blog post from one of our developing designers explaining the details.

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.

great design fast

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

Kick-Ass Build Automation

robots 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

loops 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

Kick-Ass Code Collaboration

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:

Git / Mercurial
Stash / Bitbucket (Pull Requests)
Bamboo (Continuous Integration)

Beyond Scrum – Is Agile dead?

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!

Programming Motherfucker

The methodology from Zad A. Shaw can be explained in 2 words: “Programming Motherfucker“. They’re saying in their Manifesto about Scrum, Waterfall, XP, Software Craftsmanship and Pair Programming:

“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

The Dark Manifesto is written by Andrea Janes und Giancarlo Succi and is replacing the word “over” in the Agile Manifesto by “not”:

“We are uncovering the only ways of developing software by teaching others. Through this work we have come to value:

Individuals and interactions ~~over~~ and not processes and tools

Working software ~~over~~ and not comprehensive documentation

Customer collaboration ~~over~~ and not contract negotiation

Responding to change ~~over~~ and 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!