Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. The Software Architecture Demon

The Software Architecture Demon

Scheduled Pinned Locked Moved The Lounge
csssharepointdesignsysadminoop
62 Posts 25 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Rage

    honey the codewitch wrote:

    not spend odd hours studying someone else's work just so they can use it

    Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.

    honey the codewitch wrote:

    I'm also going to come out and say it makes things harder to maintain

    No. Over-engineered code or undocumented code is hard to maintain, whether it has been created based on highly sophisticated design patterns and architecture principles or "by hand", but you cannot say that using architecture design always makes code harder to maintain. 15 year old multi threaded spaghetti code resulting from a 15-year-old-company-time one guy developer show is hard to maintain. Always. Actually, UML or SysML are tools, and as every tool, they should be used adequately to fulfil a certain purpose to make sense. I agree that using a tool just because you can is not a good strategy, but on the other side and like any tool, they can come very handy if well used.

    Do not escape reality : improve reality !

    H Offline
    H Offline
    honey the codewitch
    wrote on last edited by
    #12

    I agree to a point.

    Rage wrote:

    Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.

    This is how it should be. In my professional experience it was sometimes the case that a software project would be designed appropriately for its size and the team situation. In many cases, it simply wasn't. People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death. Is it as common as badly designed or simply undesigned software? No. Is it destructive and harmful to projects? Yes! I guess to sound cliche it's about moderation. You have to make the design appropriate for a project. I'm not dismissing UML entirely either. But it's is one of those things that strikes as having the perception of being far more useful than it actually is.

    Real programmers use butterflies

    R Greg UtasG S 3 Replies Last reply
    0
    • Sander RosselS Sander Rossel

      Most of my code goes directly into (ASP.NET Core) Controllers and PageModels nowadays. I have a Core project, which has code shared between all my projects and a SqlServer project for my database stuff. Then a Services project which has some common services, like Smtp, some Azure stuff, etc. All injected using the default .NET Core DI library. Sometimes I think, maybe I'll need this piece of code in another page later on, but then I ignore that thought. When (if) I actually need to re-use that code it's just a minor refactoring to move it to the Core, SqlServer or Services project. I recently made some NuGet packages for functions I use over and over in different projects. I'm also not concerned with keeping my copy/pasted functions up-to-date in every project anymore. It works in older projects in its current state, so no need to "fix" what isn't broken there. And that's how I roll nowadays, KISS and YAGNI :D

      Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript

      H Offline
      H Offline
      honey the codewitch
      wrote on last edited by
      #13

      It sounds like you've got a good handle on things. :)

      Real programmers use butterflies

      Sander RosselS 1 Reply Last reply
      0
      • R RickZeeland

        Good point, I'm not unfamiliar with UML, in our shop it was all done years ago and luckily I did not have to redesign any parts I'm working on. Sometimes when I see articles on CodeProject about architecture I wonder if the person who wrote it was bored and had nothing better to do than writing lengthy theoretical and incomprehensible articles. :-\

        H Offline
        H Offline
        honey the codewitch
        wrote on last edited by
        #14

        Yes to this. Glad I have some support here. Everyone but you and Sander are all sideeying me now. :laugh:

        Real programmers use butterflies

        R enhzflepE 2 Replies Last reply
        0
        • H honey the codewitch

          I agree to a point.

          Rage wrote:

          Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.

          This is how it should be. In my professional experience it was sometimes the case that a software project would be designed appropriately for its size and the team situation. In many cases, it simply wasn't. People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death. Is it as common as badly designed or simply undesigned software? No. Is it destructive and harmful to projects? Yes! I guess to sound cliche it's about moderation. You have to make the design appropriate for a project. I'm not dismissing UML entirely either. But it's is one of those things that strikes as having the perception of being far more useful than it actually is.

          Real programmers use butterflies

          R Offline
          R Offline
          Rage
          wrote on last edited by
          #15

          honey the codewitch wrote:

          You have to make the design appropriate for a project

          Agreed, and this exactly is what should be (also) taught in CS courses.

          Do not escape reality : improve reality !

          1 Reply Last reply
          0
          • H honey the codewitch

            Niemand25 wrote:

            agree that overdesign is a waste of resources, yet underdesign tends to cause much more damage.

            I'm not advocating for doing away with the design phase. I also think that while what you say is true, people are also taught this heavily, and I think they take too much to heart. Maybe that's what it is too? Maybe people get so afraid of a deathmarched project that they overengineer everything?

            Real programmers use butterflies

            N Offline
            N Offline
            Niemand25
            wrote on last edited by
            #16

            As you agreed in other post. Overdesign is rare if compare to underdesign. Which makes its impact quite low. At the moment I'm angry with myself as I one more time cut corners due to time pressure, disrespected SRP and now fixing my mess :doh: I guess the time pressure is the reason for underdevelopment and (for the most part) effectively prevents overdevelopment. Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.

            H 1 Reply Last reply
            0
            • N Niemand25

              As you agreed in other post. Overdesign is rare if compare to underdesign. Which makes its impact quite low. At the moment I'm angry with myself as I one more time cut corners due to time pressure, disrespected SRP and now fixing my mess :doh: I guess the time pressure is the reason for underdevelopment and (for the most part) effectively prevents overdevelopment. Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.

              H Offline
              H Offline
              honey the codewitch
              wrote on last edited by
              #17

              Niemand25 wrote:

              Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.

              That's probably why I see so many offending projects posted at CP. :laugh: Rarer in the field sure, but when you have a pointy haired boss who just heard about UML at a conference and now wants to impose it on every project it can make it near impossible to make deadlines.

              Real programmers use butterflies

              N 1 Reply Last reply
              0
              • H honey the codewitch

                I used to be a software architect. I think that's part of why I employ such a jaundiced eye when it comes to layered service architectures and sweeping design patterns just because and drowning in UML because reasons. It's true that when you're dealing with million dollar implementations, multiple deployment points, and disparate teams a lot of this abstraction can be useful. But how common is that in most people's development? I know it is for some of you, sure, but I think you're in the minority, or at least projects like these are in the minority. Not everyone is Plum Creek or Alcoa. It seems like the field of software architecture has taken on a life of its own and coupled with CPU cores to waste and infinite scaling out it has - and i'll just say it - poisoned software development. Just because you know how to do something doesn't mean you should. Most software application architectures do not survive contact with clients plus the erosion of time. They have a shelf life of significantly less than 10 years without some major portion of them being retooled. There are exceptions to this, but designing every solution to be that exception is a waste of time, money and creative energy. I'm also going to come out and say it makes things harder to maintain. When you're working with 20 different classes and interfaces where 3 would do it just increases the learning curve. There are definitely diminishing returns when it comes to decoupling software from itself, and you run into the cost/benefit wall pretty fast. It can only take you so far. It's best not to overdo it. Every fancy little UML entity you drop into your project increases the cognitive load of your project for other developers. Personally, I wouldn't care about that, because "cognitive load" is fun as far as I'm concerned but most people just want to do their work and go home, not spend odd hours studying someone else's work just so they can use it. Keep It Simple Stupid. Whatever happened to that? :sigh:

                Real programmers use butterflies

                P Offline
                P Offline
                PIEBALDconsult
                wrote on last edited by
                #18

                "Simplify, simplify" -- Thoreau I totally agree, but I prefer to work alone anyway. I never begin with much of a plan, I simply begin and see where it goes. Twice I recall being handed a "spec" for something I was to develop, but I ignored them and did what I knew was right -- one of the specs was actually dangerous. Specs always come from people who have no idea what they're doing, but want to appear smarter than the people who do. For one personal project, I made kind of a grid to track which features needed to be developed, which didn't, and which I had completed, but that's about it.

                N H 2 Replies Last reply
                0
                • H honey the codewitch

                  Niemand25 wrote:

                  Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.

                  That's probably why I see so many offending projects posted at CP. :laugh: Rarer in the field sure, but when you have a pointy haired boss who just heard about UML at a conference and now wants to impose it on every project it can make it near impossible to make deadlines.

                  Real programmers use butterflies

                  N Offline
                  N Offline
                  Niemand25
                  wrote on last edited by
                  #19

                  Bosses are ... well ... bosses :) Not the worst case, I met a head of DBA's in one international company who never heard of normal forms. Discussion between her and reporting team was marvellous. She couldn't understand why reporting team are so much displeased about xml in fields. It is so easy to parse, isn't it? :cool:

                  H 1 Reply Last reply
                  0
                  • H honey the codewitch

                    Yes to this. Glad I have some support here. Everyone but you and Sander are all sideeying me now. :laugh:

                    Real programmers use butterflies

                    R Offline
                    R Offline
                    RickZeeland
                    wrote on last edited by
                    #20

                    Just heard a line "we all stand together" on the radio: The Frog Chorus & Paul McCartney - We All Stand Together - YouTube[^] :-\

                    1 Reply Last reply
                    0
                    • P PIEBALDconsult

                      "Simplify, simplify" -- Thoreau I totally agree, but I prefer to work alone anyway. I never begin with much of a plan, I simply begin and see where it goes. Twice I recall being handed a "spec" for something I was to develop, but I ignored them and did what I knew was right -- one of the specs was actually dangerous. Specs always come from people who have no idea what they're doing, but want to appear smarter than the people who do. For one personal project, I made kind of a grid to track which features needed to be developed, which didn't, and which I had completed, but that's about it.

                      N Offline
                      N Offline
                      Niemand25
                      wrote on last edited by
                      #21

                      Sometimes its not that there is any choice :) The Expert (Short Comedy Sketch) - YouTube[^]

                      P 1 Reply Last reply
                      0
                      • H honey the codewitch

                        I agree to a point.

                        Rage wrote:

                        Part of the architecture is to structure the system, or the code, exactly so that people who want to do this can do it, and are not bothered with higher level topics.

                        This is how it should be. In my professional experience it was sometimes the case that a software project would be designed appropriately for its size and the team situation. In many cases, it simply wasn't. People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death. Is it as common as badly designed or simply undesigned software? No. Is it destructive and harmful to projects? Yes! I guess to sound cliche it's about moderation. You have to make the design appropriate for a project. I'm not dismissing UML entirely either. But it's is one of those things that strikes as having the perception of being far more useful than it actually is.

                        Real programmers use butterflies

                        Greg UtasG Offline
                        Greg UtasG Offline
                        Greg Utas
                        wrote on last edited by
                        #22

                        honey wrote:

                        People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death.

                        Wow. I guess the world has changed since I last had a salaried job, because I only saw this twice in over 20 years. The second time, I realized what would eventually happen, so I transferred to another group and built the appropriate subset of the same thing that a team of 30 or 40 were working on.

                        Robust Services Core | Software Techniques for Lemmings | Articles
                        The fox knows many things, but the hedgehog knows one big thing.

                        <p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
                        <em>The fox knows many things, but the hedgehog knows one big thing.</em></p>

                        H 1 Reply Last reply
                        0
                        • P PIEBALDconsult

                          "Simplify, simplify" -- Thoreau I totally agree, but I prefer to work alone anyway. I never begin with much of a plan, I simply begin and see where it goes. Twice I recall being handed a "spec" for something I was to develop, but I ignored them and did what I knew was right -- one of the specs was actually dangerous. Specs always come from people who have no idea what they're doing, but want to appear smarter than the people who do. For one personal project, I made kind of a grid to track which features needed to be developed, which didn't, and which I had completed, but that's about it.

                          H Offline
                          H Offline
                          honey the codewitch
                          wrote on last edited by
                          #23

                          It takes a certain talent to be able to code like that, and I respect it. Naturally I do, because I'm much the same way when left to my own devices. It's useful to know architecture, UML and all of that mess just to be able to communicate with people who speak it, and I will concede that huge projects with large teams pretty much demand architecture and pre-planning but otherwise just let me at the code.

                          Real programmers use butterflies

                          1 Reply Last reply
                          0
                          • H honey the codewitch

                            I used to be a software architect. I think that's part of why I employ such a jaundiced eye when it comes to layered service architectures and sweeping design patterns just because and drowning in UML because reasons. It's true that when you're dealing with million dollar implementations, multiple deployment points, and disparate teams a lot of this abstraction can be useful. But how common is that in most people's development? I know it is for some of you, sure, but I think you're in the minority, or at least projects like these are in the minority. Not everyone is Plum Creek or Alcoa. It seems like the field of software architecture has taken on a life of its own and coupled with CPU cores to waste and infinite scaling out it has - and i'll just say it - poisoned software development. Just because you know how to do something doesn't mean you should. Most software application architectures do not survive contact with clients plus the erosion of time. They have a shelf life of significantly less than 10 years without some major portion of them being retooled. There are exceptions to this, but designing every solution to be that exception is a waste of time, money and creative energy. I'm also going to come out and say it makes things harder to maintain. When you're working with 20 different classes and interfaces where 3 would do it just increases the learning curve. There are definitely diminishing returns when it comes to decoupling software from itself, and you run into the cost/benefit wall pretty fast. It can only take you so far. It's best not to overdo it. Every fancy little UML entity you drop into your project increases the cognitive load of your project for other developers. Personally, I wouldn't care about that, because "cognitive load" is fun as far as I'm concerned but most people just want to do their work and go home, not spend odd hours studying someone else's work just so they can use it. Keep It Simple Stupid. Whatever happened to that? :sigh:

                            Real programmers use butterflies

                            O Offline
                            O Offline
                            obermd
                            wrote on last edited by
                            #24

                            This is just as true for "frameworks". When was the last time a generic framework actually did what you wanted it to do?

                            H Greg UtasG 2 Replies Last reply
                            0
                            • Greg UtasG Greg Utas

                              honey wrote:

                              People would endlessly decouple things that only one person was ever going to work on, and this kind of thing happens all the time. The design would end up taking up the majority of the bandwidth even well past the design phase after the project was supposed to be nailed down. I've seen projects deathmarch over it even. Basically the project was thought to death.

                              Wow. I guess the world has changed since I last had a salaried job, because I only saw this twice in over 20 years. The second time, I realized what would eventually happen, so I transferred to another group and built the appropriate subset of the same thing that a team of 30 or 40 were working on.

                              Robust Services Core | Software Techniques for Lemmings | Articles
                              The fox knows many things, but the hedgehog knows one big thing.

                              H Offline
                              H Offline
                              honey the codewitch
                              wrote on last edited by
                              #25

                              I was a software architect and consultant working primarily in project rescue. I came across all kinds of trash fires.

                              Real programmers use butterflies

                              1 Reply Last reply
                              0
                              • H honey the codewitch

                                I used to be a software architect. I think that's part of why I employ such a jaundiced eye when it comes to layered service architectures and sweeping design patterns just because and drowning in UML because reasons. It's true that when you're dealing with million dollar implementations, multiple deployment points, and disparate teams a lot of this abstraction can be useful. But how common is that in most people's development? I know it is for some of you, sure, but I think you're in the minority, or at least projects like these are in the minority. Not everyone is Plum Creek or Alcoa. It seems like the field of software architecture has taken on a life of its own and coupled with CPU cores to waste and infinite scaling out it has - and i'll just say it - poisoned software development. Just because you know how to do something doesn't mean you should. Most software application architectures do not survive contact with clients plus the erosion of time. They have a shelf life of significantly less than 10 years without some major portion of them being retooled. There are exceptions to this, but designing every solution to be that exception is a waste of time, money and creative energy. I'm also going to come out and say it makes things harder to maintain. When you're working with 20 different classes and interfaces where 3 would do it just increases the learning curve. There are definitely diminishing returns when it comes to decoupling software from itself, and you run into the cost/benefit wall pretty fast. It can only take you so far. It's best not to overdo it. Every fancy little UML entity you drop into your project increases the cognitive load of your project for other developers. Personally, I wouldn't care about that, because "cognitive load" is fun as far as I'm concerned but most people just want to do their work and go home, not spend odd hours studying someone else's work just so they can use it. Keep It Simple Stupid. Whatever happened to that? :sigh:

                                Real programmers use butterflies

                                M Offline
                                M Offline
                                Mircea Neacsu
                                wrote on last edited by
                                #26

                                Like everything in life and art, there are two faces to this coin: at one extreme you have spaghetti code and at the other you have massive libraries of hundreds of classes and structures (I'm looking at you LEDA and BOOST). The golden path is in the middle. Our job is to find that middle path. I heard someone saying that engineering is the art of finding when one is approximately equal to two and when one is much smaller than two. I let you with these two quotes: “Everything should be made as simple as possible, but no simpler.” - A. Einstein "You should be glad that bridge fell down - I was planning to build thirteen more to the same design" - Remark attributed to I. K. Brunel, addressing the Directors of the Great Western Railway.

                                Mircea

                                H 1 Reply Last reply
                                0
                                • O obermd

                                  This is just as true for "frameworks". When was the last time a generic framework actually did what you wanted it to do?

                                  H Offline
                                  H Offline
                                  honey the codewitch
                                  wrote on last edited by
                                  #27

                                  Yes. Although I'll grudgingly accept that for its size, Microsoft did a fair job with the .NET BCL

                                  Real programmers use butterflies

                                  1 Reply Last reply
                                  0
                                  • M Mircea Neacsu

                                    Like everything in life and art, there are two faces to this coin: at one extreme you have spaghetti code and at the other you have massive libraries of hundreds of classes and structures (I'm looking at you LEDA and BOOST). The golden path is in the middle. Our job is to find that middle path. I heard someone saying that engineering is the art of finding when one is approximately equal to two and when one is much smaller than two. I let you with these two quotes: “Everything should be made as simple as possible, but no simpler.” - A. Einstein "You should be glad that bridge fell down - I was planning to build thirteen more to the same design" - Remark attributed to I. K. Brunel, addressing the Directors of the Great Western Railway.

                                    Mircea

                                    H Offline
                                    H Offline
                                    honey the codewitch
                                    wrote on last edited by
                                    #28

                                    Mircea Neacsu wrote:

                                    “Everything should be made as simple as possible, but no simpler.” - A. Einstein

                                    I *almost* dropped that quote in my rant, and I bring it up all the time when it comes to software. :laugh:

                                    Mircea Neacsu wrote:

                                    "You should be glad that bridge fell down - I was planning to build thirteen more to the same design" - Remark attributed to I. K. Brunel, addressing the Directors of the Great Western Railway.

                                    Haha it's funny because it's true!

                                    Real programmers use butterflies

                                    1 Reply Last reply
                                    0
                                    • N Niemand25

                                      Bosses are ... well ... bosses :) Not the worst case, I met a head of DBA's in one international company who never heard of normal forms. Discussion between her and reporting team was marvellous. She couldn't understand why reporting team are so much displeased about xml in fields. It is so easy to parse, isn't it? :cool:

                                      H Offline
                                      H Offline
                                      honey the codewitch
                                      wrote on last edited by
                                      #29

                                      Hahaha whoops. Although in fairness, I *became* a DBA out of necessity because a lot of smaller shops I worked for in the late 90s and early aughts had nobody and no clue. I can respect having to learn on the job, but the key is to *learn* on the job.

                                      Real programmers use butterflies

                                      1 Reply Last reply
                                      0
                                      • O obermd

                                        This is just as true for "frameworks". When was the last time a generic framework actually did what you wanted it to do?

                                        Greg UtasG Offline
                                        Greg UtasG Offline
                                        Greg Utas
                                        wrote on last edited by
                                        #30

                                        Well, a framework isn't supposed to do anything!

                                        Robust Services Core | Software Techniques for Lemmings | Articles
                                        The fox knows many things, but the hedgehog knows one big thing.

                                        <p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
                                        <em>The fox knows many things, but the hedgehog knows one big thing.</em></p>

                                        1 Reply Last reply
                                        0
                                        • H honey the codewitch

                                          It sounds like you've got a good handle on things. :)

                                          Real programmers use butterflies

                                          Sander RosselS Offline
                                          Sander RosselS Offline
                                          Sander Rossel
                                          wrote on last edited by
                                          #31

                                          If only :sigh: Been hurting my brains over some stupid .NET Framework Azure AD Authentication thing all day and I've got nothing. I even asked a question in Q&A about it, first one since 2018 :omg:

                                          Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript

                                          H 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups