• MEH (unregistered)

    When the boss give the advice to get a new job, it's always a good advice.

  • LCrawford (unregistered)

    I've done several of this type of upgrade, but fortunately had the freedom to do planning, prep, testing before rollout. Such conversions are fairly straightforward when there is a minimal Access GUI to begin with. Much more complicated when there's no documentation, no one knows the rules to be applied, similar copies of the Access DB modified for different departments, tons of "queries" to be migrated to SQL Server stored procedures, tons of reports to be migrated to SSRS.

    Henrietta did the right thing by heading to a better job - no way would her situation be successful.

  • citron (unregistered)

    Why would it be strange to use SVN? Sounds like someone has bought into the cargo cult of that specific VC that all the cool kids seem to praise

  • (nodebb)

    And another clueless company doesn't "get" anything but keeps chugging along in ignorance

  • Robin (unregistered)

    Surprised (also part impressed and part horrified) that Hebrietta stayed a whole 8 months. But glad at least there was a happy ending for her!

  • Henrietta (unregistered)

    The article mentions only about half of the WTFs I sent in. And I sent in a selection of about 30% of the WTFs.

    Reading this site kept me sane.

  • my name is missing (unregistered)

    What amazes me more about the story is that the employer is still in business.

  • Duston (unregistered) in reply to my name is missing

    You're assuming it's a business...it could be a government agency whose "customers" are other government agencies.

  • Brian (unregistered) in reply to Duston

    And this is why it's so important to remember that job interviews go both ways. Had Henrietta asked the right questions during the interview, she wouldn't have wound up in this swamp in the first place.

    Based on my own experience (and this site), I've learned to make a point of asking about a potential employer's processes. I've worked in places where processes are too strict and too lax, sometimes both at the same time, so nowadays I like to make sure I have a good idea of what I'm getting into before I get into it.

  • Richard B (unregistered)

    After 3 decades I have concluded that there are many companies that survive in spite of their internal I.T., rather than because of it. It amazes me that they do, but somehow they keep going.

  • (nodebb) in reply to Richard B

    More to the point, there are many IT-oriented companies that survive in spite of their internal IT...

  • Argle (unregistered)

    Wow! I was cringing for the first few paragraphs. I thought this was about a current client and I forgot I submitted something. The client is great and a big manufacturing firm. But years ago, some employee got the bright idea to track things in Access. I'm sure it was a good idea at the time for the task at hand, but Access can't fulfill the needs of a multi-million dollar manufacturing firm. I'm slowly re-implementing and migrating their projects to something more capable.

  • Long Time Lurker (unregistered) in reply to citron

    @citron

    cargo cult of that specific VC that all the cool kids seem to praise LOL: just this morning I commented in an internal Pros/Cons discussion about migrating from SVN to GIT - I added the Pro: "All the cool kids use it".

  • DanK (unregistered) in reply to Long Time Lurker

    Migrating from Subversion to Git is usually a disaster. The two systems have very different philosophies and feature sets. If you were taking advantage of the more advanced features of Subversion, then you will have a horrible time with Git. Also, if you have a very large repo, it will likely need to be broken apart into smaller Git repos, but no one ever does this correctly initially, so expect another migration or two when the repos get huge.

  • (nodebb) in reply to citron

    Why would it be strange to use SVN? Sounds like someone has bought into the cargo cult of that specific VC that all the cool kids seem to praise

    It's centralised and distributed is always better than centralised under all circumstances, no exceptions. Also, it wasn't written by Linus Torvalds so it can't be as good as his version control system and you can't rhyme it with "shit".

    /sarcasm

    I half expected to come here and see loads of "svn is the real wtf ha ha" comments, so I was pleasantly surprised. The speed with which version control became a monoculture is quite painful to me. I also find it slightly ironic that one of the things that helped make git - a distributed version control system - ubiquitous was github whose business model is based on centralising your git repos.

  • Yikes (unregistered)

    The original developer got everything done their way and it was accepted despite not being to best practices, because it worked and everyone was satisfied, if not happy. So, as a PHB, how does one tell the difference between an avante garde approach and one that's building up technical debt?

  • (nodebb) in reply to Jeremy Pereira

    Doesn't the popularity of Github, the uber-centralized repo for the distributed version control, add a little to the general feeling that we live in a clown world?

  • D-Coder (unregistered)

    As the Extreme Programming people say, "Change your organization... or change your organization."

  • Guest (unregistered)
    Comment held for moderation.
  • kdgregory (unregistered) in reply to citron

    Why would it be strange to use SVN?

    I would expect Visual SourceSafe (especially since this seems like an older project).

  • Dave Aronson (github) in reply to Henrietta

    Bless you for having the whatevers to take them to task over it, and to leave.

  • (nodebb)

    At least they used Access for the database , not Excel.

  • Henrietta (unregistered) in reply to mike_james

    Given there are no foreign keys, and that basically every single UI needs to be exportable to excel... the app is basically an excel app with more than 1300 sheets. Yes, more than 1300 tables. And a single DBA who refuses to give information about the inner workings.

  • Henrietta (unregistered) in reply to citron

    As of right now, it takes 10+ minutes to check out the source code and create a feature branch. With other VCSs, it would only take seconds at most. Calculate the iteration speed yourself. (Also, why did nobody mention that QA is only testing the documentation, but not the features, as the documentation/specs is written only after the feature has been built?)

  • Henrietta (unregistered) in reply to Jeremy Pereira

    I'm not sure you get the idea of "decentralized". Yes, GitHub is popular. But "decentralized VCS" means I can create local commits without pushing them to become "public". I can re-arrange edits in my branch. I am able to clean up the commits so that fixes get incorporated in their matching base commits. I can discard all my own work if it turns out to be useless or wrong without bothering the VCS. "Decentralized" basically just means I can tidy up my own work before it gets merged into the main branch everyone's working on.

  • Henrietta (unregistered) in reply to DanK

    They literally abused SVN beyond a point you could call it abusive. I mean... they're managing trunk, that's... uhm... it's fact. Then they merge their changes in a random order to the "test" branch. There's a nightly job that compares trunk to test - and it's got exceptions implemented for "known differences". Go figure.

  • Henrietta (unregistered)

    As an addition to the calculation in the article which states "roughly 2 commits per dev per day, assuming 365 working days per year"... one commit is to the trunk, another one is the merge to the "test" branch (which basically is the production branch). The iteration speed is "one feature per dev per day". Except when you account for weekends and stuff - so, everything takes 1.5-2 days to get implemented, without reviews, without proper testing. And a 3 month feedback cycle from the "test" branch through QA, yet a release is happening every 2 weeks. Also, there are 5-10 parallel releases out there which need to be maintained. I guess because someone said "a release every 2 weeks is agile".

    What the article didn't mention is my boss's learning curve. I can tell from the coding conventions when he did learn something about the language. I know he doesn't do the straight-forward stuff because he "doesn't like it" and instead goes the scenic route.

    Evaluations of tools? Based on screenshots rather than reading about them or actually testing them. Recognition of mistakes? Nope. Complaining about the state of affairs while deepening the dependency on faulty procedures and tools? Yep.

    I should also mention that my boss is the lead developer for the whole company. Which naturally means his capabilities are superiour compared to everyone else. Go figure.

  • Anonymous (unregistered) in reply to Jeremy Pereira

    I'll do it: SVN is the real WTF. You only like it because you're nostalgic for the old days "when everything was simpler". But things always get more complicated as time goes on, and new tools were developed to deal with the added complexity and scale.

    During any job interview, one of the first questions you should ask is "What version control system do you use?". If they respond with SVN, then you can be confident that the company's IT department is three people locked in a closet, doing the same things written in this article.

  • (nodebb) in reply to Long Time Lurker
    Comment held for moderation.
  • (nodebb)
    Comment held for moderation.
  • (nodebb) in reply to Henrietta

    You should've started with "my boss is the lead developer". That's TRWTF and everything else makes sense in light of it.

  • Henrietta (unregistered) in reply to Anonymous

    I asked the question, and it was clear they're using SVN. But I didn't ask what tools they used on top of it, or what processes or rules were in place for its usage. The VCS itself doesn't really matter that much as long as you have the right tools and processes, i.e. tools and processes for reviews, tools and processes to manage development, tools and processes to manage releases, etc etc.. The WTF here isn't SVN per se, although SVN makes some stuff harder than it should be, and there were already better VCSs around when SVN was introduced. Reviews, feature branches and tooling on top only got introduced after I wrote down 2 pages of arguments for it in my free time.

    But I'm getting off track here. After seeing this and much, much more, I can assure you: The set of all sets of WTFs can contain itself as a set. Infinite Diversity in Infinite Combinations.

  • citron (unregistered) in reply to Henrietta

    A couple of counter-points to your multiple posts

    • Your company badly misused SVN, but does that mean that the tools itself is bad? Give me any tool and I can make it look like shit if I don't understand it. E.g. this of using only one branch isn't an SVN problem, it is an idiotic process problem
    • Local commits - have you even look at svn shelve?
    • "Taking 10 minutes to check out, others take seconds". First of all, how often do you check out the entire thing? If you need your local commits, use the shelves and switch, but of course if you only have trunk, then it is again a process problem, not an svn problem. Then, if it takes 10 minute to check out, you both have a bad repo content and probably you're on a network drive. But again, process problem, not svn problem

    I'm using both git and svn on a weekly basis, and guess what? Both are working version control systems that solve the task they are designed for. You use one different from the other, but trying to use svn the same way you use git or using git the same way you would use svn is going to cause you problems no matter who you are. So learn both tools properly instead of just doing the hallelujah git gospel.

    (again, I'm not saying I hate git or anything, I use both)

  • Henrietta (unregistered) in reply to citron

    All correct. I never said SVN itself is bad. But SVN easily allows for bad practices. Yes, obviously I don't like SVN, but I try to use it as best as I can. It is, after all, like you said, a process problem, not an SVN problem.

  • TS (unregistered) in reply to Duston

    No he isn't. RTFA.

  • (nodebb)

    @Henrietta - regarding "decentralized", you are indeed correct; but that does not mean it is always a good thing (though it quite often is). The number of times I have seen an organization lose information because individual developers did not commit all of their work in a step-by-step fashion to a persistent and discoverable [Source Control is not enough, it may give the what/\when/who, but never the full picture of why].

  • Dave (unregistered) in reply to Steve_The_Cynic
    Comment held for moderation.
  • farhankanju (unregistered)
    Comment held for moderation.
  • Rob (unregistered)
    Comment held for moderation.
  • Kamal Tiwari (unregistered)
    Comment held for moderation.

Leave a comment on “The Contract Access Upgrade”

Log In or post as a guest

Replying to comment #570695:

« Return to Article