1. 13

  2. 33

    We sometimes use a system we jokingly call “rant driven development” (RDD).

    There is a whiteboard. If some code or component held you back, or maybe even frustrated you, you stand up, walk to the whiteboard and either write the name down or make a tally mark. That way, we find out how much impact the dirty code really has. Some things are ugly, but work and do so for a long time.

    This raises awareness in management, because you can suddenly quantify that “component XYZ lead to development holdups 10 times”. Then we fix it.

    It came out of the idea that everyone is allowed to rant about any piece of the software - as long as they want to fix it themselves. Now we just count our rants.

    1. 2

      At a previous company we would do a “five whys” root cause on any problem we had and invest some time at each level proportional to how bad the problem as. The recurring underlying causes tended to get fixed, the process was easy and seemed to work quite well.

    2. 13

      We tried this where I work and didn’t get much value from it. We were either doing speculative refactoring that wasn’t necessarily as high value as we initially thought or we just didn’t do it at all because of other time pressures.

      We even had some refactorings that we didn’t end up merging because the scope of change was so huge we weren’t comfortable they were correct. We did eventually get those changes made, but in smaller steps over the course of a number of releases. You could say “write more/betters tests” and “be more confident” but the reality is smaller steps was a better way for us to maintain our comfort level and production stability.

      What we found did work was to take the time to refactoring as we did our usual tasks. This resulted in changes that addressed pain points as they were encountered and in a scope proportional to that pain.

      In the end I guess it’s our fault the dedicated refactoring time didn’t work out. However, I do think we converged on a practice that gives us more or less the same benefits.

      1. 4

        That was actually one of my concerns with the idea (the post is not mine, I just found it). It seems that this is a practice you might make temporary. Perhaps when it is apparent that you have a piece of code that your team is working on that has a lot of cruft to it.

        With regard to your mention of comfort with large-scale refactoring, I never feel comfortable with it unless there’s a pretty robust test suite or at least you have validation rings (I work on a service and we can test that sort of thing on <1% of machines).

      2. 4

        We already have “Refactor Wednesdays” at work. On Wed. morning we have our usual standup then go over what we’re going to re-factor that day. We’ve been doing this for about 3-4 months now and its been working out great. We’ve managed to optimize chunks of our application, take time to write better documentation and do a little blue-sky. The key is to keep the re-factor work to just that day so its manageable.

        1. 3

          I prefer to refactor code as/when you’re working on it. That way your refactoring is always provably valuable (because you know you’re working on that bit of code); that crufty old report that never changes can stay crufty as long as no-one wants to do anything about it, while your core code that everyone needs to understand stays very clean.

          Pure refactoring changes are hard to have confidence in, and hard to make the business case for. Remember agile: the goal isn’t good code, the goal is user-facing functionality.

          (much the same as what @gaustin said)

          1. 1

            Refactoring is waste. By definition it is re-doing work, but better. The ideal is obviously to always do things correctly. So strive to have zero refactoring.

            1. [Comment removed by author]

              1. 1

                I am guessing you confused my statement to mean refactoring is unessasary. Refactoring is a must in many situations. But I can not think of a situation where you refactor code that is perfect. In other words, we refactor to improve on some code. What I am saying is that we should strive towards perfection. And the better you get, the fewer times you need to refactor. The ideal being never having to refactor ever.

                In other words, refactoring is a sign of waste, of not doing something correctly the first time.

              2. 2

                I am not trolling. Let me describe what a better solution than “Refactor Fridays”. What you need to do is find out why you need to refactor and fix the source. Do you need to refactor because production issues put pressure on your schedule? Fix production first. Do you need to refactor because your estimates are off? Try to add buffer to future estimates.

                Find the root of why you have to refactor in the first place. Refactor Fridays will cause more problems. You will literally have people thinking “I will push this bad code to meet the deadline now and just fix it next friday”.