In the software world, you hear the word “framework” all the time. Of course, it’s implicit connotative meaning is pretty straightforward but when you start to examine things a little closer, you’ll see that software frameworks are a set of tools that allow you to build an application. That’s it in the simplest form. When you are a software developer though, choosing the “right” framework is always a tricky disposition. A wrong choice can leave you with years of time invested only to find out that the framework you’ve based everything you’ve built on is no longer supported.  

Languages vs Frameworks

  Don’t be confused between a “language” and a framework – the two are independent of each other. You can program in a bunch of languages and some frameworks are specific to that language set however some frameworks are independent. I know, it’s confusing to me as well and I’ve been doing this since the early 90s!

You pick your language (or languages as most developers should be able to do more than one anyway) and then you adapt. At TDS, we went through different phases of how we develop applications. Since we’ve mostly been focused on manufacturing and logistics clients and the length of time we’ve been with them is hovering around the 20 year mark, we’ve done things in different ways and morphed into where we are today.

A Bit of History

  We started out developing in Delphi (Object Pascal) and Microsoft SQL Server 6.0 building custom client/server applications back in the 90s when I had my first company. The choice back in the EARLY 90s was Visual Basic or Borland’s Delphi product. After a month-long exhaustive side-by-side comparison for which, I had to learn both languages! I realized that Delphi was far superior to Visual Basic in performance and third-party libraries (there’s a new term – more on that later) that would allow me to build applications that my clients needed the quickest.   We developed a lot of applications and they were solid performers for many years. In fact, one of them is still running after 19 years (and counting)! My only regret (and yet saving grace) was that I never fully developed a “framework” of my own in which to deliver the applications within the Delphi product. We mostly copied/pasted libraries and modified them as needed. A lot of that was due to the fast-paced changes that were occurring in the industry. The web was just starting to make it’s way to the forefront. You have to remember we’re talking late 90s! Some of you reading this might not have even been born yet.

Turn of the Century, Time for a New Development Platform

As we got out of the Y2K crisis (where we even had DOS applications running Foxpro and Clipper – yes, I am THAT old), we started to rethink how we can incorporate web technologies within what we were doing. There wasn’t a huge calling for it since all of the applications revolved around the manufacturing floor we were focused on integrating with industrial systems more so than worrying about web sites. With new versions of SQL Server starting to come out with more in-depth features and the release of the Microsoft .NET Framework in 2002, we started to rethink what Microsoft was trying to do. If you were ever part of the development community back in the 90s, you’ll remember all the frustrating things like DLL Hell and Blue Screen’s of Death (well that might still go on a little) and Delphi wasn’t impervious to any of things. In fact, with the pace that was being set forward by Microsoft, Delphi started to lose its market share within the developer community.

Time for a Change?

I originally chose Delphi because of the Object Pascal language. I felt like I was drawn to it’s structure and it just made sense to me. VB always frustrated me and seemed to confound me. I like structure and it also helped that the other developers that I hired all knew Delphi and worked with it but now, we started to look at alternatives when 2006 rolled around and version 2.0 came out. We were getting more requests to do some web-based things and there was a lull in work around this time. We actually had time to look at what was out there. We did an in-depth dive into C# and I took to it like a fish in the ocean. I loved the syntax structure (albeit backwards from Pascal in some manners) and absolutely loved the case sensitiveness of it. The best (and worst) part of it of course was ASP.NET. All of sudden, we could write reusable libraries that we could adapt to work between web and windows forms projects.

Libraries vs Frameworks

So there is an excellent geeky article about Libraries versus Frameworks but in essence we, at first, were simply sharing libraries of functions across different applications. Simple things at first: grids, how to connect to a database or how to run a stored procedure. That need to simplify and write-once did give birth to our Trinity Framework though. We needed a way where we could spin up a shell, security and menu management without having to write a lick of code and by just attaching our own DLLs as a starting point. That need to simplify and write-once did give birth to our Trinity Framework though. We needed a way where we could spin up a shell, security and menu management without having to write a lick of code and by just attaching our own DLLs as a starting point. After MANY iterations (we’re talking over 7 years!) we finally managed to incorporate most of what we want to the point now where we can focus on delivering functionality and the details of the application versus copying/rewriting things again and again. It’s a huge time saver for us and our clients. The beauty of what we’ve done though allows us to focus on what the application needs to do because we already have 99% of the components we need to realize a function. Not having to write the same code or functions to do the same thing is key.

Where Are We Heading?

“Plus ca change, plus c’est la meme chose” (The more things change, the more they stay the same). It’s the one thing I’ve learned in my 30+ years in this industry. Change is inevitable and we must change and adapt to continue to build productive solutions for our customers. The change we made from adopting the .NET Framework was a solid choice and has allowed this business to grow. AI is something that I’m keenly interested in. Especially in the way that we can harness the power of machine learning and put it to work in the manufacturing world. The only way that we will able to move down that pathway is for an efficient and cost-effective way of integrating these sensors and disparate device data into our application collective. That’s where I see TDS’s next couple of years focus: Extending our framework to incorporate the data collection and integration so that we can look toward the next advent: Having the machine interpret the data that we’ve collected! The future (at least in the manufacturing world) is to be able to have the machine tell us that something is wrong (an unnoticeable change in LTS data that we couldn’t see from our dashboard, for example). Baby steps! Always baby steps.