Boundaries in Dev

There have been a bunch of blog entries , with slightly different points of view ,  discussing the decline of object oriented programming.  I think most of them miss the mark communicating the arc of history when it comes to programming paradigms. At a fundamental level, as programming languages have evolved they have improved on two different dimensions: Abstraction - allowing the developer to develop components at higher and higher levels of abstractions. Encapsulation - allowing the developer to hide more and more details from the users of their components. Let me give you a specific example from my C++ days.  At the time, I was using the Oracle Call Interface (OCI) - a C language API to connect to Oracle databases.  Using Perl::DBI, we used code generation to automatically generate C++ classes based on the schema metadata.  The class layout looked something like this: This object oriented design had a few design features that I consider object...

In the mid-90's, there was three major object oriented analysis and design methodologies among the leaders in the field: The Booch method - In my opinion, the most technical and exacting of the methods had symbols for things like abstract class es,  parameterized  types, etc. The major problem I saw in using this method was there was less advice in the analysis phase in terms of deciding what should be an object. The Object Modeling Technique (OMT) - This technique, promoted by   Rumbaugh et. al., had a primary goal of being a communication channel with customers.  It also had drawing techniques that seemed to provide a comfortable transition from entity-relationship-drawings (ERD). This gave advice on picking objects - the classical picking out the nouns from a requirements document. The Jacobson method (OOSE) - This method had all of the standard OO techniques like the others, but also added use case influenced design and officially categorizing o...

During the time of my previous post, the version of Informix on the Amdahl mainframe was upgraded to a new version that included row level locking.  Common now, at the time, database vendors were busy figuring out the best ways to perform row level locking. The method that Informix chose had an interesting unexpected feature.  If you had a unique index on a table and you inserted a row, the database implemented a row level lock on the yet to be committed index row by locking the next row in the table.  If there was no index key larger than that, it would lock to the end of the index. This meant that inserting sequential values at the end of the table, a very common occurrence for our system, would in effect behave like a full table lock.   A clean solution to this problem would have been to apply the CQRS pattern so that the inserts into the database could be queued without affecting the user.  But that would have required a complete refactoring of the ...

In 1992, I was maintaining a UNIX inventory system that was developed around a screen template system that used the curses library to implement a pretty standard menu tree with data screens as leafs: My job was to add a new screen, the red box, and the red transition lines to do a master-detail pair of screens.  The way this system worked is that a set of screen definition files would be run through a code generation program to generate the C code that would keep track of the menu path and the fields in the data screens. Each of these screens would have a 80x24 template with field names following by a special replacement character for different field types.  For example, you could have a part of the screen say: Ship Date: MM/DD/YY or Comments: @@@@@@@@@@@@@@@@@@@ and the code generator would create all of the code necessary to define structures that had a ship_date members and a comments member, handle moving from field to field with the tab key, etc. along w...

I had the privilege of see the documentary  The Painter and the Thief  last weekend.  The film tells the story of what happens when the painter of two stolen works of art befriends one of the people who stole from her. It's an absolutely riveting movie that will have you thinking your watching a drama and not a documentary.   I don't want to say anything more about the events detailed in the movie, but I did marvel at how different a relationship can be when expected boundaries are overcome. If these two people can overcome the expected boundaries between criminal and crime victim, then there should be no reason that DevOps engineers can't do the same.  After all, both sides of that relationship want the same thing for their companies and aren't starting with a crime standing between them. And hopefully, the movie will get a distribution deal so that you can see it and make up your own mind.

In the early 90's, when I was still getting my undergraduate computer engineering degree, I took a class in signal processing that I really enjoyed.  One of the major projects we were tasked to do was to implement a 2 dimensional fast fourier transform . The class spent several lectures proving that the number of mathematical for a simple implementation for convolution in the spacial domain required O(n^2) math operations.  On the other hand, if you switched to the frequency domain, you required O(n log(n)) operations to perform the FFT, O(n) to perform a single multiplication per pixel and then another O(n log(n)) to convert it back to the spacial domain. We proved it was better! And then we implemented it, and it was orders of magnitude slower.  Theory and practice didn't match. We showed it was slow! The issue was a boundary we had abstracted away in our performance proofs - memory access was not a uniform cost.  The math operations we were optimizing ...

Naming things in software engineering is difficult , so I pondered what to call this blog for a long time before naming it.  I came up with boundary waters for a few reasons: I grew up near the Boundary Waters Canoe Area , and I have a lot of great memories visiting that majestic part of Minnesota. Software development has a lot of topic areas that are related to boundaries and it was a common theme in a lot of the initial topic areas I'm planning on writing about. There are a lot of different boundaries at the BWCA that I can use for analogies: The US - Canada border Lakes & islands The water itself The .dev domain became available and it's very unlikely to get confused with  the actual geographic area. I'm starting this blog on the one-year anniversary of changing jobs.  I left a company in the telecommunications industry I had spent over 26 years at to go work at Visa.  I now have a systems architecture role that does not include coding on a regu...