Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gav (2710)

gav
  (email not shown publicly)
http://www.estey.com/
AOL IM: flufflegavin (Add Buddy, Send Message)

Hacker in NYC.

Journal of gav (2710)

Wednesday October 29, 2003
10:08 AM

ETOOEARLY

[ #15448 ]

I got in at 6:11am to push the latest version of our e-commerce toolset to the live servers. It was dark and rainy outside. Everything worked which was nice.

When it comes to XP and future changes, I think the trick is to design something that will work "now", allow you to meet medium term goals, and just as importantly make sure that you won't design yourself into the corner in the long run.

A good example is what I did today. A couple of months ago we know we would probably need to support orders with items going to multiple addreses. We didn't worry about about it as we were concentrating on what we needed to implement to meet deadlines. This caused problems because we had to fiddle with both the code and the database because we had used the product id as keys, which isn't too helpful when you start wanting to be able to have the same product going to multiple people.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Databases make this trickier (but not impossible). The better designed (this means "refactor continuallly") and the more maintainable (again with the refactoring), the easier it tends to be to change.

    That doesn't often come from putting in code for future needs. I've found it comes more often from NOT putting in code for future needs.