Someone sent me this post on 40 years of programming. It's a read that laments a few things and complains about many others. Most of the thoughts are opinions, and as such, you may or may not see validity in them. I suspect most of you, like me, see some things are mostly true and some as just false. Since I've been in this business for nearly 30 years, many of the comments bring back memories and thoughts about my career as well.

One of the things I do lament is the declining quality of documentation. I've seen the volume and detail decline over the years. I wouldn't want to go back to paper, but I would like to see better examples and more complete examination of the ins and outs of the various functions and features. Far too often I find that there are examples, explanations, or behaviors that are missing. I see the same thing in blogs and articles, which often leap and skip steps in their race to publish.

Focus and detail on a specific topic has been forgotten by too many. Even understanding the way your code works, or the ways the dependencies work has been lost. As more and more people move to using NuGet and pulling down packages, I find too often that many developers don't quite understand how their systems work. The divide between those that practice DevOps well and those that just release code faster continues to grow. Few learn from their efforts and produce smoother software development pipelines. Most release code faster, losing track of which versions and dependencies that are required.

I still see projects from GitHub and other sources that lack explanations of how to actually compile and setup the project. It seems far too many developers half release software, expecting others to spend time learning what works and what doesn't. What versions were used, and might be needed again. Maybe in some places the software evolves so quickly, adopting new methodologies and technologies constantly, that developers never need to truly understand the system. They just get things working and then change them.

Maybe that's why so many people want to rewrite and reproduce software rather than using some existing project and improving on it.

The one thing I do wish was in all languages is a standard way of handling data types and comparing them. I constantly struggle with = and == when I move away from SQL. The comparisons in PoSh make no sense, and I regularly get errors from > until I change to -gt. It seems plenty of language designers want to make their own creation and cause divergence for no good reason. I do wish SQL had implemented == for comparisons, or that they would in the future.

As I look back, some things in computer science haven't really changed at all. Speed and scales have grown, but many concepts remain the same. However, in other ways, I think we've come so far, building amazing systems that are interconnected in ways that we might never have imagined a decade ago, much less 30 years ago.

Join the debate, and respond to today's editorial on the forums

In DR planning, RPO and RTO are two concepts that help you determine what process or procedures to implement. RPO is the recover point objective and deals with determining which points in time you can recovery back to. This is essentially the amount of data loss you allow.

RTO is the recovery time objective, or how long it takes to restore systems to use.

Ref: RPO - click here

RTO - click here

» Discuss this question and answer on the forums