Continuous Deployment changes your mind

Posted in agile, continuous delivery, continuous integration, deployment, management, software development, testing on August 14th, 2011 by Joerg – Be the first to comment

We are practicing Continuous Deployment since about a year. When looking back I realize the dramatic way this practice changed the way we work.

Just to draw the fine line between Continuous Delivery and Continuos Deployment I use the definition I once heard from Neal Ford. Continuous Delivery allows you to deploy every commit but you don’t do it every time. With Continuous Deployment you go further and really deploy every time.

I have recently been asked what the benefits of Continuous Deployment are compared to Continuous Delivery. I think the impact on your development practice is a huge thing.

In our company we practice agile development since about 2005. During that time I can remember many discussions about agile practices like:

  • Test Driven Development
  • Definition of Done
  • Potentially Shippable Product
  • Refactoring in baby steps
  • Not committing on a red build

Many of them do not easily reveal their benefits in daily business. So it becomes difficult to use them consequently.

The Definition of Done is a great example. It is easy to declare something finished or appropriately tested when there is usually a QA department that will find your mistakes during release tests. So the common recipe is write down your definition, post it on the wall and “be more disciplined”. Force yourself to write more tests, force yourself to declare things done only if they are really done and so on. This is not easy. In my experience it seldom works.

This changes dramatically when using continuous deployment. Between your commit and the production system is only an automated deployment pipeline, that usually takes something around 30 minutes. There is no QA department that does a extensive release test. Your mistakes will only be found by automated test that you wrote yourself. Well or they will be found by your Users.

Automated tests become your safety net. This again changes the way you think about TDD. It totally makes sense to have a near full coverage of your code. It also makes sense to have integration tests on API and GUI level to make sure your deployment pipeline catches most mistakes. It will not catch any mistake, but in my experience the same is true for most QA departments.

You will think differently about Potentially Shippable Products. Every commit has to be shippable and it will (not only potentially) be shipped.

This forces working in baby steps. It is just not possible to refactor a system by destroying it for several days.

If a build is red the deployment pipeline is halted. Nobody is able to apply more changes to the system unless this problem is fixed. Again something that used to be a discipline thing becomes a necessity. You need to help your teammates to fix the problem otherwise you can’t work yourself. The same is true if there is a red build in the evening. One of my teammates even talks about an addiction to fix the build before going home. It just gives you a good feeling to finish your day in a green state.

Continuous Delivery has several immediate business benefits I might tell you about another time. But most of them don’t need every commit to be deployed.

But I think the impact of deploying every commit on your development practice huge. Many agile practices make so much more sense. They fit naturally in this environment and you follow them easily. This will then result in benefits for your business on the long term.

Continuous Delivery Slides

Posted in agile, continuous delivery, continuous integration, deployment, java, management, software development, testing, version control on July 5th, 2011 by Joerg – Be the first to comment

The last Java User Group event in Berlin was hosted at Hypoport. It was about Continuous Delivery. We had about 100 guests.

There where two talks. One by Axel Fontaine who introduced Continuous Delivery especially in a Java environment. You can find his talk on Parleys or on his Blog.

I had the pleasure to introduce our experiences with Continuous Delivery. We are currently developing a new product. Since we started about a year ago we consequently used Continuous Delivery. We learned quite some lessons on our way which I presented that evening. My Slides are available here. (As this was a german event the slides are in german)

Thanks to everyone who attended the event. It was a really nice evening. Special thanks to everybody who helped organizing it.

Learn your damn vocabulary!

Posted in agile, management, software development on January 29th, 2011 by Joerg – 2 Comments

Yesterday in a conversation with a team-mate we had the idea of a metaphor that turned out to be very useful. Learning programming has a lot in common with learning a foreign language.

We were talking about different experiences while programming. Sometimes you are in a real flow. You can just fluently express all your ideas and create hundreds of lines without stopping. Other times you need to stop every second line to google some details or ask other people.

When using foreign languages you can find situations that feel exactly the same. The tourist with a dictionary needs to lookup every second word. There is no way to start a real conversation. It’s only enough to get to the next train station. But after some years of learning he might join the natives and enjoy a conversation. He can talk fluently and does not look up words or think about the grammar.

If the situations feel so similar, what can we learn from the metaphor. We should look what it takes to become a fluent speaker in a foreign language:

  • Learning vocabulary
  • Learning grammar
  • Using the language

Vocabulary in the world of programming is similar to basic language constructs, keywords and knowing what functionality your libraries are offering. I would also include knowledge about the editor or IDE, keyboard shortcuts and version control.
So what do you need to do to get fluent in your language. Learn your damn vocabulary! You really need to memorize it. It is not enough to be able to look it up. This would be like looking up every second word in a dictionary. A fluent conversation is impossible. Now the good news is, that in a natural language about 1000 words are enough to conduct a fluent conversation. Something similar is probably true for programming. You don’t need to know every detail to be fluent.
But the guy with a vocabulary of 1000 words will probably never win a Pulitzer prize. A lot of people think if they know the basics of their programming environment it is sufficient. No! You have to constantly extend your vocabulary. I am often surprised by discovering new features of the JDK, my IDE or the libraries we are using. Often I realize that I could have saved a lot of time, if only I did know this before. So go and discover new vocabulary and don’t forget to memorize it.

Grammar is more equivalent to higher level constructs like design patterns, data structures or algorithms. When you learn a foreign language, grammar is very helpful in understanding the right way to combine the words. If you don’t know the grammar, the way you use the language usually sounds funny to native speakers. The same goes for the grammar of programming. So learn it if you don’t want to sound funny.
There is another interesting effect. A fluent user of a language usually does not think about grammar. He can often not even explain why he used the words in a certain way. It just felt right. There is a lesson in it. Learn your grammar well but after a while don’t try to think about it to much in order to talk fluently.

Last but not least in order to get fluent in a language you have to use it. You usually start in a class together with a teacher. You have a save environment where you can try your vocabulary and grammar without fear. A good way to do this for programming are code katas. You are in a save environment with peers that support you and give you feedback. You have to repeat a kata often to memorize every important vocabulary.
There are many other well known ways to use programming in order to get fluent:

  • Read other peoples code
  • Do private projects (and open source them to get feedback)
  • And of course your do your daily business

Like learning a foreign language, learning programming takes many years. In the beginning you will be like the tourist and his dictionary. Just make sure that you don’t stay the tourist.

Next time you are stuck every second line while programming try to identify what vocabulary you just did not memorize or what grammar you probably not understood. Then memorize it and repeat …

Why all programmers should blog

Posted in agile, blogging, management, software development on January 30th, 2010 by Joerg – 35 Comments

There are some obvious reasons why you should start blogging when you are a programmer. Most of them also apply to everybody else:

  • You share your knowledge. This is a benefit for all of us. If everybody would be blogging about all the little issues they had then a Google-Search would help us even more. I am sure nearly every problem in the world is already solved. It is just not written down.
  • It’s a kind of self marketing. A potential employer can get a much better picture of your abilities than he could from CVs or references. When I hire somebody it is already a huge plus for him when he has a blog at all.
  • Explaining things to other people is the best way to learn. You can only teach what you fully understand. This is at least as efficient as hands on experience.
  • You might even make some money with blogging. There are several sites about this. If you are interested look here or here.

But the main reason is something else. Some years ago I read an article about software documentation. There was a lot of wisdom in it, but one phrase sticked to my brain:

Programming is doing something weird to your brain. When you write a piece of documentation right after a programming session the result is likely to be barely readable for human beings.

If that’s true then the opposite should work too.  Blogging teaches you to write for people, which is exactly what you should do in your code. Good code needs to be easy to understand to be easy to maintain. There are whole books about this like the famous Clean Code by Uncle Bob.

I think blogging does something weird to your brain, that makes your code better readable for human beings. So:

If you want to become a better programmer, start blogging!

A poor man’s countdown

Posted in agile, scrum on August 10th, 2009 by Joerg – 2 Comments

We all know those high-tech solutions that show the time left to a certain event. There are huge LED-Displays, Dashboard-Widgets or even iPhone apps.

countdown For an upcoming release of our software a colleague installed a very low-tech version.

You just need:

  • a tape measure
  • scissors
  • a wall (a glass wall in our case)
  • and something to attach the tape measure to the wall (some Scotch tape or Blue Tack will do)

Attach the tape measure to the wall and cut a centimeter off each day. That’s it.

It should not be a problem to raise the budget for this solution. Most of the stuff will be around in any office. A tape measure can often be found in furniture stores for free, although a plastic tape measure for a few cents usually looks much better.
I love this kind of low-tech solutions. It’s a nice contrast to the high-tech around and even marketing can understand it.