Navigate / search

Legacy Code Katas

I like Kata’s, I’ve get a lot out of them, but if I’m truly honest, they don’t really address one area of programming where I think I need practice, and that is in working with Legacy Code. In pondering this problem I came to the conclusion that I need a way of doing deliberate practice for legacy code work, and some variation of the Kata idea seems like it might work.

I should point out that this isn’t an original idea, there’s at least one StackOverflow question from 2009 asking about this exact topic. Nothing seems to have come out of it however. Perhaps there’s a reason for that.

There are practical reasons why Legacy Code Kata’s are difficult. I’m not going to go into them all now, but for starters a traditional Kata can be stated with a few sentences of English text, and the programmer can implement it in any language, with any tool chain.

Legacy Kata’s will likely require us to provide starting code, which immediately makes them harder to create and limits their audience. Special variations would need to be created for each language for example. Might there be a way of describing the problem to be solved in a language independent way? So that the solver creates the starting code? I don’t know.

To get the ball rolling, or illustrate the idea, I’m including here some code, that could form the basis of an exercise/kata. Along with some tasks that should be accomplished with the code. If you have any feedback as to whether there is any potential here for any kind of useful learning/practice then let me know your thoughts.

Legacy Code Kata

    public class SecurityManager
    {
        public static void CreateUser()
        {
            Console.WriteLine("Enter a username");
            var username = Console.ReadLine();
            Console.WriteLine("Enter your full name");
            var fullName = Console.ReadLine();
            Console.WriteLine("Enter your password");
            var password = Console.ReadLine();
            Console.WriteLine("Re-enter your password");
            var confirmPassword = Console.ReadLine();

            if (password != confirmPassword)
            {
                Console.WriteLine("The passwords don't match");
                return;
            }

            if (password.Length < 8)
            {
                Console.WriteLine("Password must be at least 8 characters in length");
                return;
            }

            // Encrypt the password (just reverse it, should be secure)
            char[] array = password.ToCharArray();
            Array.Reverse(array);

            Console.Write(String.Format("Saving Details for User ({0}, {1}, {2})\n",
                username,
                fullName,
                new string(array)));
        }
    }

Given the code above, do the following:

  1. Break the dependency on the Console
  2. Get the password comparison feature under test
  3. Get the password validation feature under test
  4. Add a feature to allow different encryption algorithms to be used

Thoughts? Comments? Would a collection of exercises like this be a useful resource, or a waste of time?

Comments

James World
Reply

Sounds like a good idea to me. Michael Feather’s book is a good source of sample evil!

Muigai Mwaura (@MuigaiMwaura)
Reply

Check the the length of the user name and full name. The user could just hit enter on both prompts and return the empty string..

Richard
Reply

Hi, Thanks for the comment. I just wanted to clarify, the point here isn’t to put this code up for review looking to improve it. It’s deliberately problematic code for the purposes of the exercise.

David Conlin
Reply

We used this kata in our weekly technical exercise session with about ten pairs of devs, most of whom were really positive about it.

The skills and techniques it uses are really relevant to normal everyday life for almost all developers – much more so than the standard “write a system which…” format of most exercises, and it sparked some really good conversations about the right and wrong way to do some of these things, which we do every day/

The one suggestion that a few people had was that, because it’s relatively compact and simple code, it doesn’t quite reproduce the fear of editing real legacy code. This is a really good basic kata, but maybe an intermediate/advanced one might include a little bit more code or maybe come with a restriction like “because you are terrified of class x, the signature of method y must remain unchanged”.

Either way, more like this would find a very appreciative audience!

Richard
Reply

Hi David,

Delighted to hear you got something out of this. I just put this example up because I happened to have some similar code handy from another exercise and I tweaked it a little.

Your comment about more complicated examples is interesting. I have actually been looking more at doing more specific examples, e.g. code that would specifically demonstrate some of the patterns in the Michael Feathers book, like Sprout Method, Sprout Class etc.

I might try and create some more “realistic” but possibly less focused exercises with more complex code.

I originally thought this might work like a Kata where a developer would work through the same exercise repeatedly. It sounds like you used it as a once off task which prompted discussion. That would also be very interesting, I can see how discussions on how to proceed could be interesting.

E.g. To what extent should you attempt to get the whole thing under test before making significant changes, or do you have to make changes in order to get anything under test.

Leave a comment

name*

email* (not published)

website