Announcement Announcement Module
Collapse
No announcement yet.
Controller vs Service vs private method on command object. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16

    Quote:
    It's not that the idea of elegance and simplicity is a wrong idea. It is very difficult to achieve, yes.
    Which effectively makes it useless (or impracticable) for the wast majority of projects - it can be several times and finished with standard approaches in the time needed to find really elegant solution.
    You are basically stating that any talentless idiot can and should be a software engineer, and therefore the good SE practices are useless because most of those people are not capable of following them! It's like saying that - when training musicians - selecting musically talented kids and teaching them to play piano is a useless approach. Instead, anyone should be given a piano and sent to a recording studio - since it's unrealistic to expect everyone to be talented musicians.

    My point is: if you are a far-sighted IT manager, filter out the ones that just don't cut it (the ones who will never learn because they lack talent, dedication, interest, intelligence, whatever...) Then define the priorities correctly: focus on creating quality software. You, on the other hand, seem to advocate hiring just about anybody and letting them do whatever they please - as long as they eventually can get the damn thing to work... Unfortunately, that's what often happens, and the results are usually just pathetic. A simple project (simple for any good SE) would often turn into a nightmare - with no end in sight. In my own experience, it takes significantly less time and effort to deliver elegant software to QA and Production than delivering a patchy, poorly-designed mess. ALWAYS. In fact, the latter, most often turns into never-ending projects. Bad programmers start coding first, think later. It's because they are constantly in the state of panic. They doubt their ability to deliver anything ever - in the first place. So, they are always in a hurry to show some - any - results. They skip the design (the thinking) part! Proper designs (elegant, clean, simple) don't work for people who should not be programmers in the first place. Everyone else must be taught to do the right thing, and they will soon see how efficient the process becomes. I am amazed that you are arguing with this! I usually see this kind of resistance from the people who try to justify their incompetence, but I can tell that you are clearly NOT one of those people. Perhaps, it's just the "hobby" you've mentioned that makes you do that...

    Of course, that brings us to the real problem: many "programmers" should be, in fact, doing something else instead of programming. This is a very unfortunate consequence of the mass-production software phenomenon you have mentioned. Since we can't solve the problem once and for all, it is up to individual IT managers (many of whom are just as incompetent to know better) to identify the good candidates, pay them what they deserve, and get their project done without glitches. The companies that don't do such selection will [continue to] suffer the consequences: the buggy software, never-ending projects, working in the fire-fighting mode late ours and weekends - on things that could have been successfully delivered by just a few good SEs, really fast, and for much less money than the organization blows on the project developed by the "average" SEs using the "standard approaches."

    A couple of years ago I was hired by a huge insurance company to work on a system previously developed by another [well-known] consulting company in a course of a year. They had paid that consulting firm ~$1M to develop that system. (Small peanuts for my client...but about $1M too much for the kind of product that was delivered.) When I arrived, the local programmers had been working on bug fixes for that system literally every day. Something would break every single day. It was a continuous sustaining effort, a full-time job for the IT department. Then the company needed to add support for a couple of new (but similar) products to the system and asked me to look into it. It turned out that the system was hard-wired to work only with the original set of products, and any small tweaks would result in the whole thing all but falling apart. Not to mention, the code was atrocious, incoherent, with just plain mistakes that indicated that the programmers didn't understand some of the very basic things about Java, programming, or architecture. I redesigned and completely implemented - from scratch - the whole system, in just over two months. It went into QA, and for the first 2 weeks they had found no bugs! I know, it is unusual, and normally I do expect QA to find bugs in my code, but this was an easy project to me.) Later the client called a couple of times with requests for minor adjustments. That's it. If I had done that project from the very beginning - not that other consulting firm, all it would have taken is a few months at a fraction of cost. Instead, the client paid my cost + $1M, and wasted a year, plus a bunch of grief having to deal with everyday bugs whose fixes produced more bugs every day... I am sure that those lousy programmers who wrote the original version also would justify their crap with time constraints, requirements that were not clear, deadlines, and other external factors that would make "clean" design "unrealistic." It's all nonsense! It is always just an excuse incompetent people use. Anyone who is competent, who is capable of producing quality software will tell you that thoughtful, elegant, and clean solutions always ensure a faster delivery. They also ensure minimal maintenance costs throughout the life-cycle of the software.

    I hope we are done discussing this...
    Cheers,
    C

    Comment


    • #17
      Originally posted by constv View Post
      You are basically stating that any talentless idiot can and should be a software engineer, and therefore the good SE practices are useless because most of those people are not capable of following them!
      It is severe misinterpretation of my words.
      I said that for mass-production software it is enough to follow good software practices, you need not to be overly talented to create usable system.

      It's like saying that - when training musicians - selecting musically talented kids and teaching them to play piano is a useless approach. Instead, anyone should be given a piano and sent to a recording studio - since it's unrealistic to expect everyone to be talented musicians.
      It is rather as difference between average village smith and top-notch armorer. Existence of latter does not eliminate a need in a former.

      My point is: if you are a far-sighted IT manager, filter out the ones that just don't cut it (the ones who will never learn because they lack talent, dedication, interest, intelligence, whatever...) Then define the priorities correctly: focus on creating quality software. You, on the other hand, seem to advocate hiring just about anybody and letting them do whatever they please - as long as they eventually can get the damn thing to work...
      Purely your imagination - if there is a possibility way that you like is definitely preferable. But there are external constraints - there are existing employees that you can not fire due to contractual obligations and such, there are limited presence of people of desired quality on the job market, and so on, and so on. And you have job on hands that you have to perform on time on budget. So you have to use whatever you have in an optimal way.

      Unfortunately, that's what often happens, and the results are usually just pathetic. A simple project (simple for any good SE) would often turn into a nightmare - with no end in sight.
      To prevent it, it is enough to have a few (sometimes one) capable persons strategically placed on key points - to prevent idiotic decisions.

      In my own experience, it takes significantly less time and effort to deliver elegant software to QA and Production than delivering a patchy, poorly-designed mess.
      There many grades in between.

      ALWAYS.
      NEVER SAY NEVER.

      They skip the design (the thinking) part!
      Design is a F-word in software development and should be prohibited and each developer that write it - fined. Code is design!
      But eliminating of design should not eliminate thinking, really, it should promote it.

      I am amazed that you are arguing with this! I usually see this kind of resistance from the people who try to justify their incompetence, but I can tell that you are clearly NOT one of those people.
      I guess you completely misunderstood me. I do not argue with your statement - it is an ideal goal in the ideal world. But we live - and work - now and here. And have to balance our desires with ours - and others - capabilities and capacities. So we always have to make compromises. Elegant is simple, but simple is not always elegant. And often we have to do with just simplicity and maintainability, but without elegance
      It went into QA, and for the first 2 weeks they had found no bugs! I know, it is unusual, and normally I do expect QA to find bugs in my code, but this was an easy project to me.)
      Not so much unusual - I have similar experiences. One system (store logistic) that I have developed circa 3 years ago runs bug-free on customer site from day one. There were only single complaint and even that after proper investigation was attributed to the peer system that has not properly implemented agreed protocol.

      with time constraints, requirements that were not clear, deadlines, and other external factors that would make "clean" design "unrealistic." It's all nonsense! It is always just an excuse incompetent people use.
      While they indeed like to use such arguments that do not necessarily make those arguments invalid. Another sample (yes, it was clear management error but it has nothing to do with software development as such). I was working in one company which has developed quite advanced fork-lifter control system (assignments selection, route optimization, monitoring, ...) for a customer. Not very big project, something like 2 months for 2 developers. Development was successfully finished about 10 day in advance. Then in a couple of day comes company owner and says - customer does not wont fork-lifter control system any more, he wants access control system instead. And to the same deadline.

      So we converted first system to second one. You may understand that a lot of elegance was sacrificed (while about 80 percent of code was reused).

      Anyone who is competent, who is capable of producing quality software will tell you that thoughtful, elegant, and clean solutions always ensure a faster delivery.
      Do not agree - better software, yes, for sure. Faster delivery - probably, not.
      Yes, it will be faster comparing to messy, spaghetti-style software, but not in comparison which was intentionally developed as intentionally reasonable compromise of driving forces. To find such degree of compromise is some kind of art by itself.

      There are bad, messy solutions.
      There are perfect, nice, elegant solutions.
      And there are solutions that are not perfect, but are "good enough".

      If take in my previous analogy with armorer and smith - there is Excalibur and there is plow.


      They also ensure minimal maintenance costs throughout the life-cycle of the software.
      Such elegant solutions tend to have one major drawback - rely on some set of basic assumptions and while these assumptions are hold such solutions are very easy to maintain, but as soon as one of the assumptions is broken it becomes as bad as any messy system if not worse, Often complete redevelopment is required.

      I hope we are done discussing this...
      Seems so. But if you want to continue, then better in the private messages or emails as it clearly becomes off-topic.

      Comment


      • #18
        Such elegant solutions tend to have one major drawback - rely on some set of basic assumptions and while these assumptions are hold such solutions are very easy to maintain, but as soon as one of the assumptions is broken it becomes as bad as any messy system if not worse, Often complete redevelopment is required.
        This is literally opposite to what I consider elegant. Elegance in software does not mean "pretty" with a cherry on top - at the cost of flexibility, reusability, and other essential parameters. It implies the adaptability and reasonable re-usability of the participating modules. If a small change in requirements causes a major re-work, it means the design is flawed. There's no elegance in it. It also implies such organization of your code that any changes would be localized, confined to as small part of the system as possible. If you were able to reuse 80% of your code after a major last minute change in requirements, that means good design to me.

        Finally, by "Design" I do not mean "Design Documentation". I mean mental processing of the task and working out the vision of the system, its major components, and how they fit together to ensure flexibility, adaptivity to ever-changing requirements, etc. Such Design is a never-stopping process that continues to go hand-in-hand with every line of code you write. It includes constant re-factorings. The initial design, to me, may involve a white-board session or two, a few scribbles on a piece of paper, putting together a few classes and developing/clarifying the idea and the vision as I go...

        Peace,
        C

        Comment


        • #19
          If a small change in requirements causes a major re-work, it means the design is flawed. There's no elegance in it. It also implies such organization of your code that any changes would be localized, confined to as small part of the system as possible.
          You have heavily misinterpreted (or misunderstood) my words one more.
          I would try to explain once more - solutions that you name elegant are immune to minor and some not so minor (sometimes even major) requirement changes - save changes in some set of basic assumptions on which they are built. If one of this assumptions becomes broken, the whole system needs (practically) complete redevelopment or extremely ugly patching . If have selected that set of assumptions properly, you won, but if not, then you in much bigger trouble then with "good enough" and, probably, even with the"the mess from the start" system. And exactly selection of this set is the most complicated part of the software development, as your customers may 10 times confirm "this or that can not never, ever occur, it just impossible" but then in few months it becomes clear that there are situations when "this or that" occurs regularly.

          Finally, by "Design" I do not mean "Design Documentation". I mean mental processing
          But in SW design has some other stable meaning. So if you always says table meaning chair there are slim chances that you would be understood properly.

          Cheers,
          Oleksandr

          Comment


          • #20
            solutions that you name elegant are immune to minor and some not so minor (sometimes even major) requirement changes ...
            And what... it is better if your solution breaks if you change one tiny little thing?

            - save changes in some set of basic assumptions on which they are built. If one of this assumptions becomes broken, the whole system needs (practically) complete redevelopment or extremely ugly patching .
            This is where your mind-boggling, incomprehensible talent for demagogy kicks in again! Which hypothetical assumptions are you talking about? Have you no shame - to pull such empty, unsupported statements right out of your a$$? Oh, let me guess, you had once written software that was supposed to be working on a space shuttle, but one day before the deadline, the manager asked you to convert it into a shopping cart application?? And this kind of twisted logic is supposed to make me believe that it is safer and more practical to forgo programming discipline and good structure in favor of all-in-a-big-pile applications with no "basic assumptions", whatever the hell that means?

            But in SW design has some other stable meaning. So if you always says table meaning chair there are slim chances that you would be understood properly.
            No! The word "Design" in the English language - as well as in Software Engineering - does not mean "Documentation". But, I am sure you'd be happy to school me on the English language as well...

            Oleksandr, you seem to favor arguing only for the sake of expressing a strong opinion that contradicts someone else's point, almost regardless of what they are saying. (No doubt, people have told you that before!) Your arguments always follow the same pattern: you pick a statement or concept, then pretend that it was meant to be an absolute fact in 100% of all life situations, with no marginal conditions or exceptions, regardless of any contexts. Then you make an absurdly obvious point that there may be marginal cases when something else may be sufficient. Or, you provide your own inaccurate interpretation of what the other person is saying, and argue with that, and so on... So, I see no point in continuing this. All I know is that I have my ways of building software that have not let me down so far. And vouch for a disciplined approach that promotes elegance and minimizes complexity. I don't need to have a rigid definition of what all these concepts are. I define them based on common sense.

            Cheers.

            Comment


            • #21
              Originally posted by constv View Post
              And what... it is better if your solution breaks if you change one tiny little thing?
              Surely, not. Never have said it.


              This is where your mind-boggling, incomprehensible talent for demagogy kicks in again! Which hypothetical assumptions are you talking about? Have you no shame - to pull such empty, unsupported statements right out of your a$$?
              Rather from almost 30 years of experience in professional software development.
              is supposed to make me believe that it is safer and more practical to forgo programming discipline and good structure in favor of all-in-a-big-pile applications with no "basic assumptions", whatever the hell that means?
              I never, ever have contradicted programming discipline and good structure, it purely your imagination. But neither good structure, nor best of best programing discipline does not guarantee elegance. It seems that you forgot one word in the elegance definition "Elegance is the attribute of being unusually effective and simple."
              And this unusually makes all of the difference.
              To reach it you have to go out of ordinary, often way out of ordinary, otherwise it would be good, professional, stable, manageable (you name it) solution, but not elegant one.

              No! The word "Design" in the English language - as well as in Software Engineering - does not mean "Documentation".
              It should not mean it, but for wast majority of peoples it means, sorry, look here http://en.wikipedia.org/wiki/Software_design - it accurately reflects mass consciousness in SW development. And compare it with general meaning of Design here - http://en.wikipedia.org/wiki/Design.

              Yes, I 100% agree with you that it is misuse of word, but it is long established misuse.

              But, I am sure you'd be happy to school me on the English language as well...
              No way, you have to give up this hope

              Or, you provide your own inaccurate interpretation of what the other person is saying, and argue with that, and so on...
              I dare to say that you employ this technique to much greater extent that I do.
              And vouch for a disciplined approach that promotes elegance and minimizes complexity.
              Disciplined approach - for sure, as I have said many times I'm 100% on your side on this matter, but it is not enough for elegance, sorry. Such approach (together with careful thinking) may bring simple and effective solution - but not necessarily (and even likely) unusually simple and effective.
              I don't need to have a rigid definition of what all these concepts are.
              Yes, for your own use you need not such definitions, but as soon as you start to explain them to others you have to provide such definitions to have a chance to be understand properly (and even then "Does not matter how clear you explain something, anyway somebody would misunderstand you" ).
              I define them based on common sense.
              Rather on your own (while pretty good) sense.

              Cheers.[/QUOTE]

              Comment


              • #22
                And because all our controversy was really about terminology, I put my definition of "elegant solution"
                it is not just "simple and effective solution that merely follows set of well-established rules", but "simple and effective solution that establishes new set of rules that other would follow on".
                And this new set of rules brings its unusualness.

                Comment

                Working...
                X