Mixing
Approaches to delegating development to team members
I need to set up a team of software developers for a new project. In the past, typically all the developers worked on all the different layers within the app. For example, if a developer had to implement some feature that required a UI and displayed data that was retrieved from the backend, they would be required to write the code for the UI, the business layer and the data access layer (i.e. retrieving data from the backend). This has worked fine and I suppose this is the way most dev teams operate.
However, if you're starting with a team of contractors who are only going to be on the job for 3 to 6 months, does it make sense to use this approach? The issue I see is that each developer could end up writing code that doesn't follow any unified pattern. Sure you could spend the time and write up a lengthy document outlining design patterns to use, coding styles and such. But that seems kind of unnecessary.
I was thinking that a better approach might be if one developer was responsible for the UI, another for the business log and another for handling data access. The advantage to this approach is that each of them could effectively use their own frameworks and design patterns on the layer they are working on. Sure, the different layers may look differently but each layer would be consistent across all their components.
Have you ever taken this approach? If so, I'd appreciate your feedback on how it went.
architecture
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
add a comment |
I need to set up a team of software developers for a new project. In the past, typically all the developers worked on all the different layers within the app. For example, if a developer had to implement some feature that required a UI and displayed data that was retrieved from the backend, they would be required to write the code for the UI, the business layer and the data access layer (i.e. retrieving data from the backend). This has worked fine and I suppose this is the way most dev teams operate.
However, if you're starting with a team of contractors who are only going to be on the job for 3 to 6 months, does it make sense to use this approach? The issue I see is that each developer could end up writing code that doesn't follow any unified pattern. Sure you could spend the time and write up a lengthy document outlining design patterns to use, coding styles and such. But that seems kind of unnecessary.
I was thinking that a better approach might be if one developer was responsible for the UI, another for the business log and another for handling data access. The advantage to this approach is that each of them could effectively use their own frameworks and design patterns on the layer they are working on. Sure, the different layers may look differently but each layer would be consistent across all their components.
Have you ever taken this approach? If so, I'd appreciate your feedback on how it went.
architecture
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
add a comment |
I need to set up a team of software developers for a new project. In the past, typically all the developers worked on all the different layers within the app. For example, if a developer had to implement some feature that required a UI and displayed data that was retrieved from the backend, they would be required to write the code for the UI, the business layer and the data access layer (i.e. retrieving data from the backend). This has worked fine and I suppose this is the way most dev teams operate.
However, if you're starting with a team of contractors who are only going to be on the job for 3 to 6 months, does it make sense to use this approach? The issue I see is that each developer could end up writing code that doesn't follow any unified pattern. Sure you could spend the time and write up a lengthy document outlining design patterns to use, coding styles and such. But that seems kind of unnecessary.
I was thinking that a better approach might be if one developer was responsible for the UI, another for the business log and another for handling data access. The advantage to this approach is that each of them could effectively use their own frameworks and design patterns on the layer they are working on. Sure, the different layers may look differently but each layer would be consistent across all their components.
Have you ever taken this approach? If so, I'd appreciate your feedback on how it went.
architecture
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
I need to set up a team of software developers for a new project. In the past, typically all the developers worked on all the different layers within the app. For example, if a developer had to implement some feature that required a UI and displayed data that was retrieved from the backend, they would be required to write the code for the UI, the business layer and the data access layer (i.e. retrieving data from the backend). This has worked fine and I suppose this is the way most dev teams operate.
However, if you're starting with a team of contractors who are only going to be on the job for 3 to 6 months, does it make sense to use this approach? The issue I see is that each developer could end up writing code that doesn't follow any unified pattern. Sure you could spend the time and write up a lengthy document outlining design patterns to use, coding styles and such. But that seems kind of unnecessary.
I was thinking that a better approach might be if one developer was responsible for the UI, another for the business log and another for handling data access. The advantage to this approach is that each of them could effectively use their own frameworks and design patterns on the layer they are working on. Sure, the different layers may look differently but each layer would be consistent across all their components.
Have you ever taken this approach? If so, I'd appreciate your feedback on how it went.
architecture
architecture
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
asked Nov 20 '18 at 7:58
AndroidDevAndroidDev
10.1k2391167
10.1k2391167
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
That would be a right approach. The most important thing here is API's and your protocols. Its more of a team management issue than the architecture itself.
Consider MVP design pattern.
First you should design your UML and Class diagrams so that each team could follow the right APIs.
For example, this could be done if one team works on API calls and data models. Then they could provide an interface and mock implementation. Other teams that need API calls, might use those interfaces. This way both teams can work synchronized!
This means that if one team is working on VIEW layer, they know what PRESENTER wants or how it works. They know everything about view names, object names, etc. Or if one team is working on PRESENTER layer, they need an interface (API) of Model controllers. So the team that is in charge of working on model layer, has to provide those API's.
This means that you should have the architecture done before anyone starts coding!
Also think modular. If any feature can be divided into different modules, then do it. Provide API for those modules, Then developers of that module can implement it with any library they want. In the end, all the modules will gather together and build the final application.
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
add a comment |
You can consider choosing vertical slice architecture described here by Jimmy Bogard. The benefit is that with minimalistic boilerplate which can be developed in advance or in relatively short period of time, the features development is supposed to be quite isolated from each other which increase safety from the delivery standpoint and mutual impact of the development process. Additionally depending on the requirements of your project you can try to apply CQRS which also imposes certain level of isolation (between command and query flows which can be developed separately) however not so fine grained as in case of vertical slice style but good news is that you can combine them together (see this presentation).
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388533%2fapproaches-to-delegating-development-to-team-members%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
That would be a right approach. The most important thing here is API's and your protocols. Its more of a team management issue than the architecture itself.
Consider MVP design pattern.
First you should design your UML and Class diagrams so that each team could follow the right APIs.
For example, this could be done if one team works on API calls and data models. Then they could provide an interface and mock implementation. Other teams that need API calls, might use those interfaces. This way both teams can work synchronized!
This means that if one team is working on VIEW layer, they know what PRESENTER wants or how it works. They know everything about view names, object names, etc. Or if one team is working on PRESENTER layer, they need an interface (API) of Model controllers. So the team that is in charge of working on model layer, has to provide those API's.
This means that you should have the architecture done before anyone starts coding!
Also think modular. If any feature can be divided into different modules, then do it. Provide API for those modules, Then developers of that module can implement it with any library they want. In the end, all the modules will gather together and build the final application.
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
add a comment |
That would be a right approach. The most important thing here is API's and your protocols. Its more of a team management issue than the architecture itself.
Consider MVP design pattern.
First you should design your UML and Class diagrams so that each team could follow the right APIs.
For example, this could be done if one team works on API calls and data models. Then they could provide an interface and mock implementation. Other teams that need API calls, might use those interfaces. This way both teams can work synchronized!
This means that if one team is working on VIEW layer, they know what PRESENTER wants or how it works. They know everything about view names, object names, etc. Or if one team is working on PRESENTER layer, they need an interface (API) of Model controllers. So the team that is in charge of working on model layer, has to provide those API's.
This means that you should have the architecture done before anyone starts coding!
Also think modular. If any feature can be divided into different modules, then do it. Provide API for those modules, Then developers of that module can implement it with any library they want. In the end, all the modules will gather together and build the final application.
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
add a comment |
That would be a right approach. The most important thing here is API's and your protocols. Its more of a team management issue than the architecture itself.
Consider MVP design pattern.
First you should design your UML and Class diagrams so that each team could follow the right APIs.
For example, this could be done if one team works on API calls and data models. Then they could provide an interface and mock implementation. Other teams that need API calls, might use those interfaces. This way both teams can work synchronized!
This means that if one team is working on VIEW layer, they know what PRESENTER wants or how it works. They know everything about view names, object names, etc. Or if one team is working on PRESENTER layer, they need an interface (API) of Model controllers. So the team that is in charge of working on model layer, has to provide those API's.
This means that you should have the architecture done before anyone starts coding!
Also think modular. If any feature can be divided into different modules, then do it. Provide API for those modules, Then developers of that module can implement it with any library they want. In the end, all the modules will gather together and build the final application.
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
That would be a right approach. The most important thing here is API's and your protocols. Its more of a team management issue than the architecture itself.
Consider MVP design pattern.
First you should design your UML and Class diagrams so that each team could follow the right APIs.
For example, this could be done if one team works on API calls and data models. Then they could provide an interface and mock implementation. Other teams that need API calls, might use those interfaces. This way both teams can work synchronized!
This means that if one team is working on VIEW layer, they know what PRESENTER wants or how it works. They know everything about view names, object names, etc. Or if one team is working on PRESENTER layer, they need an interface (API) of Model controllers. So the team that is in charge of working on model layer, has to provide those API's.
This means that you should have the architecture done before anyone starts coding!
Also think modular. If any feature can be divided into different modules, then do it. Provide API for those modules, Then developers of that module can implement it with any library they want. In the end, all the modules will gather together and build the final application.
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
edited Nov 21 '18 at 6:33
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
answered Nov 21 '18 at 6:27
Sep GHSep GH
540419
540419
add a comment |
add a comment |
You can consider choosing vertical slice architecture described here by Jimmy Bogard. The benefit is that with minimalistic boilerplate which can be developed in advance or in relatively short period of time, the features development is supposed to be quite isolated from each other which increase safety from the delivery standpoint and mutual impact of the development process. Additionally depending on the requirements of your project you can try to apply CQRS which also imposes certain level of isolation (between command and query flows which can be developed separately) however not so fine grained as in case of vertical slice style but good news is that you can combine them together (see this presentation).
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
add a comment |
You can consider choosing vertical slice architecture described here by Jimmy Bogard. The benefit is that with minimalistic boilerplate which can be developed in advance or in relatively short period of time, the features development is supposed to be quite isolated from each other which increase safety from the delivery standpoint and mutual impact of the development process. Additionally depending on the requirements of your project you can try to apply CQRS which also imposes certain level of isolation (between command and query flows which can be developed separately) however not so fine grained as in case of vertical slice style but good news is that you can combine them together (see this presentation).
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
add a comment |
You can consider choosing vertical slice architecture described here by Jimmy Bogard. The benefit is that with minimalistic boilerplate which can be developed in advance or in relatively short period of time, the features development is supposed to be quite isolated from each other which increase safety from the delivery standpoint and mutual impact of the development process. Additionally depending on the requirements of your project you can try to apply CQRS which also imposes certain level of isolation (between command and query flows which can be developed separately) however not so fine grained as in case of vertical slice style but good news is that you can combine them together (see this presentation).
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
You can consider choosing vertical slice architecture described here by Jimmy Bogard. The benefit is that with minimalistic boilerplate which can be developed in advance or in relatively short period of time, the features development is supposed to be quite isolated from each other which increase safety from the delivery standpoint and mutual impact of the development process. Additionally depending on the requirements of your project you can try to apply CQRS which also imposes certain level of isolation (between command and query flows which can be developed separately) however not so fine grained as in case of vertical slice style but good news is that you can combine them together (see this presentation).
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
answered Nov 22 '18 at 10:38
h1ybadger1h1ybadger1
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388533%2fapproaches-to-delegating-development-to-team-members%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
