How to stop wasting time designing architechture
I have recently graduated from uni and started working as a programmer. I don't find it that hard to solve "technical" issues or do debugging, things that I would say have 1 solution. But there seems to be a class of problems that don't have one solution -- things like software architecture. These things befuddle me and cause me great distress.
I spend hours and hours trying to decide how to "architect" my programs and systems. For example, do I split this logic up into 1 or 2 classes, how do I name the classes, should I make this private or public, etc. These kinds of questions take up so much of my time, and it greatly frustrates me. I just want to create the program, the architecture be dammed.
How can I more quickly get through the architecture phase and onto the coding and debugging phase, which I enjoy?
design
New contributor
add a comment |
I have recently graduated from uni and started working as a programmer. I don't find it that hard to solve "technical" issues or do debugging, things that I would say have 1 solution. But there seems to be a class of problems that don't have one solution -- things like software architecture. These things befuddle me and cause me great distress.
I spend hours and hours trying to decide how to "architect" my programs and systems. For example, do I split this logic up into 1 or 2 classes, how do I name the classes, should I make this private or public, etc. These kinds of questions take up so much of my time, and it greatly frustrates me. I just want to create the program, the architecture be dammed.
How can I more quickly get through the architecture phase and onto the coding and debugging phase, which I enjoy?
design
New contributor
1
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago
add a comment |
I have recently graduated from uni and started working as a programmer. I don't find it that hard to solve "technical" issues or do debugging, things that I would say have 1 solution. But there seems to be a class of problems that don't have one solution -- things like software architecture. These things befuddle me and cause me great distress.
I spend hours and hours trying to decide how to "architect" my programs and systems. For example, do I split this logic up into 1 or 2 classes, how do I name the classes, should I make this private or public, etc. These kinds of questions take up so much of my time, and it greatly frustrates me. I just want to create the program, the architecture be dammed.
How can I more quickly get through the architecture phase and onto the coding and debugging phase, which I enjoy?
design
New contributor
I have recently graduated from uni and started working as a programmer. I don't find it that hard to solve "technical" issues or do debugging, things that I would say have 1 solution. But there seems to be a class of problems that don't have one solution -- things like software architecture. These things befuddle me and cause me great distress.
I spend hours and hours trying to decide how to "architect" my programs and systems. For example, do I split this logic up into 1 or 2 classes, how do I name the classes, should I make this private or public, etc. These kinds of questions take up so much of my time, and it greatly frustrates me. I just want to create the program, the architecture be dammed.
How can I more quickly get through the architecture phase and onto the coding and debugging phase, which I enjoy?
design
design
New contributor
New contributor
New contributor
asked 5 hours ago
JRG
111
111
New contributor
New contributor
1
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago
add a comment |
1
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago
1
1
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago
add a comment |
2 Answers
2
active
oldest
votes
Perfect is the enemy of good.
That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.
But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.
(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
add a comment |
What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.
But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
JRG is a new contributor. Be nice, and check out our Code of Conduct.
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%2fsoftwareengineering.stackexchange.com%2fquestions%2f384861%2fhow-to-stop-wasting-time-designing-architechture%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
Perfect is the enemy of good.
That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.
But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.
(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
add a comment |
Perfect is the enemy of good.
That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.
But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.
(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
add a comment |
Perfect is the enemy of good.
That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.
But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.
(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)
Perfect is the enemy of good.
That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.
But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.
(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)
edited 5 hours ago
answered 5 hours ago
Telastyn
92.2k24208317
92.2k24208317
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
add a comment |
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
Paralysis by Analysis also comes to mind.
– mike65535
5 hours ago
add a comment |
What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.
But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.
add a comment |
What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.
But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.
add a comment |
What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.
But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.
What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.
But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.
answered 4 hours ago
sul4bh
374136
374136
add a comment |
add a comment |
JRG is a new contributor. Be nice, and check out our Code of Conduct.
JRG is a new contributor. Be nice, and check out our Code of Conduct.
JRG is a new contributor. Be nice, and check out our Code of Conduct.
JRG is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Software Engineering Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fsoftwareengineering.stackexchange.com%2fquestions%2f384861%2fhow-to-stop-wasting-time-designing-architechture%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
1
By doing a lot more of it. You'll figure out what does and doesn't work. Notice that asking the question here is following the same trend of discussion without the context of actual code: time that could be spent learning by doing. Debating this stuff is fun, and certain patterns are objectively better than other ones, but it's really really hard to have a meaningful opinion without experience (read: scars).
– Jared Smith
4 hours ago