Skip to content

Totally distributed

Some new software development models have appear recently. One of them is the distributed model. It can be used to structure a project in various ways, but the founding concept is that everyone owns a full working copy of the project and is not directly tied to a central authority.

In one of my previous post, I wrote about the distributed way of managing source code and what differences it make compared with the common solutions that are used today. Before going any further, here are the benefits I see when using a distributed revision control mechanism:

  • Offline support (commits, branches, merges)
  • You are your own working copy and you can share changes with others in the way you want
  • You are your own working copy and you can break it apart, test it, try experimental things. You are free to play with it.
  • Flexible structure for changes flow (someone has to pull changes from you - aka the Linux model, everyone push/pull to a central repository - aka the central model, someone has to pull changes from you to check that they meet a certain quality and push them somewhere else, etc)

This is great if you are only managing source code, but there are many different things you have to manage for a software project to be successfull. How does it translate in the distributed model ? Some projects like the ones under the Mozilla umbrella are using a distributed revision control software for their code and some central models for other part of the their projects. This is fine, but there are some alternatives.

I discovered some interesting distributed aware tools to complement your distributed revision control software for documentation and bug, issue or task tracking.

It is still early to tell if we are going to see a push towards even more distributed tools like these. We can surely benefit from using these tools in a proper way. I will keep an eye onto it.

Posted 23 February 2009 § Software development § Technology ‡ Comments (0) °

Letting go

Holding tight by jbelluch

Holding tight by jbelluch

How hard should you hold onto your ideas? Do you really need full control of everything happening around you? What about trusting people and finding the answers with them?

It is time to let go. Tomorrow is too late. Now is the time.

Back when I started building my first program, I never thought I would enter a religion war zone by making my initial steps in the software development world. There should be a warning sign for this on every tutorials and introduction textbooks about programming.

Warning ! You are making your first steps in dangerous zone. Prepare yourself or you will get sucked in as well.

Everyone seems to know what is best for everyone else. Client will tell you how you should use the session to get a better performing application. Your colleague will tell you how you should you the database to get the best performance possible.  Your boss will tell you which colour you should use to make your application usable.

Developing software the hard way by Cliff Hanger

Developing software the hard way by Cliff Hanger

Let’s start with clients. Most clients I worked with wanted total control over the scope, the schedule and the cost of the project. They know how to do software development. One of the problems, is that they were given that control. More precisely, they were given the illusion of it. Giving that much control to your client is like developing upside down while being tight up. It is not going to work.

I think the first step toward redemption is to educate and explain to your clients what it is to develop software. It is surely not like manufacturing hammers.

One point I would like to emphasis is the requirements. I have seen way too often requirements made of all must-haves. I think it should have a good proportions of must-haves and nice to haves so that the scope become variable and can be adjusted to meet more important schedules or costs.

People in the software industry are known to have strong opinions. They will argue for hours over whether that technology is superior or better than another. They often suffer from the silver bullet syndrome, but the usual answer is it depends. Every solution has a cost, some advantages and some weaknesses. We should learn them and give educated answers about those technologies.

Posted 14 February 2009 § Philosophy § Software development ‡ Comments (0) °

Code of conduct

Ancient philosophers by Lawrence OP

Ancient philosophers by Lawrence OP

Being a software developper gives you a whole lot of possibilities. You are often given confidential documents. You have access to confidential data that most people would not have access too.

I was once maintaining an online shop where every credit card was stored with a simple symmetric cipher with the key in plain text in the code. I could have use all those credit card records if I was unethical but I did not. You should probably not trust at least 50% of every online shops with your private data these days.

I recently created a personal training plan to get better at software development. I searched for some references on the web and I found this document. It is called the Software Engineering Code of Ethics and Professional Practice. It is a highly interesting text which I endorse. I suggest you read it too and endorse it in your own way.

Since I am not part of the official software engineering community, I never had to follow any code of conduct. This code is well written. It express so many good ideas that I can only make it my own by approving it. If you are in the software development field and you do not have any ethical guidelines, have a look and pass it down to your colleagues.

Posted 05 February 2009 § Philosophy § Software development ‡ Comments (0) °

Building up social skills

Communication problems by Tania Paz

Communication difficulties by Tania Paz

Some weeks ago, I realized something important. Software development is first and foremost a task about communication. It is not the kind of communication happening on network links. It is about human communication.

A programmer will typically have to speak or communicate with his fellow programmers, the analyst, the architect, the projet manager, the customer, the tester, the documentation writer, the graphist, his boss, his coworkers’ bosses, the customer’s boss, the project owner and many others. There are many potential pitfalls.

Analyzing it from my point of view, I think many programmers have social skill problems.  When I say “many”, I do include myself in that group. I think certain kind of personalities makes you like computer science or at least, it makes it more enjoyable. The environment in which you grow up is also a factor which may drive you to this discipline.

On the Myers-Briggs personality scale, I am an INTP. Which can be resume with the following:

  • I for introversion which oppose extroversion
  • N for intuition which oppose sensing
  • T for thinking which oppose feeling
  • P for perception which oppose judgement

In short, I was not easily interacting with people. It has lead me to a slow progression toward social skills. Those skills which make you good at interacting with people and communicating with them. Those same skills which make you understand how people are feeling, what they are going through and adjust yourself to this reality. Those same skills which are essential in software development.

There is only one way out: trying to get better.

This is what I have been trying to do since than. I think so far it is working. Even my girlfriend has noticed.

My first goal was simple. “I will try to engage a discussion in a kindly manner with whoever I meet.” It seems simple, but for someone who has tried to stay in his bubble for as long as possible, it can be hard. So far, I think I have met that goal even though I still have some defiling moments when I just do not want to speak with anyone.

Recently, I bought How to Win Friends & Influence People. This book was recommended in a software developement book. I thought it would make sense to buy it and have a look. I did not buy it to make more friends or manipulate people. I bought it for the social lessons it contains. I have read a few pages so far and I will probably post an update when I finish it.

Another possibility I am currently thinking about is taking some communication classes. Those kind of open courses where you can go in whenever you want.

Social and communication skills are often disregarded by software developpers. I think it is time we change our view and see just how usefull they are.

Posted 26 January 2009 § Philosophy § Software development ‡ Comments (0) °

Encoding problems

A nice paper typography by Caro Wallis

A nice paper typography by Caro Wallis

Storing, managing and displaying characters should be easy. It seems like this is not the case yet.

Encodings are a way to store and recall sequence of symbols like a string in a binary format. For instance, the ASCII encoding map the sequence “abc” to the binary format of 0110 0001 0110 0010 0110 0011 so we can send it through a network link, store it in a file or save it in memory.

Encodings are absolutely needed. We would not be able to work with text in a computerized way without them. They pose a problem because they are misunderstood and misused.

Encoding problems are not rare. They are not uncommon. They are endemic. They are so present in my daily life that I do not even pay attention to them anymore. They are present in small software up to the multimillion projects.

Here is the latest example of this problem.

One of my Amazon Canada bill. They cannot correctly spell my name.

One of my Amazon Canada bill. They cannot correctly spell my name.

One of my Amazon US bill. They know how to spell my name.

One of my Amazon US bill. They know how to spell my name.



Even Amazon has problems with encodings in different systems. No wonder is it a plague among other software too. Having a character out of English language symbol set in your name is a common way to spot this kind of problem.

In the Good Old Days, when computer had to run on quite limited space in terms of memory, storage and bandwith, there were many different encodings for different languages. In order to display or find out which symbols you could construct from a giving binary representation you had to know which encoding was used to encode them.

Nowadays, we have Unicode. Unicode is an attempt at mapping every known character symbol for every currently used languages. It even maps ancient and mostly instinct language symbols.

Unicode has many ways to encode its big table in a binary format. The common ones are UTF-8 and UTF-16. UTF-8 maximize compatibility with ASCII. A text containing strictly ASCII characters will have the same binary representation using the ASCII encoding or the UTF-8 encoding.

A common mistake is that the world lives in English. My recommendation is to take your next vacation week in a small town in Japan to find out if they live in English. Another common mistake is just plain not knowing that character symbols are encoded to binary format and decoded from binary format. I have known many programmers who did not know. I did not know before I had the same kind of problems that Amazon Canada currently have. Colleges and universities should teach this kind of stuff, but that is another discussion.

The most common mistake is going from one encoding to another without thinking about possible loss of precision. You cannot go from Unicode to ISO-8859-1 without possibly losing many characters in the process. Think about it. Unicode version 5.1 maps 100713 symbols while ISO-8859-1 maps 191 symbols. There is a big gap between these two.

Unicode is no silver bullet, but in doubt, you should use it. There is not many reasons why you should not use it. Applying it in every cases in every systems should be the norm.

Posted 14 January 2009 § Software development ‡ Comments (1) °

Central control, central power

2009 is here. My new year resolution is actually a wish. I wish we move towards a more decentralized way of doing things wheter it is within the political system, within companies, within open source projects, the way we create things.

The more I think about it, the more it make sense to do it. How can a central unit, person or group know what is the right thing for all the other people?

There are some situations which require a decision to be taken that goes against the will of the majority or that a decentralized model cannot find an easy way to settle on it but it is just the right thing to do. A good example is the plastic bag tax. In many countries where it was first announced to impose a tax on plastic bag in order to lessen the use of them, people were against it. The results after a few months is that plastic bag usage drop significantly, people change their habits, they change their mind and actually promote the use of reusable bags.

We should find a way to isolate those cases and resolve them with a strong decision making process like a benevolent dictator, but the normal way of resolving problems should come from the bottom and not the top.

By the way, happy new year !

Posted 02 January 2009 § Philosophy ‡ Comments (2) °