It's no big deal



  • I just got out of a code reivew for one of my peers. The guy worked for two weeks on some new functionality and our team lead decided to do a random code review.

    Of the 13 features that were implemented, the team lead announced that 7 were unnecessary because they were removed from scope. To our quizical "When did that happen?", he responded "Oh, about three weeks ago", and he then insisted that since there was no new target date for the features, that the code be physically removed (as opposed to simply disabled by some switch, or at least commented out with some notes).

    Wait a minute, he knew before the work began that more than half of it would be unnecessary, and he didn't think it worth telling the developer who would be doing the work? "Well, it's no big deal, just delete it".

    And then they wonder why it takes us so long to do stuff.



  •  Okay, so that's three weeks to write feature X, then three more weeks to remove all traces of feature X...all billed at my usual rate.



  • Fortunately it's under version control so when he's asked to add the removed features back in, he can just revert.



    ...right?


  • 🚽 Regular

    While it's definitely a WTF he didn't tell anybody about this change, I don't necessarily agree that simply disabling the code is the best course of action either. It can often be better to just remove all of the unused code if you are not using it now and don't have a timetable as to when you're going to need it in the future. Otherwise you end up with either:

    a.) The code never gets used and future developers get confused as to why it's in the codebase

    b.) Sometime in the future, the feature is required again and a developer, not realizing this code is already in the codebase, duplicates the functionality, leading to even more confusion down the road.

    If you really need to find how you implemented it before, then assuming your company is not a total WTF and you have source control, you can always look at it there.



  • @snoofle said:

    Of the 13 features that were implemented, the team lead announced that 7 were unnecessary because they were removed from scope.
     

    If you're developing against a documented set of requirements and the requirements change but the document does not then this is a WTF that should result in the team lead (or whoever is in charge of this document) being disciplined.  How hard is it to write and maintain a functional requirements document?

    Out of interest, how big is the project you're working on (number of people, amount of time) and what sort of documentation do you generatefor a project of this size?



  • @RTapeLoadingError said:

    how big is the project you're working on (number of people, amount of time) and what sort of documentation do you generatefor a project of this size?

    10 developers, 2 business analysts, one team lead and one manager above the lead, a program management office and the representative from the business side.

    The BA's work for the business representative, and between the three of them, can't design a form with a single prompt and input field, but they, and ONLY they are allowed to write "specs". In practice, the specs are worthless (always omitting details like allowed input ranges, special cases, error checking, etc), and we are not allowed to build anything that's not in the specs, but the QA team is allowed to write bugs against specs that SHOULD have been written. Also, the "specs" have (some) details filled in while development is ongoing, but we're never told about it.

    We've taken to printing out the specs (with date and timestamp), and working from that. This way, when "bugs" are written against specs that weren't in existence when they were given to us, we have some recourse and can get them reclassified as enhancement requests. Ever since I started doing this, our bug count has been cut in half.

    Personally, I print out the specs up front, and again every now and then as I go along, just to protect myself. True, it's not really my place to do it (if I'm playing by their rules), but it's less painful for me to just have the new requirements magically be implemented by delivery time.

    We typically have version n, n+1 and n+2 in the pipeline all at once. In and of itself, not so bad, but (you'll love this), we also have n.01, n.02, n.03, n.10, n.11, n.12, n.13, and ditto for n+1 and n+2, in parallel, so we are effectively coding on code bases prior to ones that have already been given to QA. Then, when n.whatever goes to QA, and the code is merged forward, it essentially invalidates all the QA'ing done on n+1 and n+2, etc. Then, to save QA time, 3 levels of management review code diffs between testing so as to do "targeted testing". But you can't tell the folks who are scheduling these releases this is pointless, a huge waste of time and a gigantic risk because they don't want to hear it.

    Oh, and just for fun, no one person works exclusively on any particular section of the code; everybody works on everything, in parallel, so nobody is an expert on anything, the merges are a joy, and invariably, different coding styles result in lots of rewriting by the team lead, because it has to look like his code.

    Then again, I'm being paid by the hour.

     



  • @snoofle said:

    In practice, the specs are worthless (always omitting details like allowed input ranges, special cases, error checking, etc), and we are not allowed to build anything that's not in the specs, but the QA team is allowed to write bugs against specs that SHOULD have been written. Also, the "specs" have (some) details filled in while development is ongoing, but we're never told about it.
     

    I would always like to see specs agreed and signed off before work starts.  If the business don't know with some degree of clarity what they want then I don't believe development should start.  I'd say it's always worth spending the necessary time in the requirements gathering and documenting phase.  (If people think it takes a lot of time to get the requirements right before development starts they should see how long it takes once it's half way through...) 

    After the spec is signed off any variances to the spec can be recorded as change requests.  Adding detail/clarification is fine, but would a notification email to the concerned parties be so hard to arrange?

     

    @snoofle said:

    Personally, I print out the specs up front, and again every now and then as I go along, just to protect myself. True, it's not really my place to do it (if I'm playing by their rules), but it's less painful for me to just have the new requirements magically be implemented by delivery time.

    That's all you can do really.

     

    @snoofle said:

    <Parallel coding mayhem>

    I'm not really a developer so I won't comment on this!

     



  • @RTapeLoadingError said:

    I would always like to see specs agreed and signed off before work starts.
     

    Me too. But rarely does that happen.



  • @snoofle said:

    Then, to save QA time, 3 levels of management review code diffs
    But aren't those guys non-developers? What are they doing, review code diffs? @snoofle said:
    Oh, and just for fun, no one person works exclusively on any particular section of the code; everybody works on everything, in parallel, so nobody is an expert on anything
    That shouldn't be a problem out of itself, unless the system is a complex mess that can't be understood by any single person (which I guess it is).@snoofle said:
    the merges are a joy
    Well, I can imagine. Do you guys coordinate among yourselves who's altering each portion of code at a time? (I don't see management doing that)@snoofle said:
    and invariably, different coding styles result in lots of rewriting by the team lead, because it has to look like his code.
    How competent is the team lead? Maybe it's for the better that he's not trying to do anything "productive". Unless he's coding style completely sucks and/or he is introducing bugs while rewriting.



  • I wonder what the odds would that the stakeholders, when informed that the seven requested features that had been dropped from scope had been implemented anyway and were ready to test, would demand that the features be added back into scope for the release.  Pretty good, I'd imagine.

    A classic case of middlemen prioritizing what's easiest for themselves over what's best for the client.

     



  • @Zemm said:

    @RTapeLoadingError said:

    I would always like to see specs agreed and signed off before work starts.
     

    Me too. But rarely does that happen.

    And even when it does, it just means that the supposedly-settled spec gets a whole bunch of changes piled on it during development.

     



  • @DaveK said:

    @Zemm said:

    @RTapeLoadingError said:

    I would always like to see specs agreed and signed off before work starts.
     

    Me too. But rarely does that happen.

    And even when it does, it just means that the supposedly-settled spec gets a whole bunch of changes piled on it during development.

     

    That's par for the course but you just write them up as change requests and deal with them after the initial development is complete.

    Maybe I've been spoilt but where I work we don't do anything unless we have signed off functional requirements.  What are you coding against if you don't have a document saying what you are trying to do? 



  • @RTapeLoadingError said:

    @DaveK said:

    @Zemm said:

    @RTapeLoadingError said:

    I would always like to see specs agreed and signed off before work starts.
     

    Me too. But rarely does that happen.

    And even when it does, it just means that the supposedly-settled spec gets a whole bunch of changes piled on it during development.

     

    That's par for the course but you just write them up as change requests and deal with them after the initial development is complete.

    Maybe I've been spoilt but where I work we don't do anything unless we have signed off functional requirements.  What are you coding against if you don't have a document saying what you are trying to do? 

    Half made up, half from incomplete verbal requirements. Then development takes twice as long because it wasn't what the client expected (it was what they asked for) or they chAnged their mind and since there was not much written down the requirement was vague. Things are better for my work now - better manager came along and nutted thugs down more compared to when I first started there.



  • @RTapeLoadingError said:

    Maybe I've been spoilt but where I work we don't do anything unless we have signed off functional requirements.  What are you coding against if you don't have a document saying what you are trying to do? 

    At my previous job, we had actual written requirements. At the time, it being my first job out of college, I kind of viewed them as formalities for business red tape. At my current job, we have no requirements. What we have is a behemoth VB.NET/WinForms (and some VB.NET/ASP.NET websites) written by an Indian contractor company, constructed from informal conversations and emails between various individuals. We're rebuilding it as a C#/WPF app (while the legacy version is still being actively developed), so most of our requirements have basically been "Make it work like the legacy. Oh, but can you make it do this? Such and such is always causing huge delays for the users, can we fix that?" Nothing written down, of course.

    This recently burned me when I had to update one of the websites (and make some DB changes to accommodate it), and right when I had finished, the project managers decide that it's too close to a live release and they won't be able to QA it (what, an actual QA department? Who needs that, we'll just have a few business users poke at it), so I'm to revert all my changes. Luckily, we do have a source control system, but it's still a pain in the ass because I have to be sure not to mess with the code of the Indian team, whose work overlaps mine, and who are ~9 hours off from us.

    What was the question again?



  • @superjer said:

    Fortunately it's under version control so when he's asked to add the removed features back in, he can just revert.



    ...right?
    This reminds of the configuration management system we had to use at my former workplace. It was Serena Dimensions, and it made the life of us developers pure hell, mostly because it was configured to use pessimistic locking (check out a file before you start changing it, linking to precisely the change request you were going to implement, do your change, and then check in when done, both processes took 30 seconds for every file) instead of the optimistic locking approach we were used from CVS.

    When I challenged to QA manager who loved Dimensions so much about this, he explained to me that the big advantage of Dimensions was the ability to build releases consisting of exactly the features and change requests required, or more precisely, that individual features could be left out of a build at will. At first, I was simply shocked. Then I tried to tell him that that would never work out.



  • @TheRider said:

    @superjer said:
    Fortunately it's under version control so when he's asked to add the removed features back in, he can just revert.

    ...right?
    This reminds of the configuration management system we had to use at my former workplace. It was Serena Dimensions, and it made the life of us developers pure hell, mostly because it was configured to use pessimistic locking (check out a file before you start changing it, linking to precisely the change request you were going to implement, do your change, and then check in when done, both processes took 30 seconds for every file) instead of the optimistic locking approach we were used from CVS. When I challenged to QA manager who loved Dimensions so much about this, he explained to me that the big advantage of Dimensions was the ability to build releases consisting of exactly the features and change requests required, or more precisely, that individual features could be left out of a build at will. At first, I was simply shocked. Then I tried to tell him that that would never work out.

     Although it is not easy to set it up, a development environment can be setup so that "individual features could be left out of a build at will". The real question will be "Is the cost of setting up, maintaining, and enforcing such an environment provide a positive ROI?".



  •  Maybe he wants it set up so that "individuals could be left out of a build at will".


Log in to reply