Web Development

Question

Hi, Lets take a website project with a number of team members and it has a number of features. During the development, Is it better for same guy to do one complete feature(DB,Application Logic,Frontend(Javascript,HTML,CSS etc)) or Is it better for the different guy to do the Application Logic and Frontend. In most of the cases, DB is done by some other guy I think. What is the recommended way to do this.

Answer 1

As with most subjective questions, it depends.

I tend to fall in the camp of specialized skill sets. In which case, make them work to their strengths. Better to focus on one thing done really well. If you want those devs to have broad expertise, maybe rotate roles on the next project, but don't try to do the jack-of-all-trades stuff. You end up with a lot of diluted skill sets and nobody can dig in really deep and solve the especially hairy problems without hackery.

Answer 2

The answer to this question depends on the people involved and the size of the project.

In general it is easier to keep each layer of the application coherent if there is a single person writing the layer (horizontal separation), but with a close knit team of good devs, you could slice a project vertically and organize the labor by actual "features."

Working horizontally like you suggest breeds less overall knowledge of the application, since each dev knows their layer, and not the other layers.

Answer 3

Regardless of which way you slice it, you want to make sure that there is some redundancy in the knowledge and understanding of each developers focus. So where I might focus on one feature or layer, there is at least one other developer with a good understanding of my work. This way, the entire project cannot be derailed by one key developer leaving the company.

Answer 4

Steve, it is so difficult to say what is better unless you specify a particular goal.

I think that if all parts of the task are assigned to a single person, the task will be completed faster. This is because in this case we can save on communication: explaining the idea of implementation, dividing task into parts, assigning parts to other people, negotiating responsibilities, etc.

On the other hand, if there are many specialists involved, it can result in much higher quality of the implementation (provided you have educated and experienced people). But it is more like to take more time and money.

Finally, it is up to your to decide, what is better: faster, cheaper or higher quality. For critical tasks of the project I'd go for quality, for non-critical I'd go for speed.

Answer 5

Im sure when you get to organizations such as myspace,facebook and google you cant have just one person working on code.

I think the best way to tackle a situation is by logging everything and explaining what work/changes they have made.

For example if my partner works on some feature for my site he will be required to document and explain in full the changes he has done or implemented and also explain what his code is doing and how it integrates into the rest of the system.

This way when i come along i can see that he has made a change to the system in the Input class and he has explained how he has secured one of the latest XSS Attack or what ever.

So when i read His code i already know:

• What the purpose of the code.
• How the code implements into the rest of he system.
• Why it was necessary.
• Its main purpose and functionalities .

The main part of being a team is communication so having such a system that will provide the communication would be vital.

People tend to work great on there own because there's no need for the communication. but as you grow and expand you have to be able to structure your application and team you need to make sure that you can have 20 people doing different things but they all know what is going on within the application as they see a "Change Log" as such.

My opinion is that a team is better than a singular person.

Answer 6

I think, that for small teams, it is normal if the programmers do just the coding(including DB development) and the other gays to do the CSS and other design part. If the programmers are enough, they can separate their work and everyone to create his own module(part from the project) starting from the database and finishing with the embedding the logic and the design.

Answer 7

As people say, it depends on the project but the way we work everyone is expected to have basic skills right down the architecture stack from web front end, through java to SQL and they take functional areas to work on doing the whole thing.

That works for us because most of our front end and SQL stuff is relatively simple so in depth skills are rarely needed here, and because our work neatly fragments into nice size functional chunks. If that's not the case with you then it won't work.

As a rule if this is possible I think this works best as within each bit of functionality you get someone who is focused on the complete end product and as a result you end up with a better user experience. You also reduce the dependencies between individuals in the team which means you're less likely to have people wasting time waiting for someone else to finish something.

Exceptions to this I tend not to mess around with:

• Designers - developers generally produce ugly web work and designers generally write poorer code. I'd usually consider designer a specialist role for anything where the front end is key.

• DBAs - if you have a complex database then you want a DBA (or at least a developer with solid experience) to pull that all together and keep it solid. In extreme cases they'll more than pay for themselves in the optimisation they do and the hardware savings.

But as a rule I like generalists. There are exceptions but for the most part I don't believe that the sort of systems being developed by most companies have a level of complexity which demands, for instance, a JBoss specialist who does nothing else.

Answer 8

You should ask your employees what they like to do...and then after talking with your boss and clients you will tell each to do what he does best :)

---

As every project manager knows there is a plan and there is a reality - two different things :)

What is your plan: to complete one single project as fast, as cheep and as good as possible? Or maybe you want to build a quality happy team that MIEGT give you better results and more flexibility in the future.

Search for a moment for an answer and you better make it solid before you continue and face the reality...

Have an answer good... Now you are attacked with contradicting demands by your manager, your client, your own team and maybe by your colleagues. Your employees want to learn new staff or not to learn at all, your boss doesn't care who the work as long as it done in the same time and quality he is used to from your best man and your client makes sure to build up the pressure as the project falls behind schedule.

---

Conclusion:

If you can't remember when the last time you finished a task on time - don't search for adventures. This challenge, promising as it might be – can and will be interpreted as the inability of the manager to do his job – "of course the project fails... tasks are done by the wrong people!"

If you are on top of your duties... you can ask your employees if they want to break the routine and work on different tools. My guess is that after they will stop being suspicious, they will become more interested in the job, more happy and motivated and find out that working for you opens new opportunities for them...

---

Human, sadly, are not machines - they make cracking sounds even when everything is OK - if you best man makes a sound give him a teaser of what he wants so he will still do 90% of his main project.

Answer 9

I strongly prefer feature by feature development. Mostly because if you finish 80% of the features, you have a working app, but if you finish 80% of the layers, you've got nothing.

It's all a question of what you're optimizing for. Developing feature-by-feature allows you to get a new version out faster. It also helps you find gaps in your architecture where it doesn't support your features. But it requires people to have general skills -- Everyone needs to be able to do a little database design, a little middleware coding, and a little front-end layout. They don't have to be brilliant, but they have to be able to know when they're at the edge of their skill and call for help.

Developing layer-by layer allows you to get the most out of your exports, but you run into some dangers. If your database guy doesn't understand the front-end requirements, you DB may be organized in ways that require the front end to make many queries. If your middleware is developed in an OO manner, you may have the "Impedance Mismatch" with your database or front end. You may also end up with things being built in the wrong layer, because "we can't wait for the middleware to be updated, so we'll just do it in the front end."

In my experience, there's always more we want to do than we have time for. I prefer feature-by-feature development, because I can delay features to version 2 and release a useful site. I can't delay a layer, leaving me with schedule slips.