2

the back-end now has spend 9 months to be able to upload phonebooks .... and it still doesn't work :'D

How... It's not even a complex feature. Just parsing a simple xslx file. I don't know how incompetent a senior developer can be.

Comments
  • 5
    > Just parsing a simple xslx

    i've worked enough with excel-files (too much, tbh) so i can tell you: it's _never_ simple.

    if it were simple, csv would have sufficed. the fact that xlsx was chosen shows that there's at least some arcane magic inside. and/or that the person requesting this feature is an idiot. usually both.
  • 0
    @tosensei The only thing is that it does is:

    - read names

    - read primary number

    - read secondary number

    - check if it is valid phone number & check if there are duplicate records in the file & existing phonebook.

    I think that should be pretty simple to make it in a week or 2 max. but they over engineered it and it breaks constantly :D
  • 4
    @wojtek322 since it's excel, your phone number is now a date.
  • 1
    @electrineer But 9 months for that feature? That's way too long, no?
  • 0
    It might not be straight forward but it wouldn’t take 9 months. Unless it’s some obscure backend framework then it’s a week at most.
    From scratch in .net, a half decent dev could do that in a day.
  • 2
    @wojtek322 well, "valid phone number" is a problem that still hasn't been fully solved. it's not as bad as "valid email address", but it's full of pitfalls and edge cases.

    also: i am _very_ certain that excel has no scruples messing up phone numbers in numerous ways.

    and you don't even know what $PeopleWhoCreatedTheFile did to $TheFile
  • 1
    @DotGreen "in a day" - in theory, yes. but in my experience, it's not very pessimistic to multiply every estimate involving "excel" in any way by ten at least.
  • 0
    @tosensei the basic upload and checking can be done in a day. As long as all the rules around checking are defined and there’s nothing else additional that needs to happen other than just rejecting a badly formatted file. I’ve done similar.
    My guess is that it’s badly defined, the requirements are flaky and it’s a project that no one wants to touch. It would take a monumentally shit dev team to be incapable of coding that in 9 months.
  • 0
    @tosensei We are using the google/libphonenumbers library to validate it. This covers nearly all use cases.

    The excel is rejected if the spreadsheet format is slightly off. It is just 3 columns and we offer a template that the user has to use. I fail to see why it takes that long; we are not covering all use cases that can happen.
Add Comment