Branch per feature

Last Friday I have read an article from Mr. Martin Fowler about VCS, focusing in Distributed Version Control System. Although it is an interesting topic, I guess it is a kind of technical discussion if it should distribute or not.
Before someone wants to shoot me, I know that there are advantages over a central system, but the point is that I don't want to highlight it here.

Actually it is much more interesting all the patterns that emerged with this kind of VCS, not because they didn't existed, just because the DVCS makes then simple. So ladies and gentlemen I would like to introduce you the amazing Spider-man!!! Ops… wrong introduction… I would like to introduce you the Feature Branch technique (a.k.a Branch-Per-Feature).

The main idea of this technique is: every new Feature of your software becomes a branch in the version control system, and as soon as this feature is implemented the branch is merged to the baseline. Simple isn't it? There are quite few advantages in this technique, the main one (in my point of view) is that you can release the software with the desired features as soon as they are available.
For example, if you have 3 features on the go, but one of them is important and should be released right now then, just merge it to the baseline and you are ready; the other features are no impacted and your delivery do not need to wait for that.

I don't need to say that to have it working like a charm, continuous integration is a must.

There are two really good articles about it, the first is an introduction about it by Martin Fowler and the second is a How-To about implementing this kind of technique.

• Feature Branch
  
• Branch-Per-Feature Source Control
  

I really got enthusiastic about this kind of source control technique, it is really usefull if you are interested in selling services and not software, so for you last minute services are almost a must.

Have a nice week.

Horror plot in software development!

There are few things in this world that is worth to do over and over again, but I am but that falling in the same stupid errors is not one of them. I have just left a meeting where, for my surprise, people are happy to do it again.
I will put it as example: let's imagine that you have a car factory, your car is not the best in the world, but some people like it. Then you realize that every time that your customer wants a new item into the car (like ABS, radio, etc) you should almost rebuild the car.
After years one of your engineers come up with the brilliant idea: let's build a car that the user can choose what we wants at fly, so if he wants a radio he just tell us and suddenly the radio is there. Uou marvelous isn't it?
Then some more years to develop it, and you finally have the car! But as car stuffs increase people start to say: "you know, let's not make it configurable, it gives us a lot of problem". Sooooo guess what: you end up with the same car as before.
As I told you: the same mistake.

It is like an horror history: doesn't matter how much times do you kill Jason, he will always come back, there will be a lot of blood, a lot of people will died in the way, eventually we could have a happy end (the guy get the girl and that is it); but still a lot of suffering.

The point is: doesn't matter the end, we are still writing horror histories, and there will be blood! We should before changing the players start to think about changing the kind of history, way not action? Or a comedy or a even romance? You know: light stuff!

Going back to our original example: the car was made in the same way, the same approach, way should the result should be different? No way, it will be the same!

About software (yeap it is a software blog): if we keep looking at your application in the same way, they will always look the same. And I am not talking about the technology that we use for that, but the way that we do that.
It should be configurable, let's make it in a way that I could be configurable, not just adding properties. It should be multi environment, let's do in a way that it could be deployed multi environment; and so on.

To finish: in the next article I will add my idea of how a specific kind of enterprise application should be done. Why this kind? In the last years I have faced this kind of application all around and no easy approach to it.

Now you ask me: what kind of application? Well I am writing this post in a thriller way, so you will see it in the next issue ;-)

SPDS - Stupid People Developing Software

Yes, that is!!!!

We are just too stupid to develop good software, or even, to develop a software in the right way. I have just changed my work place, and I am still looking at super heroes all around. I don't see people worried to make the thing in the right way, just to make the thing like a super vilan.
Like a super vilan? Yes that is: instead of just killing the hero they need to create a BIG weapon and tortuous plan, just like us developing software.

If you need to create a file, why don't you create a validator for that, and use it to test? Noooo you need to send it to someone that will read, spend a day to give you an answer about. Or if you integrate with another system, why don't you start makeing good boundery tests? Noooo we still need to call everyone.

You it seens that things are only good when we need to spend at least 5 weekends working. The most that I like from Agile is fast deploy to the user, but no one cares about it; 1, 2 or even 6 months of development and a deploy in the last possible week, is it clever?

No it isnt't. Come on people let's put our brain to work, let's stop playing Superman, let's do you job as we are supposed to do: with wisdom, not just inteligence.

I'AM SICK AND TIRED OT IT!!!!!

How good is your software team?

Last friday a friend of mine send me a interessting link. It is a post from Joel Spolsky about software team quality.

On that post it is proposed 12 questions to analyse your team quality, I don't think that it could garantee you team quality, but for sure missing something like these could cause some impacts on your team quality.

Take a look over there and see what do you think: The Joel Test: 12 Steps to Better Code.

Terminology 2

For those interested in another IEEE document terminology (sorry for those I don't have any link, but I have the document - just send me an e-mail):

• IEEE 610.2-1987: IEEE standard glossary of computer applications terminology
• IEEE 610.3-1989: IEEE standard glossary of modeling and simulation terminology

I hope it could help to make us communicate better.

Terminology

We all know that communication is a great source of problems, and it is not different in software development.
Most of the terms that we use comes from a common sense of its meaning, but it is important to have a source for them. Although the dictionary is a great source for terms (not only the ones related to the software) we need to reference to something more specific.
Talking about software engineering there is two great sources for papers: ACM and IEEE. IEEE released a document: IEEE 610.12/1990 - IEEE Standard Glossary of Software Engineering Terminology, with some terminology. Even if it is from 1990 (a little bit old) it is a good place to start.
As all IEEE documents you are supposed to buy it, but you can read it at this link: IEEE 610.12/1990

Sorry, what is your job?

In my quest for a new job I have found a lot of announcements with some funny job titles. Even in my last work I had a visit card as Software Engineer.
Let's think about it a little bit: what does a software engineer do? Well, in that case I used to be a programmer, as my collegues.
Right now I have at my side the book Software Engineering A Practitioner's Approach (Roger S. Pressman) and it has more than 800 pages. It is difficult to imagine that someone apply all these knowledge at the work, in a simple function. Let's take another kind of Engineer, like the Civil: some are specialist on bridges, other houses, other highways, and some other parts (I don't know - someone can help me on that).
Anyway the point here is: Software Engineering is a set of disciplines and as it you are supposed to work on one of these disciplines, not all of them. You could be a analyst, a designer, a programmer, or anything else.
So next time that someone ask your job or want to make a visit card for you, think about your title - remember that it shows your knowledge about yourself and your work.