How to stop wasting time designing architechture












2














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?










share|improve this question







New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 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
    3 hours ago


















2














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?










share|improve this question







New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 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
    3 hours ago
















2












2








2







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?










share|improve this question







New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question







New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 5 hours ago









JRG

111




111




New contributor




JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






JRG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 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
    3 hours ago
















  • 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
    3 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
3 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
3 hours ago












2 Answers
2






active

oldest

votes


















5















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.)






share|improve this answer























  • Paralysis by Analysis also comes to mind.
    – mike65535
    5 hours ago



















0














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.






share|improve this answer





















    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.










    draft saved

    draft discarded


















    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









    5















    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.)






    share|improve this answer























    • Paralysis by Analysis also comes to mind.
      – mike65535
      5 hours ago
















    5















    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.)






    share|improve this answer























    • Paralysis by Analysis also comes to mind.
      – mike65535
      5 hours ago














    5












    5








    5







    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.)






    share|improve this answer















    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.)







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 5 hours ago

























    answered 5 hours ago









    Telastyn

    92.2k24208317




    92.2k24208317












    • 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




    Paralysis by Analysis also comes to mind.
    – mike65535
    5 hours ago













    0














    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.






    share|improve this answer


























      0














      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.






      share|improve this answer
























        0












        0








        0






        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 4 hours ago









        sul4bh

        374136




        374136






















            JRG is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Quarter-circle Tiles

            build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

            Mont Emei