Loading ...
Sorry, an error occurred while loading the content.

106723Re: [XP] How can you tell when your project is headed for disaster?

Expand Messages
  • Ron Jeffries
    May 3 7:42 PM
    • 0 Attachment
      On Monday, May 2, 2005, at 8:35:24 AM, James Carr wrote:

      >> 1. Why is management even aware of the architecture?
      >> 2. Is the architecture really better in OO rather than a mish mash
      >> of html and scriptlets?
      > The other firm (which has a self-proclaimed "web specialist" who only
      > knows the very basics of the language and the code he has written is
      > of the copy and paste variety) apparently desires to be able to modify
      > the code himself, and complained to the management that I made it too
      > complex that "no one can understand it". I feel the comment blocks
      > were adequate, but I did not know that a requirement (at the time) was
      > that the code needed to be modifiable by a third party.

      I'm not a big fan of comment blocks. The best way for anyone to
      maintain your code is to be involved in helping you implement it. I
      understand that that's not likely to happen.

      >> What if you learned to complete the most important 50 hours' worth
      >> in 50 hours?
      >>
      >> What if you even learned to predict ahead of time what you would
      >> have completed in 50 hours?
      >>
      >> That's only a week or two of work ... couldn't you get pretty good
      >> at predicting? Then you'd need to get good at completing what was
      >> predicted ... what would stand in the way of that?

      > I've gotten better at this now. But at the time, well, what can I say?
      > I was only one month out of college and had never even worked on a
      > project larger than a small CGI script (which usually takes an hour or
      > two). To me, I completely felt it was within my skills to complete the
      > system in 50 hours. If I was in the same shoes again, I probably
      > would have quoted 500 hours. ;)

      Live and learn ...

      >> > no upfront design or planning (basically just identified what was
      >> > needed and coded it),
      >>
      >> What went wrong due to this? Why is it a problem? When were the
      >> problems first identified? How much did they (or would they) cost to
      >> fix? Why was it that much? Have you read /Refactoring/? Are you
      >> doing anything like /Test Driven Development/?

      > As I stated earlier, I learned of refactoring, test driven
      > development, and all the goodies only recently. I have Refactoring and
      > PoEAA by Martin Fowler, XP explained by Beck, as well as many other
      > books (almost the complete set from the Addison Wesley Object
      > Technology Series). I guess the main problem is I wrote a rather large
      > software system with no formal control or unit tests of any kind. With
      > 15,000 lines of code written under a month with no overall plan or
      > guide, things are rather a bit... messy.

      Live and learn ...

      >> Your compensation isn't enough, unless you are in a federal prison.
      >> Or perhaps India or China or one of those places. Even then,
      >> actually.

      > Indeed. I feel this has been a major drag on my productivity. In the
      > beginning I was rather hard working, and put in alot of hours overtime
      > off the clock to make sure my projects were done the best to my
      > ability and was pretty focused. Unfortunately, I've recently became a
      > bit demotivated, especially when learning that one of the computer
      > repair technicians actually make $2 more than I. I often consider
      > going out on my own as proramming projects are done 100% by myself,
      > but lack the experience to really go out on a limb myself. How does
      > one keep demotivation from hampering work ability? I feel like it's a
      > catch-22... I'm demotivated because of my pay, yet this can also
      > become a cause and affect of not getting a raise. Bleh, just
      > stressful. ;)

      Yes ... I mean this in the kindest possible way: consider quitting.
      They might even hire you back at a higher rate. Also consider not
      quitting until you have a better job lined up, and work to do that.

      > Thanks for the comments Ron, very helpful. This project has been
      > stressful, and I have relieved some of that stress by refactoring the
      > code and making it more cleaner, but it bothers me that if I knew then
      > what I know now, I could have done a better job faster. I guess that's
      > the price you pay though. Rather than having a mentor show you how to
      > do things right, you instead learn to do things right by doing them
      > wrong and having a project blow up in your face. :)

      Live and learn. I really mean that. As Richard Gabriel puts it: "The
      work teaches us."

      Ron Jeffries
      www.XProgramming.com
      Curiosity is more powerful than skepticism.
    • Show all 30 messages in this topic