Why does it do that thing?

Discussion in 'OT Technology' started by Peyomp, Feb 14, 2007.

  1. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    I fix one bug I make a new one. I add new feature I break old on and in the end it is the better.

    Why does it do that thing on me? That thing?

    Then it becomes. That thing. It leaves me and is its own and I've got NOTHING and its just me and my thing and its left.

    then find another bug. Or call it a feature at first. It will cover you in its sticky web and you'll have to cut the whole thing out if it doesn't bite you and bleed you down weak and tear you to pieces first!

    Like a pony. No, like a unicorn. Only the fucker keeps changing and even though changing its shoes isn't too hard well its hard but you are good and though DETERMINING THE SHOE TO PUT ON is what is so hard. How to put it on is a littler hard. Putting it on is easy. Sometimes.

    Thats is al.
     
  2. Doc Brown

    Doc Brown Don't make me make you my hobby

    Joined:
    Mar 31, 2006
    Messages:
    16,404
    Likes Received:
    0
    Location:
    Ohio
    "When the demon is at your door, in the morning it won't be there no more.
    Any major dude will tell you"

    Steely Dan
     
  3. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    1. Inadequate planning and design.

    2. Excessive drug use.

    That is all. ;)

    EDIT: Nice variation from the normal tech speak around here.
     
  4. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Debugging does not result from inadequate planning and design. Unless you code on sleeping pills. Its just a part of life: you will spend more time debugging than you do coding. If you don't, then you're just not detecting bugs very well.
     
    Last edited: Feb 14, 2007
  5. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    See now, you just don't get the whole planning thing. I'm not talking about a brainstorming session, I'm talking about a brainstorming session followed by feature specification, Visio dataflow and entity-relationship diagrams, mathematical proofs for each function algorithm, and version control to make sure every revision gets completely implemented all at once. Only then does it get turned into code.

    Most of my programs work as intended the first time I compile them; my most frequent error is forgetting to declare variables. I probably spend half as much time debugging as writing code or implementing planned revisions.
     
  6. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Thats because you don't write much code. Which is evident from your post. I'm intimately familiar with planning and design. Much more than you, having actually designed, planned and implemented actual software people actually use on a commercial basis. You will still spend more of your time debugging than coding, if you have ACTUAL customers who complain, nevermind market determined deadlines.

    Someday you will learn this, and your textbook spiels will carry some weight.
     
  7. Doc Brown

    Doc Brown Don't make me make you my hobby

    Joined:
    Mar 31, 2006
    Messages:
    16,404
    Likes Received:
    0
    Location:
    Ohio
    Now, that's the JollyOgre that I know. oops! I mean, Peyomp.
     
  8. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    If you have a rigorous set of requirements, you can UML and diagram your hearts' content. But that product won't ever serve any real market need if it interacts with actual users. Requirements inevitably shift, and when they do if you spend all your time diagramming then you aren't reacting very quickly. Thats not to say that documentation isn't important, but in the real world you will immediately realize that your diagrams get shredded. And thats not an excuse not to document, rather it is stating the truth of the matter: diagramming and planning do not save you from hacking into your pre-concieved notions of how a system works and changing fundamental assumptions about the system.

    When you do that, you will get bugs. If you plan long enough that you don't get bugs, your competition will own you. This is why you have QA. This is why you use Agile methods and self-test your own code.

    Inexperienced software engineers, and I know because I did this too, lament market pressures and think the 'proper' way to design software is to rigorously plan and document everything. Thats fine for your pet project, but don't expect to actually be able to compete if you do that.

    Bottom line: if you are building a system of any complexity and you turn out code that doesn't have bugs, you are doing something very, very wrong.

    If you work at NASA, then I take it all back. If you work just about anywhere else, then I call complete bullshit and Jihad on your post.

    Whats more, if you invest too much faith in your pretty little diagrams you draw up beforehand, you are GARUANTEED to never succeed on any complex project. Thats because 'you always throw one away.' its a basic tenet. You are MUCH better off at getting in there and creating a crude hack with no structure whatsoever, that accomplishes the simplest thing that could possibly work, and then designing something based on that experience, to replace it. If you DON'T do that... then the crap you design for so long will end up being the one you throw away. Lesson: You can't do macro design until you've covered the micro-realities of the implementation.

    That is in a textbook you must have skipped. Might want to go back and read the 'Mythical Man Month,' if you claim to be a "Software Engineer."
     
    Last edited: Feb 14, 2007
  9. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    I agree with everything you said. The projects I work on are projects that I'm contracted to perform, so time-to-market isn't really an issue. Even then, you're right that planning and design don't save me from having to change requirements and constraints as the concept of the project evolves, but it does save me an assload of re-coding time because it takes FAR less effort to take a pencil and eraser to a sketch than it does to rewrite live code.

    However, I draw a distinction between debugging and prototyping, which is what you're talking about in the last third of your manifesto. Debugging is when you fail to implement something correctly and it doesn't work. Prototyping is when you build components that you have no intention of using in the final version (to prevent messy code from getting included in the final product), to make sure that what you plan to do is possible.

    I agree that it's very hard to avoid prototyping, ESPECIALLY with regards to user interface design -- I do it myself on almost every project I work on. As for debugging, well, once the proof-of-concept is done, no more code gets written until the algorithms are vetted, so debugging an entire system takes maybe a day's work.

    Maybe what I say would make more sense to you if you'd sat next to me in class; what I'm talking about aren't pie-in-the-sky ideals, they're best-practices developed by the first generation of enterprise-system programmers, who first realized that it was possible to write software that no one person would ever completely understand. The courses I took were either taught by, or based on books written by, people who had to invent the whole software development lifecycle.

    I'd say about 2/3 of my CS/SE professors were either former or current employees of Bell Labs (my school was in NJ) and it was very easy to tell which discipline they fell into -- the CS profs used to bitch relentlessly about how the software engineers stripped all of the art and creativity out of their work, but that's what it takes to make good software.
     
    Last edited: Feb 14, 2007

Share This Page