IT work is never truly black and white. There are thousands of possibilities, and thousands of ways that those possibilities don’t turn out the way you had expected. It’s easy to walk into a new job, look at the environment, and wonder “What were they thinking?”. But it’s another thing to be in the moment and have to make a split-second decision: Do it quick, or do it the right way?
I am often an advocate of taking the time to do things the right way the first time. It’s extremely time-consuming to go back and fix things a year or two later only because something else requires it. Every time a problem comes up, I race through several different variations of a solution. Usually, there is a “No way/Only if we absolutely must” idea, a “This would work, but not be ideal” idea, and a “perfect world” solution. Often the perfect world idea will take much more time and effort than we currently have to complete – which means that we are too likely to go with the non-ideal solution.
At some level, you have to be able to accept that not everything can be done perfectly. We don’t live in a perfect world with infinite time and resources. Corners have to be cut in some way or another, but it’s up to us to determine where and how. That being said, we shouldn’t blindly accept imperfection either. Use the multiple options to fight for a solution that edges toward the perfect world idea. Maybe we accept the temporary solution, only as long as we are allocated time within the near future to make it more ideal. Or it’s possible that we accept the temporary solution, but with some mitigating factors.
For example, maybe we are told that there is a new product being installed on our network. Servers are already being built and the application will need to be running quickly. However, the application serves a very different purpose than most of the remaining network and it introduces new risks. In the ideal situation, we might create an entirely new virtual network segment to isolate this type of traffic. However, maybe because of the time crunch, we only have enough time to create a new VLAN and put the application behind it’s own SVI. Not really a true separation, but it’s a start.
In this scenario, we could propose two better solutions. First, we may want to suggest that we create the new VLAN/SVI to get the application running immediately, but we allocate time over the next week or two to create VRFs/firewall contexts/etc and completely isolate the application. This would allow us to meet the requirement in the meantime, but work toward our ideal long-term state. Our other solution could be to just extend the VLAN up to a firewall and apply basic filtering – not ideal but this still gets us to a much better state than just allowing the application into our existing environment.
When you look back, it’s always easier to see how things could have been done better. Usually you just have to work with the resources you were given at the time, which is often less than perfect. However, we shouldn’t settle on just ‘getting it done’ or insist that it must be perfect every time – but instead push for a middle-ground. Whenever you see yourself in a situation like this, take a moment and outline a few options. Talk to your direct supervisor about them – in most cases they will listen. If we can provide an option that is better than “good enough” but also doesn’t require a significant additional time investment, then they are much more likely to give in. Just be sure to stress the potential risks of taking the easy way out.