If there’s a work that need frontend and backend developers to work together, should they:
-
Pair programming all the times? When it’s backend work, frontend developer is navigator, backend developer is driver and vice-versa. This would most time-consume and I don’t really sure it’s has benefit enough for all time wasted.
-
Pair programming with only some part like only API part that need to communicate the data with each other. Frontend may need to know some database structure to be able to pair with backend too.
-
Just do the API Documentation together and after that, just do their own work base on the API Documentation. (Fastest way but I don’t know if there will be any drawback).
P.S. They work at the same place and can ask the others anytime when they do not understand something.
In my opinion there are the following advantages of pair programming:
- Two peope check the logical consistency along the way
- The code gets more readable and understandable
- Annoying bugs and typos are more likely to be found while writing the code
- One person can write tests/documentation alongside
The main connection between front- and backend are interfaces. Good interfaces can be the result of pair programming, but I think that the interfaces should be defined before you start writing the code.
I personally would roll with the third point but I also think that there is nothing wrong with the second point if the development team is small. I dislike the first point, because I think that pair programming between two programmers with the same field of activity will be more productive.
In layman’s words:
- In pair programming both partnerts get to drive and to navigate on the same codebase, so 1st point is not what one would call pair programming.
- If things are done right, frontend dos not need to know the structure or the database.
- Writing documentation before writing the code is at most atypical
My suggestion:
– have a couple of programmers pair-program the frontend and a couple of programmers pair-program the backend.
– If you only have two programmers then make them pair-program the backend, then the front end.
– If both frontend and backend need to advance simultaneously (and you have only two programmers) then let each programmer do his/her work by his/her own.
Yes, why not.
What you get from pair programming is the benefits of someone else looking at an overview of what’s happening with the code, while the main coder gets caught up in the details. You also gain from the spread of knowledge that will transfer between the two.
So in this case, your back end guy will code up the interface the front end guy will later consume, and will know the interface he’ll be presented with later – he can also suggest additions because he’ll know what data he wants there and then, saving the costly rework later. And vice versa.
Both guys will gain knowledge of the product from an unfamiliar area, will see it being used and tested and will know the configuration and setup of it. Even if they don’t become cross-area developers, the benefits will still be seen in overall product knowledge.
3
It Depends
I worked in a very small shop where we were all on billable hours. You were assigned the entire task front-end, back-end (which included any database stuff) and the specified hours. After a year or so of doing all the tasks individually we decided to team up and work together. I was much more suited for javascript error trapping and backend stuff especially database work. My buddy was much more suited for front end stuff and configuration.
We decided to team up, pool our work and hours. It worked out great.
I focused on backend stuff building my pieces so I could plop them inside a set of <div></div> tags.
My buddy did the layout work knowing all I needed was as set of <div></div> tags.
I would then jump on all the javascript error tapping and he did all the configuration.
Each of us focused on what we were stronger at. More work got done with less stress.
2