Foreword

This document aims to help you understand how technologies, process and people are integrated in an effective web development team. I will not cover motivational techniques, or leaders teachings among the whole history that could help you to manager your team better.

Here I am more interested in structures, workflows, tools and concepts. A naïve try to merge many sparse modern concepts and tools.

This is an amateur work, the first try of many – and I am very open to criticism, suggestions and commentaries.

In the first part, I will cover some theoretical concepts.

In the second part, I will use these concepts and build practical ideas.

Section I – Sorting Professionals.

Whatever the workflow adopted, whatever the tools chosen and whatever the environment is set – people are the entities that make the team machine work.

As a machine, there are different parts which are capable of doing each thing needed in the whole scenario.

Choosing and incorporating the appropriate professionals is fundamental to make this team work, and although it is obvious yet this is often neglected due to budget constraints or some sort of Cowboy Coding privileges.

Two basics types of sorting immediately arises: by competence and by expertise. Let us see each one of them.

By competence, in all branches of softwarecraft:

- Apprentices –  has begun in the craft, usually is learning the first language and tries to solve the problems through brute-force only with no understanding of choices and consequences. Demands a lot of attention and support in order to be productive. May turn out to be productivity suckers of another people, a Journeyman or Master who would be coaching and supervising him on the task being developed.

- Journeyman - is experienced and demands little supervision. When one achieves this point usually has begun to specialise in some segment of the craft. One’s skills set are robust and getting bigger. They are not yet able to cross really complicated problems among several different segments of the craft. For instance, one team of solely journeymen would have great difficulties to develop an Image server integrated into a HTTP server, storing files in a tailor-made filesystem on the top of a XFS partition. And yes, this has been done, in Facebook. (http://www.facebook.com/note.php?note_id=76191543919)

- Master - I borrow the description of The Pragmatic Programmer: From Journeyman to Master:

• Early Adopter / Fast Adapter
• Inquisitive
• Critical Thinker
• Realistic
• Jack-of-all-trades – in my words, consummated cross-skills thinker and inventor.

By expertise, in Website Development:

• Web Designers
• Usability Engineers
• Interface Coders
• Business Logic Engineers
• Database Developers
• Testers

I will not explain these roles, but their names are quite self-explanatory and the most important concept of all is: the maturity of your team and project will expose the need for each kind of these people.

The most common composition I’ve seen is: Web Designer, Interface Coder and Business Logic Engineer. Coincidently, it fits in the MVC structure, which shall be approached later.

I shall name this composition Standard Web Development Team.

]]> http://blog.cirello.org/2010/07/29/web-development-team-process-howto/feed/ 0 http://blog.cirello.org/2010/07/23/sysadm-suicidal-letter/ http://blog.cirello.org/2010/07/23/sysadm-suicidal-letter/#comments Fri, 23 Jul 2010 22:38:42 +0000 Dérico Filho http://blog.cirello.org/2010/07/23/sysadm-suicidal-letter/ /dev/null make no-sense life; exit 1;]]> # !/bin/bash
echo “” &> /dev/null
make no-sense life;
exit 1;

Por via de regra “don’t take anything for granted” comigo.

Assim, é muitíssimo provável que esteja interessado, que queira viajar, que vá para o Rock ou que vá atrair você. Mas ao observar estes eventos você nunca terá certeza.

Se você perceber bom humor e brincadeira, não estranhe se de repente desaparecer. É quântico, quando você observa o bom humor, ele não está lá.

Será que eu escrevi para você de verdade? Ou quando você me perguntar, eu não estarei lá para responder?

Humn… Adoro física quântica. Sinto-me uma partícula de Higgs…

P.S.: e por falar em partícula de Higgs, estou com Richard Dawkins, embora não duvide de sua sinceridade, você está halucinando!

Should you see two girls with equal physical traits of beauty, the sweeter one will be prettier. Although I would not be any expert in such affairs, I do have one possible and likely explanation.

Sweet people are more relaxed, in almost every aspect of life. They are less bounded by imposed standards of dress code, behaviour, or social life style.

Should they feel to dress funnier one day, they will do – and if they mess up, they just do not care, and their faces, expressing happiness, are going make you to stare in the face, pretty and relaxed instead of looking the wrong dressing.

The sweetness is capable of neutralising such defects.

These personality traits above described are admirable shades of outer beauty. They are of very special kind: the only-nice-people-may-have kind.

I have had the opportunity to meet such a girl. So sweet and lovely.

She is beautiful, and her kindness makes her better.

One day, I asked her: “Why are you so beautiful?”

She paused and answered she was not beautiful, and argued that her friends were perfect, bodily speaking.

They may have better bodies, yes… Would this make them more beautiful than her? No.

It is a crazy opinion, but it is my honest opinion.

Kammy Te Kanawa, you are beautiful. And you should know that.

Métodos poucos ortodoxos de aula.

Mas não é exatamente da aula que eu quero falar. Quero falar sobre a turma.

Veja, eu só assisto aula com a turma de IPBD uma vez por semana, as demais aulas é com outra turma. Tenho pouco tempo para me integrar com eles…

Eu já comecei faculdade algumas vezes, por via de regra as turmas de 1o. Ano/Semestre são bem bagunceiras.

Curiosamente esta turma de IPBD, que é de 1o. Semestre, é quieta, calminha, interessada…

Mas acho que tem mais a ver com o professor, que é de dar sono, que dá uma materia mobral e chata, não tem como se empolgar e fazer algazarra…

Minha soneca de sexta a noite agradece.

A matéria é ótima, pena que já tive antes… Se o professor desse algo mais divertido como Conceitos Fundamentais de Tuning de BD, aposto que o clima seria outro.

Bom, a aula já tá acabando, e o “feriadão” está aí.

Meta de amanhã: zerar 123i.com.br

Como o dia é feriado, e sempre bate um bode de trabalhar no feriado, fiz uma lista de cinco coisas para se fazer nestes feriados de um dia.

1. Visitar ou ligar para um amigo que você não vê faz tempo.
2. Passear no parque ou na praia (se você mora na praia).
3. Assistir a um DVD que você esqueceu no fundo da gaveta ou na estante.
4. Ficar algumas horas no StumbleUpon
5. Jogar algum jogo de tabuleiro, não video-game.

Agora com certeza algumas coisas para não se fazer no feriado

1. Óbvio, trabalhar, mesmo que você tenha trabalho atrasado.
Aproveite a folga para recarregar as baterias.
2. Jogar video-game.
3. Ir ao shopping (coisa típica de paulistano)
4. Fazer compras
5. Ir almoçar fora num lugar bem gordo.

Bom, parece que o meu feriado vai ser parado mesmo…

I work in a real state agency. This company has its own management system which deals with customer database, customer relationship management, product database and product export to other external system of advertising.

It has been developed by 6 years now, and passed by the hands of 8 programmers (or interns) so far. And until the lastest one, adding more man power to its development always uncovered a sad feeling of Brook’s Law.

Brook’s Law dictates that “adding man power to a late software project makes it later”. Actually it really happened. After hiring a new programmer it took at least 3 months of intensive training, which approached quality (5s, Kaizen and PDCA) and some programming skills such OO, MVC and Design Patterns.

This thorough training should supposedly prepare the hired programmers to a supposed high-level of coding. Well, the code was not that high-leveled and the programmers always had to struggle with so many standards that they could not produce code.

There was never a roadmap or formal product release. Indeed in the beginning, the changes were made directly into the code and bugs fixed later. I guess when nothing is yet done, act quick-and-dirty or worse-is-better is a good atittude.

OK, it may have hurted some ears around. I am not defending them as a real alternatives for software development. What I am saying is: they are great choices to evolve from NOthing to SOMEthing. Let me explain it a bit further.

The company I work on was founded by a group of Internet investors. They had no previous experience on real state market. They had money and wanted to invest. One lunatic among them decided to burn his cash in a real state agency in the rotten brazilian market.

Alright. If you are producing a software to a company runned by an expert in the market, usually the biggest problem you could have would be how translate some business needs into technical specification.

However, If you are producing a software to a company runned by a lunatic that simply has no idea of what it is taken to do the business, then your greatest is problem is doing something almost completely off your mind – if the CEO has no idea and you have no idea – anything, even a bad thing, is better than nothing.

This lack of identity reflected the source code’s organisation, robustness and stability. Actually, a paleontologist could dig four differente eras of coding.

The first one made by four hands and it’s completely quick and dirty. The second one a bit more organised, but yet worse is better approach (the great change was moving from VI to Samba Shared file access). The third one with better structured code. And the last one developed with OO/MVC/All the letters that are G&W.

Thus, teaching the new-comers about the system had do cope with all these generations of coding and thoughts.

Why that last one has been different?

The last hiring was completely different on many aspects.

First, the hired programmer was a better professional. I am not talking about technical skills – I am mean a more matured and seasoned person. A young company with young employees behaves childishly – spending more than needed with wrong people.

Second, the company knows better its needs and what it expects from employees. It means that the business needs are more easily translated into technical specifications.

Third, the oldest codes are no longer changed. They work (sometimes badly) and they do not demand more maintenance. All the code produced is related to new needs, therefore I need to teach fewer things one to new employees.

Adding man power in these conditions is easy. Brook notice the projects delays when he realised that new programmers could not add production immediately because they needed to be taught. And that’s the whole issue.

The more one programmer need to learn in order to begin working – the longer it’ll take to make him productive.

When the teacher knows the things to be conveyed, it is easier. On the other, when there is no teacher (or no knowledge), it is the famous Research and Development – not funded, not supported and only demanded.

Does it ever happened to you?