need help directing a co-worker

[xSauronx]

So i am not a programmer. I may be incorrect in my assumption or understanding of what i am going to ask 🙂

I work with someone who does some programming.

I will spare some details, but we have a legacy app the programmer will update this year. It was written for XP, probably in vb6. We use windows 7 and windows 8 now.

The program requires the date and time formats to be changed from the default m/d/yyyy to mm/dd/yy or some such. Only on the 15 PCs that use the application.

I think it makes sense to update the app to use the default system time.
The programmer thinks microsoft handles the date and time stupidly and refuses to learn how to make anything work with the default settings. Right now we just change that setting on the PCs using the app.

it seems reasonable to me to update the app to work like every other app. am i wrong? is it likely to be a huge headache?
or is this something actually easy to change? or at least more reasonable to be handled as an update to the program?

it is not critical to handle. but during setup, it is easy to forget to do, and we have since discovered a couple of other old programs that need updating need the time format changed, and i also think *those* should be updated to use the default system settings as well.

thanks for any input

 

[Ken g6]

The programmer should be willing to use whatever format you want. You should ask for a level-of-effort estimate. That should give you a better idea of how reasonable it is to "update the app to work like every other app".

 

[dave_the_nerd]

Ideally, everything is consistent.

Practically speaking, is the date format change in the project requirements? He might just be resisting because you're asking him to do a bunch of extra work.

 

[Ken g6]

I'll also add that date/time parsers that require a specific format are a bit of a pet peeve of mine. Even since I saw Chronic, a Ruby extension, I've wished there was a similar module for all languages, and that everybody used it.

 

[dave_the_nerd]

I'll also add that date/time parsers that require a specific format are a bit of a pet peeve of mine. Even since I saw Chronic, a Ruby extension, I've wished there was a similar module for all languages, and that everybody used it.

I usually find myself defaulting back to the UNIX epoch as my least common denominator if I need to get two things talking about dates, but Windows might not let you do that. (?)

 

[xSauronx]

Ideally, everything is consistent.

Practically speaking, is the date format change in the project requirements? He might just be resisting because you're asking him to do a bunch of extra work.

she doesnt update the program until there is a large log of changes requested because its a lot of work. there are several user changes being requested now, and i have a few install changes so she said she will be updating in the next couple of months.

she is slow to change her ways on sort of anything, so since she already decided its too much work and she cant do it, she wont look into it again. well, not because i asked, anyway. i dont want to get the bosses involved, honestly. is it really is a giant pain to write a program to use the windows default date/time format though? that just seems like you could call the date pretty easily and not have to worry, but again, im not a programmer, so its why i asked 🙂

I'll also add that date/time parsers that require a specific format are a bit of a pet peeve of mine. Even since I saw Chronic, a Ruby extension, I've wished there was a similar module for all languages, and that everybody used it.

but that sort of makes it sound like it could be a giant pain. which bites.

 

[KB]

The program requires the date and time formats to be changed from the default m/d/yyyy to mm/dd/yy or some such. Only on the 15 PCs that use the application.

This should have been a requirement when the app was first written. Most changes are easier to implement from the beginning. It's like the difference between adding windows to a house after its finished or leaving window openings while it's being built.

The task of using default date formats is rather easy and straight forward. If the code was built well, such a change would take just a few lines of code and a few seconds to make, but if the code was poorly written, then changing this could be a lot of work. Maybe 2 code changes per date per module.

 

[xSauronx]

The program requires the date and time formats to be changed from the default m/d/yyyy to mm/dd/yy or some such. Only on the 15 PCs that use the application.

This should have been a requirement when the app was first written. Most changes are easier to implement from the beginning. It's like the difference between adding windows to a house after its finished or leaving window openings while it's being built.

The task of using default date formats is rather easy and straight forward. If the code was built well, such a change would take just a few lines of code and a few seconds to make, but if the code was poorly written, then changing this could be a lot of work. Maybe 2 code changes per date per module.

I agree. but it is an old app and we have been able to take over the code, from what i understand. or maybe they had someone write it years ago and our company owning the source was the deal. *shrug*

I'm going to try and talk her into letting the new guy help update it. He is a recent grad and might be interesting in working on a critical app and getting some recognition if she will let him pitch in. /fingers crossed

i appreciate the insights though 🙂

 

[BoberFett]

I'm a bit confused on what the requirement is. Is the date stored in a text format? I would hope it's being stored in a standard date format. If it is, then it should be a simple matter of changing the mask to whatever you want to be when you display it. If it's stored as text, then that's more of a challenge. It's also crap code that probably has other problems as well, and you're better off leaving well enough alone. You don't want to change a date format and have that break a bunch of code that's expecting specific text formatted dates.

 

[Cogman]

Just want to echo what the others are saying. The difficulty of the task is going to depend on how well the code is designed. In the worst case, it will be the programmer digging through all of the code looking for places where dates are (or aren't!) formated and updating them all. In the best case, it is a minor change.

Now, I'm biased, but the fact that it is a vb6 app is a strong indicator in my book that the app is poorly designed. This may not be the case, but it probably is.

 

[Carson Dyle]

I'm a bit confused on what the requirement is.

Same here. Are we talking only about how dates are displayed, or how they're stored?

And are you only talking about the requirement to change a setting during installation? For only fifteen PCs in company, why even bother? Especially if this is only a display format setting - if someone does forget to change it at installation time, you can change it later and no harm is done.

 

[sm625]

I'm assuming "installation" for this program is simply copying the .exe file rather than running an installer. In that case you can just make a batch file which sets the default time/date format and then copies the file. That also assumes this format change can be done from command line.

 

[xSauronx]

I'm assuming "installation" for this program is simply copying the .exe file rather than running an installer. In that case you can just make a batch file which sets the default time/date format and then copies the file. That also assumes this format change can be done from command line.

lots of assuming there. its not copying an exe, its running an installer that is probably from the win2k or xp era. the whole program should be updated to a windows 7 level but im not sure if i will ever see it happen.

Same here. Are we talking only about how dates are displayed, or how they're stored?

And are you only talking about the requirement to change a setting during installation? For only fifteen PCs in company, why even bother? Especially if this is only a display format setting - if someone does forget to change it at installation time, you can change it later and no harm is done.

it is how dates are stored. the computers that use this write data to a couple of databases, but it is the program that requires the dates to be readable in a certain way [from what i understand].

why bother? if someone is updating the app, why not just...update that, too, and make it work like every other app? its not a big deal to have it done, more of a "while you are at it."

But i am getting the impression here that it could be a lot of work, so that's fine, it is not a requirement or hard to handle, but it was worth asking. The in house dev is at a point of refusing to expand her knowledge on a lot of things for whatever reason, and sometimes i go expand my knowledge of things she works on to make something easier to handle.

If I do the legwork to make the implementation easier, she will work with me better. I don't like it being that way, but if it get's something useful done then... sometimes i bother.

 

[MrPickins]

why bother? if someone is updating the app, why not just...update that, too, and make it work like every other app? its not a big deal to have it done, more of a "while you are at it."

Updating legacy applications is almost never this easy. Changes need to be researched, designed and implemented methodically.

Even "minor" changes can be a can of worms.

 

[matricks]

why bother? if someone is updating the app, why not just...update that, too, and make it work like every other app? its not a big deal to have it done, more of a "while you are at it."

Updating a self-written app isn't something you do while you're at it. It's not about opening the software project in an IDE and checking off a hundred Windows Update-ish checkboxes, it's writing (probably significant) amounts of code to re-implement the functionality that's already there, just in a better way. Which certainly can be a good idea, but it's something you do when it actually needs to be done, because it is a significant amount of work. If it needs to be done now, figure out the requirements and have at it. But it doesn't happen on its own.

 

[mrjminer]

Accepting different date/time standards and converting them can be a problem for an application that already exists. Like, a massive amount of time kind of problem for a not much reward kind of problem. It's not something that would be super difficult if you knew that's what you wanted to do when you just start coding the program, but to change it after the fact is something where the return definitely will not be worth the time invested on some custom legacy application.

Of course, maybe it's super easy in the application you guys have now if you aren't using dates in a lot of places, but, generally speaking, not going to work out well.