Programmability: Don’t Just Do It – Pay Attention and Do It Well!

CommunityWe all remember the very popular Nike tag line “Just Do It.” What a great way to live your life as it applies to the world of sports and getting out there and doing it. It doesn’t matter if you are good, it’s important to just be active. However, in the world of technology, “Just Do It” doesn’t apply and, in many cases, is a very bad idea. In technology, you are bound to fail if you blindly do something without thinking about it, getting input, and doing the research to do it properly. This doesn’t imply that you shouldn’t be prepared to just do it, but, in tech, that isn’t always the case.

There is a very famous quote that helps illustrate this point, but most people leave out an important part – “In truth, whatever is worth doing at all, is worth doing well” that is the commonly quoted/known version. What is commonly left out is the key point which follows: “and nothing can be done well without attention.” Philip Stanhope, the 4th Earl of Chesterfield, wrote this in 1746 and it is just as applicable today as it was then. The attention to what needs to be done is what matters in order to do something well. This is very applicable to the world of technology and programmability today.

I see too many cases where people are forming the requirements for some new hardware or product and they just use a shallow marketing checklist. More often than not, this checklist is just a list of hot keywords or a barely understood, put together a group of standards that are being applied to product development. Which standards and what “MAY” and “SHOULD” options from the standards are the best practice ones to implement? Simply following a shallow marketing checklist is a perfect example of someone not paying attention so they can do it well.

Rushing to meet the marketing checklist versus really putting the research and details into the needed capabilities is an example of going shallow versus going deep, something we have talked about in a previous blog post on transactions and getting the right learning to succeed. When people go shallow in the tech stack, they end up with inferior solutions that will have interoperability problems or simply won’t fully meet what the market really needs.

An example from the world of network programmability is the selection of only REST or RESTCONF and not NETCONF. The majority of the time this decision is made simply because REST is in the comfort zone. This is very short-sighted and shallow. With a shallow understanding, one might assume that RESTCONF is the same as NETCONF. However, with a deeper understanding which can be gained from reading our whitepaper “Inside RESTCONF“, one will know what RESTCONF can and can’t do compared to NETCONF. This deeper understanding will enable you to properly decide whether only having RESTCONF is truly sufficient or not and avoid making a product that fails in the marketplace if it isn’t. This is just one example of how going shallow can put you into a bind. It is better to take the time to go deeper and do it right upfront so you have far fewer issues after deployment of the network equipment or services.

To truly understand NETCONF, YANG, and programmability, you need to get smarter and really educate yourself on all that network programmability has to offer. A good first read is the book “Network Programmability with YANG”. Additionally, we recommend reading some good blogs in the area such as our blogs here. We also recommend looking at our NETCONF and YANG Automation Testing program to gain a deeper understanding of how well your solution works and implements best practices for programmability.

For the tech industry, let’s change “Just Do It” to “Do It Well” through the right knowledge, resources, and approach.

2
Leave a Reply

avatar
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
0 Comment authors
Recent comment authors
  Subscribe  
newest oldest
Notify of
trackback

[…] recently talked about this in another blog post on doing programmability well. As organizations built the requirements for new hardware or solutions, programmability was added […]

trackback

[…] interoperate in any environment. This is a big reason why I continue to talk about the need to do programmability right, but make sure you aren’t doing it in isolation. With each unique device in the network, with its […]