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/2007/12/10/my-company-and-brooks-law-why-hiring-a-new-programmer-delays-the-whole-company-schedule/ http://blog.cirello.org/2007/12/10/my-company-and-brooks-law-why-hiring-a-new-programmer-delays-the-whole-company-schedule/#comments Mon, 10 Dec 2007 04:56:05 +0000 Dérico Filho http://blog.cirello.org/2007/12/10/my-company-and-brooks-law-why-hiring-a-new-programmer-delays-the-whole-company-schedule/ Continue reading →]]> Hi!

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?