Slides: I love Programming

Here are the slides from the lightning talk I gave at a RailsGirls Berlin event on Saturday. It’s basically a lightning talk version of my blog post “I love Software Development, because it’s very collaborative and communicative”.

As such it is about how the view the general public seems to have about programmers/software developers is actually pretty wrong as we actually communicate and collaborate a lot.

Enjoy – and thanks everyone again for the great event this Saturday! And of course to everyone laughing and smiling, that makes presenting so much more fun 😀

Tobi

Advertisements

I love Software Development, because it’s very collaborative and communicative

I often have the feeling that programming and software development is largely misunderstood. Many people seem to still have ancient believes about how software development works. Believes potentially scaring them away from pursuing a career in software development. Let’s fix this.

In this blog post I’ll show why the mental image of one person sitting in a cellar all by him-/herself is as wrong as it can be. I’ll explain why I believe that the most important ability of a software developer is his/her ability to communicate.  And I’ll highlight why I enjoy software development so much. (hint: there are also slides about this)

The typical misunderstanding

Let me take you through a somewhat normal conversation for me with strangers at a party:

misunderstanding
A rather typical conversation at a party.
(Note for clarity: the depicted conversation wasn’t about this and those people are actually dear friends of mine, not strangers)

Bingo! You’ve just won yourself a speech of how that is basically the opposite of what I do. My work is filled with lots and lots of communication. Let me walk you through some of the most important and most frequent communication activities in Software Development.

Communication within the team

Team Spirit, December 2006
Team Spirit, December 2006 (Photo credit: JF Schmitz)

Most software isn’t built by a single developer. It’s developed by a team or even multiple teams. I mean does anyone really believe that a single nerd in a cellar builds Facebook and another one builds Windows?

This software is built by large collaborative teams. In a team you have to work together to achieve something.The parts developed by members of the team have to interact and play nice with each other. To Facilitate this the authors have to communicate. As software often solves complex problems, these systems also have to be carefully designed. This is best done in a group of people in front of a whiteboard – not in front of a monitor.

Modern software development actually focuses a lot on the team developing software and how they work together. Let’s take a look at the Manifesto for Agile Software Development, the foundation of most modern software development processes. It values:

Individuals and interactions over processes and tools

This is the very first point made highlighting that good software development is about people and how they work together. It’s not only communicating about the project, solving difficult problems together – of course the normal small talk and “grab a drink together after work” is included as well 😉 Motivation is very important.

It doesn’t stop here though. Often software projects are big enough that multiple teams have to collaborate to realize them. There is a lot of communication going on there as well. But there are still other people developers should communicate with like the system administrators and the customers. Wait, what – the customers?

Communication with the customers

Yep the customer. The ones ultimately using the applications. Or the client wanting the application.

Unfortunately that thought might seem alienating at first, but think about it. Those are the people who ultimately know what the application should do. They are the ones that will be using it, it should fit their purposes. The only way to know if the application reaches its highest goal, satisfying the customer, is through frequent communication and thereby feedback. That starts with asking them what the application should do and how it will be used. It doesn’t stop there though, it is enhanced through demos of a prototype of the application to verify understanding.

Some people take this even one step further. In one of the all time classic books about programming, The Pragmatic Programmer, it is recommended that you spend as much as one week working with the your users before writing an application. This way you should get to know what their work is like.

All of this generates invaluable insights and builds trust.

Look, there are two of them in front of just one monitor!

A friend and me doing some Pair Programming

Yep that’s two developers in front of just one monitor. Actually it’s me and a good friend of mine. So what do we do? Well naturally we are working. We are doing Pair Programming. That is one of us is actually writing the code while the other one observers. We both design the code and talk about it. We work together.

Some people think that this is a waste of time. Hell those are 2 programmers, give them 2 PCs so they can write twice as much code!

It’s not as simple as that. In software development we constantly solve problems. Solving them together leads to a solution sooner, higher quality code and more knowledge spread across the team. The benefits of Pair Programming are worthy of a whole blog post of their own.

Despite the benefits Pair Programming is still a pretty debated topic. Some people despise it. Some people only apply it to difficult problems. Some people say that all production code must be written in Pair Programming.

For me I love Pair Programming: It makes programming a lot more enjoyable, at least to me. When you try to solve a complex problem sometimes you hit the wall. You just don’t know how to solve this problem. You’ve run out of options. It can be really frustrating. That never happens to me when I’m Pair Programming. We, as a team, never seem to run out of ideas on how to solve a given problem until we find one that works. On top of that I can communicate and collaborate with someone all the time. How much more awesome can it get?

And what’s my point with this? During a good normal work day, I actually communicate and collaborate with at least one person almost all the time. Sweet.

Communicating through code

Now I really gotta be kidding right? What does code have to do with communication?

A lot actually. Let’s see what Kent Beck says in his book “Smalltalk Best Practice Patterns” in the Introduction chapter:

“(…) when you program, you have to think about how someone will read your code, not just how a computer will interpret it.”

Kent Beck

And that someone refers to the people in your team as well as yourself. As a team you work together meaning that you have to be able to understand and extend the work of your colleagues. And of course you must be able to understand what you wrote some months ago or even just some weeks ago. You might be surprised how difficult this can get with poorly written code.

Good code must communicate well. The best code, in my eyes, is the code that is the easiest to understand. Code that pretty much speaks to its readers. Writing such code can be very challenging. You can find me discussing with my Pair Programming partner about naming questions for like 2 minutes – it is important.

(Taken from OSNews)

Does everyone work like that?

Not every company empowers their teams. Not everyone loves pair programming. Not every company cherishes communication. Not every company works Agile. There are people out there still following the Waterfall process, which has been a misunderstanding from the beginning, where at first rigorous documents are made and then the programmers are locked away to “just code it”. Why do people keep doing this? I have no idea. I just know that there are enough tech companies looking for developers out there so you don’t have to end up at an old-school command & control enterprise.

So with all this talk about communication one might ask: “What about the introverts? What about people who don’t like to talk as much?”

Well I’ve worked with some people who might qualify as introverts. Let me tell you this: I’d love to work with each and every one of them again.

See communication is not a one-way street. It’s not just about talking, it’s at least as much about listening. People who just talk but don’t listen are bad communicators. Maybe more introverted people don’t talk as much. However with the ones I know I found that if they say something it is of immense value. And they are very good listeners as well. Plus they enjoyed Pair Programming as much as I did. I would say they are good communicators and collaborators. To me bad communicators and collaborators are those that don’t work together with the team and spend most of their time simply criticizing others.

Wrapping up

stickies
Look we got post-its too! (Thanks for the photo to Andreas!)

So what’s the lesson here? Well today’s Software Development is a lot different from what many people think it is. You work together as a team. You talk. You draw on white boards. You have those funny little post-its to coordinate work. Some people work together all day long. You have fun. You actually communicate with he people using your product.

As I hinted at first all this makes me believe that the ability of developer to communicate is more important than his/her technical ability. Developers are part of a team. If they excel technically but don’t know how to share their expertise with the team then they’re not helping much. Even worse, people who spend meetings just criticizing ideas can easily kill the motivation of a team and slow them down significantly. Luckily I haven’t met many of them.

Good communicators and collaborators on the other hand do everything for the team. They help and motivate each other. They happily share their knowledge and are always ready to learn new things.

So my point is this: Do you like solving problems? Do you like to work in a team? Would you like to work in a continuously evolving field with lots of new technologies and opportunities? Do you like to build something awesome helping many people?

Congratulations, software development might be just the thing for you!

Updated Resource section

Hi everyone,

just a quick note I updated my beloved Resource section with some quite nice new resources. I also restructured it so that Ruby and Rails got some distinct sections.

When I started this blog sharing resources for learning how to program was pretty important to me and it still is now. I love both teaching and learning. I hope that these resources can help you to learn how to program, teach someone how to program or improve your own skills. But it’s not only programming there, my favorite topic “agile software development” is also mentioned!

Most of the resources are free so go ahead and check them out.

Enjoy and have fun!

Tobi

Teaching Agile

graduation hat

I’ve been at the XP 2012 conference and I had a great time and a lot of interesting conversations. One topic that particularly intrigued me is how we can teach agile software development at universities. There are, to my knowledge, quite some universities that don’t teach agile software development at all or do it very badly.

I attended a good talk by Mark Lainez. He, and some of his colleagues, use their spare time in order to give presentations and hold workshops about agile at Belgian universities. This is super awesome. They do this because they saw a lack of “Agile” education at universities in Belgium. However this is not only a problem in Belgium. It is much more widespread than that.

This post is mainly aimed at people like Mark and lecturers at universities, who want to introduce “Agile” to universities. I’m lucky to be at a, in my eyes, particularly good university. As I’m a student myself I’d like to share my thoughts on what worked for me, what didn’t work and what might work when learning about agile software development.

Theory is good – but people need practice

Let me tell you something about my studies at the Hasso Plattner Institute: We learn about design patterns in our third bachelor semester! Awesome right? The bad part: Few students care at first. You need a big project in order to understand the benefit of design patterns.

It’s the same thing with teaching agile, people need to work on something real in order to realize the benefits. People need to practice pair programming in order to see how much it improves their code, their skills and their productivity. I was very skeptical about pair programming at first. However I had a key moment with pair programming. I noticed that I hardly got stuck anymore on hard problems whilst pair programming. When I run out of ideas to solve a difficult problem my partner usually has a good idea to solve the problem. If that does not work then we can discuss and come up with a new approach. You have to experience this in order to really appreciate its value.

However it’s really hard for external speakers to arrange a course with the development of a whole project at a university. Therefore I recommend, inspired by what Mark did, little workshops where you introduce people to pair programming or other techniques.

Furthermore put an extra effort in a really good presentation. Students usually have higher expectations for external speakers than for “normal” lecturers. Try to get them engaged, for example with games. There are lots of little games you may play. These games usually don’t take too long, you get people engaged and most importantly you make your lecture memorable. You can find a list of suitable games at tastycupcakes.org.

At my university we had the Lego Scrum exercise. I liked the Lego Scrum exercise very much and I remember that my fellow students mostly felt the same. At the very least it is something that everyone remembers. Here is a little video of us doing the exercise (sorry for no subtitles!):

I highly encourage you to embed those games into teaching agile software development. I believe that they can truly make a difference. But once you got the students engaged and they know about the theory, then it’s time for practice! Time for a project! Or more?

Don’t conduct one agile project, conduct 2!

Let me tell you something more about my bachelor studies: We are supposed to develop our first project with agile software development methodologies in our fourth semester. And you know what? It was a disaster. But a disaster that was needed.

We were using eXtreme Programming (XP) for the first time. We had enormous problems with estimations, user story slicing, iterations, test driven development (TDD) and probably everything else you can imagine. We did a whole bunch of mistakes. It was not just my group. Nearly every group I remember faced similar problems. For instance nearly everybody wanted to do TDD but ended up with a code (line) coverage between 20% and 50%. When we didn’t get our user stories done during our first iteration we simply prolonged the iteration by one week. Yes we really did that.

Of course, there were bright spots. We used pair programming and loved it. Our planning went pretty smooth towards the end. However I honestly don’t know how I’d feel about agile software development if this would have been our last agile project.

Luckily we conducted a second project in another course, which has already been praised. There we were using Scrum in a team of 50 people (with sub teams of course). We developed a customer relationship management system in Ruby on Rails. Our planning and retrospective meetings were facilitated by students who took the course in previous years. It was interesting to see how much we all improved as we grasped the concepts better. Moreover it was a good experience in inter team dynamics.

It was good but we still had a long way to go. Unfortunately not everyone seemed to like the concepts as much as we did. We were one of few teams to choose an agile development process for our bachelor project, were we were (mostly) free to choose how we want to work.

Adaptive vs. Innovative

Clarke Ching opened my mind to another important aspect: Adaptive small changes when rolling out agile or the “all at once” package. I believe that some of the problems we had were related to this. If you try to implement so many new and different concepts all at once, you will most likely end up implementing every change just a little. There are just too many new things which you can’t possibly really implement the first time around.

Therefore I believe that it could be beneficial to run workshops specialized workshops or exercises prior to the project. These exercises could focus on estimation, pair programming, TDD or… you get the idea. This way students get the opportunity to familiarize themselves with a method prior to using it in a project. Or you could tell students to simply focus on a set of changes and not try to implement all of XP all of a sudden. I just had the feeling that it was a bit too much, so maybe these techniques could be used to mitigate the problem.

The Takeaway

Theory is good and necessary, but practice shall never be underrated. If you give a lecture as an external speaker make sure to make it memorable. Engage them. Share your enthusiasm with them. You won’t convince them all. That’s alright. But if you give it all, you will successfully plant the idea of “Agile” in their heads. And I’m very thankful for everyone, who does this.

Why Waterfall was a big misunderstanding from the beginning – reading the original paper

You probably know that there is the Waterfall process – by now feared by most as “the father of the plan driven approach”. Some may even know that Waterfall was supposedly “invented” by the paper “Managing the Development of Large Software Systems” by Dr. Winston W. Royce in 1970. But have you ever read it? Why should you? It’s probably just an endless explanation of how great Waterfall is… or is it?

What if I told you that it is the exact opposite? If I told you that it is a paper identifying this pattern (without naming it Waterfall) and describing its deficiencies and proposing enhancements? Don’t believe me? Well let’s see what Mister Royce writes right after introducing the pattern on page 2:

I believe in this concept, but the implementation described above is risky and invites failure.

Doesn’t sound so positive, does it? Oh and that’s not even the best part! The best part is that the paper actually includes some thoughts that I would classify as agile.

Wait what?

Yes back in 1970 the paper, that supposedly invented Waterfall was describing its deficiencies and actually contained some agile thoughts. I really recommend you to go ahead and read this paper. Or stay with me and let me explain it to you – or do both.

The reason why I’m bringing all of this up is that it seems that all of this is a little known fact. I mentioned it to two of my lecturers (both PhDs) during discussions about agile vs. plan driven. The fact that they didn’t know this kind of shocked me, so I decided that this probably needs some more exposure – and this is all the exposure I can give.

But all is not lost, I actually learned this fact from a lecturer, Dr. Joachim Schnitter, at my home institute – so thanks to him!

The misunderstanding

Royce doesn’t define the Waterfall model and recommend it, he identifies the pattern and shows one of the major problems of the Waterfall model as the testing phase occurs at the end of the development process:

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.

He further on states that faults found there will most likely result in a major redesign of the software, he describes the devastating effects of this as:

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

To me this analysis is pretty much right on target in describing Waterfalls biggest problem, highlighting that he doesn’t recommend this approach at all. He is suggesting improvements.

So how is this paper agile?

It is certainly not totally agile, but it contains thoughts that go in the right direction and really resemble some current agile practices. Winston Royce proposes 5 enhancements to the “Waterfall” model, they are as follows:

  1. Program design comes first
  2. Document the design
  3. Do it twice
  4. Plan, control and monitor testing
  5. Involve the customer

Let’s focus on the latter 3 as the first 2 aren’t pretty agile to my mind (especially not number 2 as it highly emphasizes documentation):

Do it twice

Royce basically advocates that if your software product is original, the version delivered to your customer should actually be the second version of the product, at least for critical areas. He goes on to explain:

Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.

He explains that this is done to identify problems early on, so they can be tackled appropriately later on. All of this sounds like a “spike” to me. You go on to build a part of your system, which you have little knowledge about, in order to increase your knowledge about this part of the system . You do so in isolation and throw the code away afterwards. He says that you should do this, but for the whole system.

Plan, control and monitor testing

In this section he once again argues that it is bad, that the testing comes last. However he does not jump to the conclusion that testing should come first, but he greatly emphasizes the importance of testing for the success of a software project. He also says that code should be checked by a second party, as many errors are easy to spot. I know it’s a very far stretch but that reminds me a bit of one of the motivations for Pair Programming, although he doesn’t suggest anything like it.

Involve the customer

This basically stands for itself as it is also one of the four core values of the Manifesto for Agile Software Development. He more explicitly says:

Involve the customer – the involvement should be formal, in-depth, and continuing.

He also states what it is like when the customer is not involved and the development team is basically left alone:

To give the contractor free rein between requirement definition and operation is inviting trouble.

He suggests 3 points after the initial requirements generation, where “the insight, judgment, and commitment of the customer can bolster the development effort.” These are: Preliminary Software Review (after Prelimnary Software Design), Critical Software Review (after Program Design) and Final Software Acceptance Review (after Testing). Although this is not an on site customer yet, it is much better than “make a contract and then let the contractor work alone in the dark on the system according to the contract” – don’t you think?

So was Winston Royce agile?

Certainly not, but he had some really good ideas on how to improve software development, some of which may be classified as “agile”. But why have most of us never heard of this before?

So how did Waterfall become so popular if the deficiencies were so well-known?

What I write now is just a rumor, nothing more. I’ve no way of telling whether it is true or not and clearly no reference.

So from what I’ve heard sometime some guy of the Department of Defense was given the task to look for a software development process to develop a new system. He found the paper of Royce, read the first page (which is quite positive) and saw the figure at the top of page 2 depicting what we now know as the “Waterfall” model. As it was simple and seemed good he went on to propose the depicted process, without ever reading about the deficiencies and proposed enhancements. Maybe it’s just an urban legend, maybe it’s true – I don’t know. Either way I’m sad that Winston Royce has been so misunderstood.

Lesson learned

It can be very beneficial to go back to the roots and read the original sources, even over 40 years after their initial publication. If some more people would have done this, maybe we would have (mostly) gotten rid of Waterfall as a Software Process by now. However it is still there and going strong. To each his own, but I prefer agile methodologies, practices and associated software development processes. To me they are way more productive, effective and fun. And it is always good to know that a CMMI level 5 company can highly benefit from a switch to Scrum – doubling the productivity and reducing defects by 38% (and many more benefits). I encourage you to go ahead and read about it in the Scrum Papers, the section (paper) is titled “Scrum and CMMI Level 5: A Magic Potion for Code Warriors”. Have fun reading it and I hope you enjoyed this read as well!

Can a distributed project be agile?