Parenting and IT: More Lessons Learned

As I noted in my "What I Learned About IT From Rocking My Son" article, my wife Nicole is recovering from major shoulder surgery, so my 1:1 time has dramatically increased with our toddler, who goes by the nickname Finn.

Like many toddlers, Finn adores nursery rhymes. We read them in books, watch videos about them, and play with toys that integrate them into the entertainment experience. The perfect trifecta!

And as I'm sure you can imagine, "London Bridge is Falling Down" is a perennial favorite.

While reciting it the other day for what must have been the bajilionth time, I couldn't help but think about how this well-known lyric also relates to the world of IT. (What can I say? I'm clearly a multitasker.)

What follows are my musings on what we seasoned IT folk can infer from the classic rhyme.

Probably not Agile

It seems that the project team opted to build out the entire bridge first, then wait to see what happened with their completed design. Does the term "waterfall model" mean anything to anyone?

Thinking about it, doesn't it seem absurd for a team to endure the long and tedious process of building something without knowing it will work until the design is 100 percent complete? In today's development world, this would be the same as telling an application's sponsor, "We think we understand everything you want. Now, give us about two years, and we will be back with a product that meets all of your needs." Years ago, that approach was the most common development approach. 

Just like the bridge that failed to hold up to London's weather patterns and undercurrent of water, that application (if it actually was delivered in two years’ time) did not match the current needs of the business, since two years in the past can be a lifetime in functionality and requirements.

Didn't recognize a learned lesson

The original wood design didn't work, but was attempted again with a repeat failure.

In fact, some video versions of the song which I've watched with Finn show the same approach being implemented over and over again, all with the same unfortunate result. While the repetitive approach is likely designed to teach young viewers the rhyme, the reality of such an approach parallels Albert Einstein's definition of insanity.

However, one doesn't have to look too far to locate situations where the same approach has been re-attempted and a different result is expected. Here are two common examples within Information Technology:

Simply rebooting

At some point, an application running in a production state starts crashing unexpectedly. While the actual source of the situation is not easy to fully diagnose or is too involved to resolve in a timely manner, the decision is made to simply reboot the server hosting the application.

While the action causes the application to be functional again, it is only a matter of time before the server crashes again, since the source of the problem has not been addressed. In fact, the only thing that has happened is that the application was restarted.

As a consultant, I have encountered this approach even to the point where cron jobs are created to restart servers on a timed basis.

This is clearly insanity, especially when data corruption inevitably begins to creep into the problem.

Throwing hardware at the problem

The other common situation is when an application begins to slow down from a performance perspective. Maybe things were great for some period of time, but as usage or volume (or both) increased, the performance for the application started to trend toward an unfavorable state.

Like the situation noted above, recognizing and resolving the source (or sources) of the issues can be time consuming.

Since hardware (actual or virtual) is considered less expensive than a root cause analysis and resolution project, I often see where production support teams opt to move the application onto servers that provide more power to process and host the application.

Like the reboot option, positive results might be apparent early on, but over time those same issues will start to surface again, especially as the usage or volume continue to increase.

Insanity, but now with a higher price tag.

Failure of proper analysis

Wood would wash away, bricks and mortar were not ideal, iron and steel was too bendy, and silver and gold introduced the threat of pilfering. These are the results of the bridge building team's efforts to provide a suitable solution for crossing into London. And these results came at the heavy price tag of building the bridge over and over again.

In technology, we lean toward enterprise architecture efforts -- either in some online outlet or part of a dedicated team in a given organization -- to provide the proper analysis of a given solution or framework. However, it wasn't too long ago where technology teams embraced a market-leading solution for something it was not designed to do.

Here, the Lotus Notes product comes to mind.

Lotus Notes

I have written about Lotus Notes in the past, but I feel like it really applies here. With approximately 70 percent of the market share in the groupware space, companies realized there was an application component of Lotus Notes. In addition to using Lotus Notes for email and collaboration, custom applications could be developed.

This was great news, since every end-user would already have a Lotus Notes client and could simply launch the applications from their workspace. Security was already there, since it had to be created for the collaboration component to work. It was going to be great.

However, Lotus Notes wasn't an ideal choice for corporate applications. The underlying solution wasn't designed to handle such solutions. In fact, I visited several clients which had employed Lotus Notes for mission-criteria applications, some of which should have been transaction-based.

In every case, those application owners were not pleased with the platform that was running their applications, and they wished proper analysis would have been completed before the solution was selected.

One More Lesson

For purists of the "London Bridge is Falling Down" story, in the end they realized that silver and gold was the way to go, but didn't consider needing the watchman to be awake to actually "watch" for burglars.

In order to provide a solution that could hold up to all the challenges facing a bridge to London, the most expensive products would be required. Additionally, there would need to be 24-hour support to monitor the bridge. In the case of the original song, giving this watchman a pipe to smoke all night would keep him awake to avoid any unexpected visitors with ill intent.

What we can learn here is that even when you have the best solution in place, you really need some manner to monitor the solution. This is where network operations or DevOps come into play.

After all the work is done, it is crucial to keep an eye on things. Just like any edifice that exists, routine maintenance and inspection are always expected. Even from a theft perspective, the risk of data breach continues to be a primary concern for security staff. Thus, expenditures for monitoring and management become just as important as the initial application design itself.

Conclusion

Pulling it all together, I believe we all would agree that introducing a much-needed land connection over a waterway in the capital city of England would be considered an important and significant engagement. Proper analysis of the project should yield a modest budget that provides a significant return on investment, since scores of citizens and visitors would plan to use the bridge to reach their target destinations. However, this return on investment is only maximized when the following pitfalls are avoided:

• Instead of building the entire bridge, a prototype phase should be adopted. This could be completed at an alternative location, of much smaller scale, to provide a working solution that could be presented to the product owner, aka consumers of the overpass.

• Before securing the first footing, take time to research and analyze the failures from prior attempts. In this case, rebuilding the bridge using the same approach should be avoided, if that approach was the root cause of the failure.

• Recognize the fact that the bridge itself will never be a completed effort. After the original construction phase finishes, the maintenance and monitoring phase will begin. With even the best products in place, time and efforts will be required to make sure the bridge remains functional and reliable.

One final note: the original lyrics do not conclude what happens with the "pipe-smoking man" approach.  However, we have to assume it was successful, since this bridge does indeed exist today, though no longer in England.

Have a really great day!