Replacing legacy systems (Part II)

In part one of this article I presented an approach to get started with replacing a legacy system.
By now we’ve picked one specific subsystem of a larger legacy application as the focus for the first implementation phase of the replacement system.

To make this a little easier to follow, let’s assume our end goal is to replace a big application that does all the internal management of a fictional slot-machine maker&distributor. Let’s call the company SlotManiacs and the application we are replacing is SlotManager3000.

In the first steps we already decided that the part of the application that we’d replace first is the UIs & logic that tell the workers which slot-machine they should currently assemble and gives them information on how to do it. That part is called Slotsembly.

Getting to know the playing field

OK, so we know what we are working on: modernizing the Slotsembly UI & logic. Next up we have to figure out how Slotsembly 2.0 should look and behave like. What I mean is we should ask the following questions:

• What are the business processes covered by the Slotsembly UI & logic?
• How does the workflow function in the application, how would users expect it to function?
• Is anything missing in the current version?
• Is anything in the current version that no longer makes sense?

Some basics about those business processes should already be known, since we had to have a rough idea about them when picking a subsystem to start with, but now we need to really understand it. In the best case we should be able to use the legacy application like one of the current users.

Walking a mile in their shoes

If you have the chance to, try this out: go to the workplace of a current user and try to do his work and ask lots of questions about his daily work. So we let Fabian the factory-worker lead us to his workplace. We’ll try to do his work for a few minutes and we’ll ask questions like:

• Do you always use this button to do X? E.g. when there are some buttons with strange labels.
• This behavior of the application seems strange, doesn’t this annoy you? Do you know if this is really necessary? E.g. when there are many popups/warnings that get clicked away, when you have to click often for things you need often etc.
• Why do you have to do X this way, can’t you do Y instead?
• Why are these steps separated in the application? E.g. when you have to click one button to get plans of some slot-machines, but another button to get plans for other types of slot-machines.
• Why are these steps fused together in the application? E.g. when opening some details-view to check something also triggers printing of that list.
• Is there a way for you to see X? E.g. when you do steps, that more experienced workers do fast, slowly because you don’t have the routine and you’d like to double-check something but there doesn’t seem to be a way.

Strange GUI is strange.

Make sure you document as much of this as you can, you’ll need it for further analysis and in discussions on how to design the new system.

Curiosities-collection and reasons behind

Areas of improvement which I’ve repeatedly seen in legacy-applications:

1. Cryptic behavior that only specialists (as in people that have used it long enough) can use.
2. Undocumented — and potentially unused — features.
3. LOTS of special-cases, typically mostly outdated.
4. Extreme focus on generic UI (nearly indistinguishable UIs that do vastly different things).
5. Extremely customized UIs (every text-field is placed pixel-perfect after the last letter of the label).

Not mentioning the typical technical shortcomings like insufficiently structured spaghetti-code, code-duplication, etc.

Points 1–3 typically originate from the people using the software and the people writing the software being very close. When Fabian the factory-worker is the best friend of Dean the developer and he visits him every Friday we can easily imagine the following scenario:

Fabian: “Hey Dean, it’s really annoying that we currently have to print the part-list by doing that 1 additional click after opening the detail-view, can you do something about that?”
Dean: “Sure thing, I’ll hack this in right now, starting Monday it’l get printed automatically every time you open the detail-list.”

The only problem is that this was 5 years ago. 4 Years ago, printing the list was no longer necessary because SlotManiacs factories got bigger/more monitors so that you can simply read this list from the screen all the time without printing. However it’s still printing it every time since the workers don’t care, nobody told Dean and even if so, he’s so busy keeping up with fixing all the other special-case logic he put in over the years that he wouldn’t have time to remove this code anyway.

A problem that is often overlooked here is that this direct interaction between users & developers may seem very efficient, it can degrade the applications usability if not managed correctly. All these special-functions that may seem handy are often surprising to first-time users and are only something you can take advantage of when you know about that behavior. Since for these quick-fixes there is typically no serious reflection happening about if and how this should be integrated in the software. For any sufficiently complex software and/or large organization, the first-time-user perspective should get special attention. If a UI & behavior isn’t self explanatory, you have to rely on training users, which is expensive and people tend to forget what they don’t need regularly. That means by including lots of those quick-fixes you optimize the application for an ever-shrinking minority in the company. In the worst case you end up with 1 person who can handle it perfectly and lots of people who barely understand how to do their most routine daily tasks with it.

Venn diagram time!

Points 4–5 (extremely generic or specific UIs) are typically found when Dean was maybe too keen on using all the UI-Designer tools he had available: “Oh, there is one more pixel between the last pixel of the label-text and where the textbox starts, I can save that.”.
In the other direction he could be either a hardcore purist that wants to do everything in a generic way and/or doesn’t understand the value of good UX: “You want a date-picker instead of a textfield? It’s basically the same thing, can’t your workers type in dates correctly?”.

Putting it all together

Now you should know:

• How workers use the application on a daily basis (required).
• What the actual goals of them using it are (required).
• What they would like to be able to do additionally (valuable).

What you should make sure you’ve also looked at the technical perspective:

• Rough overview of the inner-workings of the logic behind these UIs.
• Identified any special challenges from a technical perspective.
• Identified surprises like mismatches between what you saw/heard from the behavior from the users perspective and what the code tells you.
• Identified surprises in the shape of hidden things in the code which you neither saw nor heard of from the users. This could be things like calls to some other external system that nobody has mentioned yet or big blocks of code that seem to have no connection at all to the actual business processes.

Workshop time

When you have all of that and roughly made sense of that for yourself it’s time for some intense workshops with the key stakeholders again to find out:

• What should the new system actually offer? UI & what logic should be part of the system and which parts is just the way we work de jour, which the workers have to follow without guidance from the system.
• How drastic should the workflows be improved?
• Does that only concern the on-screen-workflow or has SlotManiacs considered optimizing/changing the factory worker’s workflows as well (now would be the time)?
• How much innovation/experimentation should be done from a technical/UX point of view? Should the new application be used as a marketing tool to attract new customers/workers: Look how shiny our internal tools are, we must be an awesome company! Or is it simply: re-implement this in a modern technology so there are more than 5 people within a 100km radius we could hire to support this & do it fast.

Define the extent of the re-implementation.

Be prepared to dig through all your collected documentation multiple times during that workshop because it’s likely that you’ll hit topics where when it comes to how something currently works, managers will say A, workers will say B and developers will say C.
To give an example from our fictional meeting in the SlotManiacs headquarters management said that workers are already using the new company tablets to look at machine-parts-lists when going to re-stock something from the main storage rooms. The workers say they’ve never heard of that and the developers/technicians say that this was never put into practice because it was discovered that the WiFi reception is so bad on those devices that they don’t work in the factory areas.
Typically the differences will be more nuanced, but you get the idea of what your job is here: get everyone involved to find and commit to a common way of how to think of and do things with Slotsembly 2.0.

Phew, that was a taxing process, I guess you expected that we’d get further in this second part. Planning the scope of such replacements is important because we don’t want to end up with a system that has to be rewritten from scratch again before we’re even done modernizing the next subsystems.

In Part III (stay tuned) we’ll take a look at what we should pay attention to when it comes to actually creating the new Slotsembly 2.0 application.

Have you been in similar projects? Did you have an elaborate hands-on requirements-collection phase with everyone involved as described here? Please share your experiences in the comments.