There Used to be a Mountain Here
Passersby today wouldn’t have known that there used to exist an obstacle that at the time could only be navigated around and not removed or plowed through.
If you haven’t spent time working closely with different software development teams you might not be familiar with the common practice of blaming the IT professional who currently no longer works with the team. In my experience I’ve seen this commonly occur within various Information Technology departments, but I'm sure that this is not a unique phenomenon only found in that space.
For a past project my team was tasked with improving legacy software. Users of this software were facing what’s typical in the case of old software that needs to be updated. The tech was no longer suitable for the job it was built to support. This occurs naturally. It’s often the case that the work we do evolves and expands with the passing of time. So while, this now legacy software, was properly built when it was considered new, the speed of business continues to march on. As an added pressure, business technology must to some extent keep up with the consumer market as well. We shouldn’t expect the professional we support to live with 1990 solutions while always connected and continuously improving touchscreen experiences are being had in the surrounding world.
Many of the users complained of being stuck in a user experience that did not properly support their workflows. For instance, information that they needed on one screen could only be obtained by navigating over to another. This called for more clicking than should be necessary. Some users solved this problem by copying information out of the system and onto Word documents so that they could keep what was important to them nearby.
Visibility to the underlying data was controlled through various front-end layers. The front-end application layer received was determined by the stakeholder’s department. In each department users were used to having their specific application that would give them a view of data from the same underlying source across the enterprise. In this way a user in one department would get mostly the same information organized in a different way. Because the user-interfaces (UI) used by each department differed there was a common assumption that each department was accessing a different data store. While at first this may not sound like an extreme disadvantage, this particular UI tailoring went too far in some cases by unnecessarily restricting what a user could see. In our process of improving upon this situation when we began to familiarize users with the full set of data unrestricted from the view they were accustomed to they were often surprised by how much useful information actually existed in the system. We were often met with statements like, “I wish I knew this was here before since this data would make my job so much easier.''
It’s all too easy to write-off the previous team as being full of unworthy hacks especially if your are new to the company and/or you do not have any relationship with any of the individuals from the previous development team. It’s also important not to overly villainize the previous team when approaching a situation like this. If you’re able to resist the urge to scrap all that was built before you may then find clues of lessons hidden within the previous design decisions and find yourself taking on less work as you discover what features can be reused.
In our own case what we found was that each front-end application had a common search tool that was problematic in that it did not allow for the type of flexibility that users across the enterprise needed. We discovered that what existed was a strong foundation of information that just needed to be opened up and allowed to be revealed in a more accessible way. The project was then able to take an unexpected turn away from the previous efforts of adding more features and instead enriching and extending the search feature that already existed.
By giving the previous work a measure of respect and peering into the decisions of the past you likely will discover long forgotten useful bits of functionality. More commonly you’ll find curious designs that only lead to more questions. But, it is these questions that when taken to the most knowledgeable users will open up even more understanding. Revealed to the team will be bits of the puzzle that might otherwise may never have been considered.
Avoiding thinking too much of yourself and of the current IT team will also help you to be less susceptible to the line of thought that the IT team has cornered the market on all of the right answers. This thinking can affect seasoned professionals as well as your brilliant young hotshot developer. Let’s get this straight, an IT professional may know the best technology to implement a wonderful solution, but he must still put on his listening ears.
Don’t be too hard on yourself if you’ve fallen into type of, “I’m the best”, thinking that slightly clouds your judgment of the past. Even I at one point used this line of reasoning, blaming a past developer’s code for slowing down my work’s progress. This sort of thinking gives us a measure of comfort in that we are able to deflect possible ill thoughts on our own work, but it isn’t productive. I think it also makes the one shelling out the blame in some way maintain that feeling of superiority to the person who is no longer there to defend themselves. But, when we do this what we often overlook the circumstances that existed at the time the previous developer was building the application or that portion of the software. We don’t know the constraints they faced. To illustrate, I recall driving down a particular road on my way home. Being that I was in a rush, as I drove down the road I was slightly annoyed with the seemingly needless twists, turns, and bends I was forced to navigate. I felt that these turns only served to add to the distance and increased the time it took for me to get home. Now couldn’t it be possible that at the time the road was built there was a small rocky hill or maybe even a pond that existed at that time that needed to be built around? But today that obstacle has been removed and is now long forgotten, replaced with a small shopping center. Passersby today wouldn’t have known that there used to exist an obstacle that at the time could only be navigated around and not removed or plowed through.
In a similar way we don’t know what technical limitations or time constraints a developer was dealing with. We also don’t know about the landscape of the job at the time. A different culture with its expectations could have called for them to build something in a way that in our current world would clearly be ill advised.
I’ve never skinned a cat, but I imagine that there’s more than one way to do it, since this is what the common saying tells us. Yes, it’s true that there are multiple paths to accomplish many things in life. Some of those paths while not inherently being wrong will feel wrong to us. And, that’s okay. It’s a good thing to have the freedom of choice. And, if you happen to have the time, budget, and authority to do so on a project please feel free to change the paths taken by those who came before you. As we do so let’s remember to not be so hard on our IT brethren and keep our mind open to the possibility that they may have already successfully invented the wheel and there’s no need to go back to the drawing board.
In our own projects after we’ve brought them to a successful conclusion and we’ve moved on to newer, bigger challenges, our own code will face the scrutiny of a new crop of developers and project managers. Hopefully you’ve fully documented your own solutions in a way that will reveal to this new team your own genius and show what you were up against. Maybe they’ll come to understand the compromises you made and start to see a bit of the vision that you didn’t yet get a chance to bring to reality. If they do maybe it will be for the best. If they don’t, then that’s okay too. Just keep in mind as you yourself enter new projects that the foundation may already have been properly built.