Three Things We Do In IT That Don't Match Reality

"Life imitates art far more than art imitates life... results not merely from life's imitative instinct, but from the fact that the self-conscious aim of life is to find expression, and that art offers it certain beautiful forms through which it may realize that energy" - Oscar Wilde

This notion is often concluded that events in the real world are actually inspired by some form a creativity. This is the reverse of how art is often interpreted. In other words, perhaps that song you listen to was based upon creativity and not reality.

While this notion is certainly something to think about — the focus of my article is actually a little different.

Instead, I am going to focus on three situations I have encountered as an Information Technology (IT) professional that do not match the real-world approach we would use in similar circumstances.

You may also like: What Is the Scrum Methodology? All the Basics You Must Know.

Multiple Trips To The Hardware Store

Assume there is a need to perform a series of computations for a provided set of parameters. The service handling the request will have access to all the necessary data and required attributes in order to reach a conclusion that can be validated using a unit test strategy. Pretty standard request, right?

A common approach is to start with some base entity being requested and perform the necessary query to return some data for processing. As needed, additional data can be fetched to assist with the effort in providing the expected result set.

While this approach works great and is very logical to follow, the same approach can introduce performance and scalability concerns.

A real-life comparison would be to make multiple trips to the hardware store, every time you needed something for the tree house you are building for your children. Imagine starting the project and heading off to pick up some wood for the project, only to return home to realize you also need a box of wood screws as well. Then just as you are ready to affix that first board, you need to make another trip to the hardware store in order to pick out hardware to utilize the boards and screws.

To avoid the "several trips to the hardware store" approach, consider looking at the entire domain of the ask; then, change the design of the service to be performant and optimized. One example would be to restructure the queries in the process to return all the data at once — grouping/mapping the results as needed.

The time saved from performing one query instead of several isolated queries will not only lead to improved performance, it will make the DBA group happy as well.

Believe Me, the Other Light Is Red

While working on a project when Maven concepts were still relatively new, the team was using Snapshots and Versions for a shared library that was utilized across different services. The idea was great, as it avoided having duplicate code within each of the individual services. Don't repeat yourself (DRY), right?

The plan was to create a new SNAPSHOT before development of the shared library would commence. When the new shared code had been fully tested and validated, the SNAPSHOT label would disappear and a new unchangeable version would be deployed and referenced by the production service instances. The process became automated and was validated.

The challenge was the management tier wanted to revalidate that the shared library was still okay, when the automated process simply removed the text "SNAPSHOT" from the pom.xml of the shared library.

A real-life comparison here is to consider the case where you are driving your vehicle and you notice there is a traffic light before you. The light is currently red, so you decide to start slowing down in order to avoid a sudden stop. While watching the light you noticed it changes from red to green.

As drivers, it is not a common pattern to stop your vehicle, get out of the driver's seat, and walk around to validate the traffic in the opposing directions has a red light. Instead, we make the assumption that the proven process is doing its job and making sure opposing traffic directions do not have the green light at the same time.

In this case, after the automation code has been validated, there should not be a need to retest a shared library version where the only change is to make the version final.

Lane Ends, Please Merge to the Right

I written about how much I really enjoy the IntelliJ IDEA product for my daily coding efforts. I am convinced that the cost to license the Ultimate edition pays for itself after one or two pull requests or code reviews.

As a developer, I appreciate not only the forward-thinking of the product (e.g. to suggest alternatives to code patterns as they are automatically analyzed), but how the product also indicates the case when a function or method is deprecated. Aside from running into seeing deprecated methods in use during pull requests, I have seen them pop into my code stream, when referencing something I encountered online while resolution a situation for one of my customers.

At the time, the referenced solution implemented methods that were not deprecated. But now they are deprecated.

A real-life example here is a scenario when you see road construction signs that indicate your lane is ending and a merge to another lane is advised. During off hours, this is likely not a big issue. However, when traveling during peak commute times, the reduction in lanes often leads to slowed or stopped traffic. In this case, it is like you are a driver who decides not to merge, but drives around the cones in order to press your luck with the closed roadway ahead. For now, your plan is working... but you are not certain of your long-term supportability.

When I face deprecated methods, I use this as a learning opportunity to understand why the item is deprecated and seek to understand the recommended manner to solve the problem. More often than not, the recommended approach provides a far better solution than to use the deprecated option. The last thing I want to do is run out of roadway on my application lane.

Bonus Example: Thanks, But no Thanks

Have you ever encountered a situation where a team member was added to the team, but they don't have an understanding of a technology or framework being used on the project? Normally, the individual will spend some time getting up to speed with the unfamiliar concepts so that they can be a valued member of the team.

I ran into a situation where the technology in question was the leading technology option in it's given space. In fact, one could say it was the de-facto standard. Yet, the team member added to the team had really no understanding of the technology, due to supporting older code bases. On multiple occasions the individual recruited other team members to do work related to the technology — citing being "challenged" with the technology.

The bonus real-life example here can be compared to receiving a free car once a driver's license is obtained. When getting in the car, the new driver notices the vehicle has a manual transmission instead of an automatic transmission. Something the driver does not currently know how to drive.

In this example, the receiver of the free car decides to not accept the gift and makes the decision to not drive at all... since there is no desire to learn the automotive technology that is foreign to them.

Conclusion

The idea behind this article has been on my backlog for quite a while, as I tried to determine the best real-life examples to show how crazy our approach to solving problems can be, if we fail to take a step back and see the big picture.

Going forward, consider asking yourself these simple questions:

• Are you making one or multiple trips to the hardware store?

• Are you revalidating a proven process?

• Are you blindly hoping the closed lane you are using will reach your destination?

• Bonus: are you putting more burden on your coworkers due to an inability to learn something new?

Have a really great day!

Further Reading

• The Single Most Important Thing in Agile.
• 10 Myths About Agile Software Development Companies, Busted.
• Agile Patterns.