Programming together

Programming together in a group is a bit like living together in the same house or sharing the same apartment. It can be fun if all work together. It can be frustrating and annoying, too. Others will get upset if you don’t clean up the kitchen (and do not leave clean code), mess things up or if you change their things. In an apartment- or flat-sharing community, it is often the shared rooms like kitchen and bathrooms that cause the most trouble.

To be more precise, software engineers or software architects who work together are a bit like architects who live together in the house they are building. It works best if everybody agrees on a central plan (if there is any) or if everyone works and “lives” in his own space, i.e. everyone has his own room(s), owned only by himself, where the others are not allowed to change things. If you are lucky, then the others may show you their rooms occasionally. Some shared regions like the main entrance, can be public, though. Basically, programming well with others is difficult, just like living together, because likes, tastes and preferences vary.

Since programmers are like little gods, almighty and all knowing entities in the world they have created, the clash begins already if two or more programmers with equal rights must work together. One wants a red room, the other a green. One wants wooden furniture, the other plastic. To find a compromise means to communicate and talk with each other. And this is an area were most programmers do not excel. I am not good at it, either. I think it is justified to say many have chosen to become a programmer in order to avoid too much idle talk and communication. This is were the difficulties begin..

(The picture is from Flickr user Annette Bouvain and shows a flat share)

A minimum number of chips and code

Good hardware engineers like the legendary Steve Wozniak make designs which have a minimum number of chips. They try to design a simple minimum-chip circuit, because in hardware design a minimal number of chips means to minimize the cost.

Good software engineers make code which have a minimum number of lines. They try to design a simple minimum-code program, because in software design a minimal number of lines means to minimize the complexity. Less code means less effort to understand it, less trouble while maintaining it, and less hassle in changing it.

Thus in general, less items in engineering means less cost and less complexity. A minimum number of items, whether chips or lines of code, is important to achieve simplicity and the KISS principle. The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.

(the image from Flickr User Fellowship of the Rich shows an Apple motherboard)

Social networks are like expanding universes

The universe is not static, it is expanding ever since the Big Bang 13.7 billion years ago. It contains billions and billions of stars and galaxies, and it is getting bigger all the time.

Social networks like Google+, Twitter, or Facebook are similar. They do not only contain billions and billions of users and pages, they are also getting bigger all the time. Each day, more users join, and existing users add more content: they add more photos, share more links, and write more posts.

This is the major challenge in the engineering of social networks: to handle a system which is getting bigger all the time. An engineer of such a network is like a cook whose pots are constantly boiling over. He must add more pots each day, and keep the old still cooking.

Facebook was founded in 2004, and it was expanding ever since, gaining more users and more friends each day. Since it does not allow users to quit, and does not delete old content, it grows more and more each day. Twitter was founded in march 2006, and it was expanding ever since that time, too. Each day more users join, existing users gain more followers, and create more tweets. The latest and most advanced social network is Google+, which was started in July 2011 and combines the best features of Facebook and Twitter. It is growing at an ever accelerating rate, too.

The fundamental problem for the engineer is clear: a system which is getting bigger all the time is hard to handle, because it requires nearly unlimited scalability. If the engineers do not consider this from the start, it will be hard to build it later. Apparently, Google has the best prerequisites to master this challenge, it knows how to build scalable systems better than any other company. Some websites say Google is the King of scalability.

(The picture of the accelerating universe is from Wikipedia)

Programming well with others

Recently there was a post at the 37signals blog Signal vs. Noise about the question why programs become territorial. The reason is simple: Programs become territorial because programmers naturally consider their code as their territory. Your code is your work and your creation based on your ideas, right? Therefore as a programmer it is natural to think that your code belongs to you. It is the world you have created. And in his own world the programmer is a little god who knows everything, while everyone else is a mere mortal without superpowers. The own world contains only cities and places the programmer has built himself – so the programmer is the creator, architect, ruler, general, and governor all in one. A programmer which tries to understand the code from someone else has not only lost his superpowers, he is completely lost. It is a bit like being a tourist in a foreign city – you will feel lost in the beginning. Maps in form of database diagrams and UML models help to a certain degree, but even with a map it remains difficult to understand a foreign territory.

Software engineers tend to own their creations. It goes well in two cases: if everybody knows and owns his own part, i.e. if everybody has his own territory, or – if if the territory belongs to the team. This means everybody knows and can change everything, everything is well documented and the team agrees on certain coding standards, policies and guidelines. Unfortunately, working in a team is not easy, because it is difficult to create useful documentation, and programmers do not like giving up their freedom. They like their superpowers. Developers want autonomy, mastery and purpose. Working in a team is difficult, because it means to have a team ego instead of an individual ego. Agreeing on standards does not mean that everyone in the team has to accept tools, libraries and plugins you prefer, rather it means to accept things others prefer more than you, and to abandon personal habits and likes. This is not easy, because programmers are often very opinionated. So the two extremes that work are:

  • The individual rules: team has no strong ego, territory belongs to the individual
  • The team rules: individuals give up their ego, territory belongs to the team

Between those extremes it gets complicated. Code changes can lead easily to personal conflicts if code is owned by people. Therefore developers tend to avoid changing the code from others. Programming well with others is difficult. It certainly requires good communication. Most programmers know how to communicate, but they don’t want to. They want to do it themselves, and they see others as competitors. It takes indeed a bit the fun out of programming if you have to justify and explain every decision to others. To find the right balance between cooperation and competition in a team is not easy. In general, the golden rule helps: One should treat others as one would like others to treat oneself. Do not ignore them, ask others for their opinion, show them your respect, include them in important decisions, explain your architecture, show them your achievements etc. Communication is the glue that keeps groups together. This is the reason why most programmers have difficulties when it comes to programming well with others. They lack social skills, and the only languages they really like are programming languages. They are used to work with machines and not with people.

Ben Collins-Sussman and Brian Fitzpatrick give us some hints how to program well with others. Documentation is important: document your design decisions, your architecture, your goals, your failures, for example on an easy editable Wiki. The ability to communicate is also an important aspect. They argue in this video (and their forthcoming book with the same title) that collaborating and communicating with others is at least as important as having great technical skills. According to Ben and Fitz, the right attitude is important in a team. You should be thinking about “how do I work with a team” and not “how do I present myself as a genius”

Programming Blogs

Hacker news has an interesting list of programming blogs which you should read daily. The blogs from John Resig, Jeff Atwood, James Hamilton, and Joel Spolsky are certainly good. And guess what? Someone even mentioned this humble blog. What programming blogs do you prefer to read?

Steve Wozniak about Engineers

In a recent Google+ comment, Steve Wozniak wrote:

I’ll always be for the poor engineers. They have so much skill and experience but get paid very little. They design the products that change the world but those who write stories about them get paid more. But the thrill of making things yourself is just too strong for real engineers to give up.

How true!

Aircraft-carrier of Authentication

Normal applications are usually protected by authentication modules or plugins. Like warships they protect the application against hostile intruders and regulate who is allowed to get in. In Ruby on Rails one would use RestfulAuthentication or AuthLogic for this purpose. They are powerful and easy to configure, and they provide enough protection for a whole application. Once they are adapted to the application and are able to communicate with it, they work fine.

Big Single Sign-On (SSO) Servers are different. Instead of adapting them to your application, you must adapt your application to them. If normal authentication plugins are like warships, then Single Sign-On (SSO) Servers like Shibboleth and OpenAM are like aircraft-carriers of authentication. They are very powerful, and can protect multiple applications, but they are also very huge, heavy and expensive, because they are complicated to configure and to maintain. They are accompanied by multiple other units, for instance web policy agents (which correspond to airplanes). They operate with highest security measures like SAML. They are powerful weapons once they are configured, delivered and deployed. Unfortunately, it often takes a while until they are ready.

(The picture is from Wikipedia and shows the USS Nimitz)


Get every new post delivered to your Inbox.