Show cover of The Soul of an Internet Machine

The Soul of an Internet Machine

"The Soul of an Internet Machine". This show explores the intersection of business and technology and the internet.

Tracks

Middleware
The first time I heard the phrase middleware, I was writing software for FedEx with a terrific team of Oracle developers in the late 1990s. I had to ask for a definition. In short, middleware is software that run between two things. Middleware is software that is invisible to the user. Middleware is software but seems to fall outside the accepted definitions of an application or app. It is software’s own software-based infrastructure. Does that make any sense? Probably not.I wrote my first lines of code on a PDP-11 microcomputer from Digital Electronics Corporation (DEC) during high school. I attended a school in a wealthy area surrounded by the massively burgeoning IT industry.  In my high school, four years before the IBM-PC came to the market, I learned BASIC. The name literally meant “Beginner’s All-purpose Symbolic Instruction Code”, and no does not relate to the American slang basic, which seems to be a bit of an insult. 10 BEGIN 20 PRINT “HELLO WORLD”30 ENDHard to imagine how these building blocks gave us the world of modern digital commerce. Those roots go back even farther. That trip requires tipping our hat in honor of Ada Lovelace, Alen Turing.My educational progression followed the global development of software and software tools. In 1982, heading to university, I bought an IBM-PC for $2,500. That was the discount a university professor got. Adjusted for 2022 dollars, the cost would approximate $7,500. As a college first year, I thought I would study computer science. Regrettably, my university’s systems were older than my high school’s systems. No way was I going to learn how to program in assembly language on a huge mainframe computer. Mainframes, in 1982, were already doomed, so I thought. I never wanted to write an operating system, which was one of the capstone assignments. I finally took CS-111 as an independent study. In a class by myself, I read Cooper and Clancy’s “Oh Pascal” learning the software language Pascal. That book remains on the shelf behind me in my office today. At the age of 28, I had already been a contributing author and technical editor for books about computer programming. Two evenings a week, I stood in front of a group of adults teaching programming skills at a community college. One high school elective and single independent study course for one semester started me on my career. While an autodidact, nearly all I learned fell beyond the reach of classrooms. School never came easily to me, likely because of my learning differences. I watch colleagues like Dimitri in awe. In direct comparison, I see that I fraud and the idiot, even today. We’re all like that though, aren’t we? We get good at something, or we get recognition then we tell ourselves: No, I don’t deserve this. From my perspective, he is better skilled that I, smarter than I. I admire he jumps between programming languages and environments.I mentioned Pascal on purpose, not just as the rambling digression (I do love my digressions though). The programming language I use for work today had been built from Pascal. Oracle, when needing to create a procedural programming language borrowed heavily from Pascal. Pascal is an imperative and procedural programming language, a natural progression for me from BASIC. The language had been designed by Niklaus Wirth. Mr. Wirth, who is 88 years old in 2022, won the Turing Prize in 1984, roughly the same year I learned Pascal. Stevie and I write code in Oracle’s PL/SQL language. The language derived from an earlier structured procedural language called Pascal, that I learned at university after learning BASIC in high school. We declare variables at the top of a subroutine. We write code in logical subroutines called procedures or functions. These get compiled by Oracle into the database as something that is no longer intelligible to human readers. These routines / subroutines form building blocks within the database to perform tasks, typically with data. One might need a routine that calculates the total value of an invoice. That routine must spin through each line of data for an invoice. The routine identifies the quantity of items ordered. It then multiplies quantity by the unit price to generate the value of that invoice line. Then we tally the total of the invoice lines to get the invoice total. We, the developers, must control this process precisely, due to the variations needed. When do you round the numbers to two decimal places? When do you calculate the taxes? How do you handle items that are not taxed. How to you calculate discounts? Each of these steps must follow the client’s instructions and we must do it precisely. The process and math must be consistent and transparent. Someone will run a calculator through the numbers to confirm the math. Later, an auditor will verify every bit of it. Nothing can be hidden. That’s the land of managing the boring business data: customer contacts, invoice information, inspection data, reporting, document management, bank balances, reservations, etc. My world.Our software depends on a user running the application within a browser. The user updates a customer’s profile or generates a service order. Those tasks such as presenting the data entry web pages to the user’s browser is accomplished by Oracle APEX. I do not have to write the JavaScript and HTML and CSS required to make an application operate within a browser. 98% web-based applications rely on JavaScript. 100% of web-based applications depend on HTML and CSS. We tell the browser to paint a region blue by setting the region’s color property to blue. We do not tell the browser how to do the painting. We only specify the color. We don’t tell a browser how to draw a line, we specify the thickness and style of the line. I won’t present a sample of object-oriented code to read. It doesn’t read well, maybe it is hard to hear: onclick= “void(0);”When I look at our applications written in Oracle APEX, the apps can look different on the different browsers. Occasionally, in Firefox, I see fonts with serif instead of the sans-serif font specified by our team. These variations are reminders of a key difference between procedural languages and object-oriented languages. With object-oriented languages, such as JavaScript, the browser decides how to execute a process. The browser’s own personality expresses itself a bit. One might argue that the process of formatting and presenting data to users via a browser could be called “edge-ware”. Browsers and JavaScript is software sitting at the edge of an application. Edge-ware, a term absolutely nobody uses, sits at the edge of a software application formatting and presenting our pages to the user. Ok, if you do an internet search on Edge-ware, you will find a village in New Zealand and a couple of companies. Let’s also quietly acknowledge that JavaScript is used on servers too. That is a more recent development. The user logs into our Oracle APEX application via browser. The data travels back and forth between the user and the Oracle server via the internet. For illustrative purposes, the Oracle Server sits in the middle of the internet, the “Cloud”. Users sit at the edge of the cloud with their phones, tablets, laptops, and desktop computers. And let’s add cars, refrigerators, doorbell cameras, modern televisions – these all sit at the edge of the cloud with you the user.  The spirit of “edge-ware” tells a story. If we have lovely object-oriented software running on the client-side, or edge, of our applications. And we have lovely software written in a procedural language compiled within the Oracle database, then how does the client/edge talk to the server and the database? Say “Hello” to middleware.Middleware is like a Babelfish (for fans of Hitchhiker’s Guide books) or the Universal Translator (for fans of Star Trek). Middleware does this cool job of shuttling instructions and data between two very different environments that use different languages and different technologies. I think I defined middleware. It required 2000 words to accomplish that goal. Through the journey I did a bit to differentiate structured programming languages from object-oriented languages.In December and January of 2021, our project with Electrotest had been defined as middleware. With a careful stretch of my definition above, our software could, maybe, possibly be called middleware. The project leaders used the term as a means of evaluating the replacement of multiple legacy systems. Our software would be a central repository for data from several external and legacy systems. Our software would sit in the middle of existing systems. Fair enough, close to the definition above, without all the discussion about babelfish or universal translators. I suspect that the project leaders used the term as a way of exploring writing new software without committing to the project. Likely also as way of softening the discussions with folks who may be resistant to change. As a team, we had been given the opportunity to solve some long term and systemic issues. A CEO rolling through announcing massive project to all software that helps the company do its thing would be unpopular. These projects occasionally fail or people get resistant to the change. The project leadership used the term “middleware” to help others accept these early steps. Middleware sounds less threatening than: “Our software is crap, we’re replacing our crappy software for the unknown crap written by someone else who doesn’t now crap about our wonderful business.” That’s good political thinking and good leadership. We’re going to stick this reliable, awesome Oracle database into the middle of our systems to help solve problems our other software doesn’t solve. To the user community at Electrotest, this approach appeared friendly and hopeful. Everyone recognizes problems in systems. We’ll just fix those in a targeted manner.To the new developers, we get the message, if this goes well maybe we can take more on later. Let’s get one thing working and evaluate.I need to remember this trick. I have been in several situations during the last decade during which the big boss stands up in front of the users to mandate immediate and instantaneous adoption of our software. The big boss writes a memo reinforcing the message. Within months, the resistance from management overwhelms all work. Resistance to change kills custom software development. And please don’t ask us programmers to manage that for you. Electrotest’s approach likely generated an environment of collaboration and success for both the user community and the developers. This definition of “middleware” became more political than technical. It worked. Well done to the team. I’d never had conceived of that approach. We benefitted from viewing ourselves as this fake-middleware. We reach into the other systems to review their data whilst exploring past mistakes. We did not need a lot of input from user for this analysis. Hundreds of customers had been named with a dot, or two dots, or a slash, or two slashes, or three slashes. What can I infer from that? First inference is that the legacy system, DAX, required the user to type in a name for the client. But the client’s name data entry process had nothing behind the scenes controlling it. Second, I inferred that most users were right handed. Their favorite keys results from movements of their right hand. Both the dot and slash sit below the right-hand pinkie finger. Why were they doing this? Clearly, I can’t know without interviewing the users. I make more inference: The user perceives no value in entering the data The user does not possess the data and therefore can’t do the data entry  There is something about the system causes the user to curtail their efforts One observation I made is that their unique identifiers for service orders were limited to six numeric characters. Meaning that each time they got to their millionth order, the order numbering process started over from 1. When you do that, the order number is no longer unique. It appeared to me that they cycled through their order numbers every two to four years. When unique identifiers fail at being unique, the data is junk. Another observation about the data is that some orders had a value of one cent. Some had a value of negative one cent: zero point zero one euros. Again, I inferred the users need to perform operational tasks that the system did not understand. The system required a price on each line, therefore zero could not be permitted. The users had to create order lines that had zero prices.The users were not wrong, the software was wrong. This happens. We call this opportunity. Business owners likely call it something else.What did we have to do to prove we could make a few improvements? I believe we had to demonstrate our ability to write software that met their specifications, solve problems, and do it at a reasonable cost while executing quickly. When managing corporate data and building an ERP (Enterprise Resource Planning) and or CRM (Customer/Contact Resource Management), customer data forms the center of the data picture. One cannot create a service order nor an invoice without knowing who the customer is and their preferences. We had hundreds of pages and menus in two applications that were linked. We included over one hundred thousand rows of existing corporate data. We had a reliable and proven login process for user authentication and authorization. When the client looked at the system roughly six weeks after telling us to execute, they saw something that they recognized as their system: their colors, their data, their flow. We wrapped it neatly in corporate branding with their logos and security. It worked reliably on Windows computers, Apple computers, tablets, phones, and desktops. It worked on Safari, Chrome, Edge, and Firefox. Some of the menu items took you to page 1, the empty dashboard page. Actually, most of the menu items took you to page 1, the empty dashboard page. What do you want in six weeks? The customer profile stuff looked good enough to earn credibility with a new client. We did put the server’s time on the dashboard. The server runs in UTC, the coordinated universal time sometimes called Greenwich Mean Time or Zulu (that a NATO and military term).We wrote almost no database code with PL/SQL, our procedural language. We limited our effort with client-side languages. We designated the desired fonts and corporate colors using HTML and CSS as appropriate. We did not have to do this for hundreds of new pages. We did it once and we were done (for now – we kept coming back to the look-n-feel, corporate colors, and logos). We never touched the middleware between the client’s browser and the server’s Oracle environment. For the dozens of lookup tables, we made one, the copied it over and over and over. All of the lookup tables had roughly the same structure with the same fieldnames. With the exception of the primary key, which was unique for each table, all of the look up tables were the same. We did not hit perfect. We could not achieve perfection. We did not have formal user requirements. We used our experiences and expertise to build a system we thought would meet their needs. We did not then have direct access to the client to ask questions. We did our work based on our professional standards. That’s what we presented. I am certain someone said: “Oh that’s perfect” or “Hey terrific”, but within days we got requests to make changes. Not perfect, but good enough. Sometimes good enough is good enough. When the mission is to build something fast, grab a big hammer and start swinging. There is time later to do the finish work, efforts we call “painting with a small brush”. 
34:17 1/20/23
Framework
I have started so many projects in my life and career. More often, I remember the end of a project. The end of a project means friends disappear. Comfortable familiarity and expertise fades. Sometimes with massive and exhaustive projects, I get sick for a while. When it goes well, I feel snuggly connected to those around me. Leaving Iraq after a year, left me drained, and I failed to keep in tough with others from those days. They also did not keep in touch with me either. That happens after projects end. I did write a colleague from my days at FedEx where we wrote software in Oracle together. This was in the mid to later 1990s. His email had not changed. Our lives had changed during the decades. When revising these teams and times, I find pleasure in the grueling and difficult environment. I find pleasure in remembering the quiet moments and the surprising moments with teammates. In the 2023 series of “The Soul of an Internet Machine”, I am making my second attempt at narrating the beginning of a project. As series 1 informs us, projects fail. Teams fail. Things fall apart. The globe faces a pandemic, etc. In December of 2021, I tempered my enthusiasm about starting a new project with reminders of past failuresOften during years of looking for projects, I see organizations especially our U.S. government looking for software developers. They hire Fred from here and Bugsy from there. Here is Mickey from another place. The bosses say: We need software, so I’ll hire developers. That process often fails. That process certainly costs more money. That process results in immediate, and often systemic problems.Let us explore this together. Electrotest demonstrated immediately the complexity of their demands plus the scope of the project, possibly lasting years. Electrotest, any client or employer, requires us to build them tools that improve their operations. We are expected to improve revenue, reduce expense, improve consistency, reduce regulatory risk, and make the work environment easier on their staff. When the work environment is easier and logical and rhythmic and symmetrical, then training new folks is easier; error rates decrease; and I’ll argue that job satisfaction improves. All too often a bank or a government entity says: Hey, we need to improve our software. The natural result then is hiring programmers. Programmers write software. We want software, therefore we hire programmers. If this is a big project, hire five or ten. If a small project, hire three. The bosses say: we hear Oracle is good. We need Oracle programmers. Or they decide on Microsoft or another brand. The first thing the individual programmers do is introduce themselves. The second thing they do is argue. They argue about standardization, about techniques, about which what is better. We invented a genre of television shows predicated on this experience. The brand “Survivor” comes to mind. One might approach the challenge in one of two ways. I recommend finding a team that had built their credentials and products working together. They arrive with as the “Pros from Dover” often ready to go. They know how to work together. They know each other’s strengths and weaknesses. They possess team shortcuts; team tools; team standards. Their team’s leadership process had been established long before your project. Furthermore, the team tends to success, or fail, together. Their loyalty often focuses on the team instead of their own individual ambitions. We build together, we succeed together. If one of us faces problems, we turn to each other within the team to provide support, love, time, or training – what ever is required. The common choice with many organizations leaps to the conclusion that programmers write software. If you need software, hire programmers. Those assumptions often fail to create an amazing team. Without an amazing cohesive team, you don’t get good software (or a good anything). Good code requires good thinking. Good thinking results in good code. You must hire a team that can think well together, communicate well together, and meet your already impossible deadlines and expectations. Any minute that requires resolving disputes or cleaning up messes costs time, energy, money, and often drains emotions unnecessarily.“Did you do your PSTs?” “Are you walking the dog or is that dog still walking you around?” “Did you find the long pole in the tent?” “I need a rubber-duck.”“Paint with a little brush”“Maintain parallel construction”“Trust the tools”“Baby Steps”“Crawl, walk, run”“Time for a big hammer”“Begin with the end in mind”“Semper Gumby”“Retreat, regroup, return”“Establish a baseline, change one variable, test, repeat.”“A then B then C”“Sometimes good enough is good enough”These phrases form a team’s shorthand. I don’t know the shorthand that Steven Spielberg’s team has. Certainly, a team’s phrases embody the spirit, ethos, and soul of a team. That’s what builds great software. By January 7th or 10th of 2021, we had an operational application running. Technically, we had two applications running. Yet on January 4th, I was still making improvements to the original table structures. I’d make suggestions then beg for approval. That often resulted in difficult phone calls and tension. Dirk and I had never met. We created a demonstration of the worst that happens when you stick two strangers together in a development environment. He was the boss in his mind. I was the boss in my mind. My table designs were better than his. His data table designs came from months of work and numerous meetings with the client for approvals. Dirk and I conflicted continuously. APEX stands at the top of software development tools that are considered low-code/no-code. At the simplest, one can select, drag, and drop data field onto web pages. APEX includes user authentication and user authorization processes. The name APEX derives from a concatenation of Application and Express. APEX resides as a native element within Oracle’s database. It turns a classic server-side database application developer like me to a cool, hip, web-based application developer. I am not required to know CSS nor JavaScript. People create complete applications without writing any code in PL/SQL (Oracles procedure programming language). Nor are folks required to write queries with SQL. This is the definition of low-code/no-code. That takes an application only so far. When you have scores of tables and data for those tables that each need a quick means of management, drag-and-drop is lovely. It is fast. APEX provides standardized and familiar menu systems that resemble the types of menus one sees at on-line shopping sites, banks, and credit cards. I do not have to build that stuff. I don’t care too either. In the early minutes of a project, creating a framework for an application or a suite of interconnected applications ought to be simple, fast, reliable, and consistent. Additionally, I do not want to spent time worrying about the responsiveness of an application. It ought to look great and function fine on a mobile phone platform, a tablet, a laptop, and large-sized monitors often found on an office desk. Somebody else solved that problem already. I don’t need to replicate that. I certainly don’t want to introduce my own mistakes. As the technology related to presenting an application on a web browser improves, I don’t need to chase those improvements around. HTML version 4, then HTML version 5. CSS progressing through the years, now using variable substitutions. Cool, mature, growing up. Yay. Well done HTML and CSS. Oracle’s history spans back to the early 1970s as a relational database tool. There are few companies standing in our industry with heritage of this nature. IBM is older. With Tracey Kidder wrote “The Soul of a New Machine”, he described the goings-on at a company called DG. Gone. DG’s offices were near my childhood home. In the same cluster of towns, you could find DEC, Digital Electronics Corporation. The founder of DEC lived on the same road where I grew up. My school bus, good old #7 with my bus driver Joe, passed Ken Olsen’s home twice every school day. In the same region of Massachusetts, you once found Wang. An Wang and his family lived near me. My mom played tennis with Mrs Wang. I went to primary school with one of the kids. Gone. Oracle made good decisions. Somebody decided to be agnostic about the technology a database requires. They said: We don’t care if we run on an IBM, a DEC VAX, a Wang system, or a PC type server running Microsoft Windows. I am noticing a bit of shift in this agnostic approach, which may bite them. Good luck. The company that survived through five decades of information technology growth seems to be wedding itself to its own hardware platforms. Our Oracle APEX application get hosted from a centralized Oracle server. Some tasks run on the user’s web browser such as the client profile page. We provide the instructions on how that looks, where the buttons are, the colors used, and etc. Some tasks run on the Oracle server such as updating the data tables and processing data as one might when finalizing an invoice and generating the invoice PDF form.We delivered the first draft of two applications to the client in January within a month of getting the assignment. We took time off for holidays and family too. A good team, plus good tools, plus a professional and seasoned set of standards, plus expertise creates efficiency. We’re the “Pros from Dover”. We had a pre-demo review on 11 January 2022. On 17 January, the software was being demonstrated for the client at their site. In the early stages the objectives of our project remained deliberately minimal. The project leaders feared treading on legacy systems and facing institutional resistance to change. At that moment, we publicly stated we were writing middleware. Our initial goal involved connecting disparate legacy systems siting on a variety of platforms and written in other languages. The client provide us with their “Brand Book”, a series of logos, definitions of their preferred fonts, and their designated corporate colors with red as the dominant color. During these weeks, we dedicated ourselves to building a Contact or Customer Resource Management system, a CRM. We build client profile screens, contact profile screens, starting embracing the bizarre challenges with addresses and locations. Stevie built a glorious and beautiful system for user privileges. Do we optimize everything forcing change down the client’s throat? Do we optimize everything because it will be cheaper, more resilient, more reliable, easier to support and easier to use? Or do we deliver to the client what they want in a manner they expect to see it. I often get it wrong. I do so early on with this project in a significant way. Of course, I still secretly believe I was right. Who cares about right? The client cares about getting what they asked for. Do I tell them they are wrong? Do I tell them we can improve?In one belief structure, we hold the maxim: “The customer is always right.”In a contrary structure, a practitioner may say: “If they could do it themselves, then they do not need me.” From preparing taxes, to performing surgery, and executing a criminal defense, clients often defer to their hired professional. Like earning credibility and trust within any environment, then we discover the truth teetering between both. Like that physics challenge from high school when I endeavored to understand that light is both a wave and a particle. Seems contradictory.In this case, the client gave us details and instructions that appeared to constrain our process. Yet, we build two applications with speed and total freedom. Both statements remain true. We modified Dirk’s table structures to come closer to our team’s standards whilst retaining the original nature of Dirk’s intent and the data structures the client approved. 
35:49 1/6/23
Data Tables
During the last half-century, we revise the terminology related to the early days of a software design process. Hopefully, when we ignore dogma, the goals are the same. We, the developers, must create tools for clients that work to improve process. Pragmatically, the process is a bit messier than the ideal suggests it should be. Step 2 then Step 4, then maybe circle back to Step 1 or 3. That’s life isn’t it?Instead of getting client requirements in December as a means of starting the project, I got handed hundreds of data table definitions. With my experience I could read these data tables and read the data presented in other formats and reverse engineer the process. I could do this while simultaneously seeing flaws in the not-a-design. How?How can I look at hundreds of tables and do this?Accounting systems, invoice generation, inventory systems have been around for decades. The architecture remains consistent. They are based on analog processes well established by accounting traditions. The buzz words are ERP and CRM: Enterprise Resource Planning and Customer Resource Management (or Contact Resource Management). These systems date to the earliest days of commercial software. The first real test for “computer” systems – I put computer in quotes followed this progression:1.       Calendar Calculations including celestial positions. These calculations help ocean navigators know their position on the globe. Think: Astrolabe, even Stonehenge. Estimate of eclipses, moon phases, and seasons. 2.       Census tabulation – That’s where Herman Hollerith made is mark at the turn of the 20th Century. His thing eventually became IBM. 3.       Ballistic Trajectories – how much energy does it take to launch a thingy from here and land there with precision. Hey, it was World War II, we wanted to hit a few targets. This stuff tied into the post-war Space Race. During the space race, we used early computers to aim a rocket at the Moon.4.       Accounting.Our team is expert at seeing data structures and workflows for back-office business functions such as managing funds, managing documents, and managing process. We explore the use and role of a data table in an Oracle relational database. My father, when talking about writing said: Maintain Parallel Construction. Parallel construction techniques lend to punchier writing. Picture a dynamic preacher delivering a sermon with rhythm. You can anticipate; the preacher pulls you along – or so I recall, been a while since I stepped into a church for a sermon. We create these patterns deep within the buried infrastructure of code for the power it brings later in construction. These techniques improve efficiency. These techniques reduce the risk of errors. You don’t accidently refer to the wrong foreign key, the wrong table.The early work was good and accurate enough for us to start. We delivered a preliminary model and framework to the client by the first week of January 2022. I might have been rude and horrible, but we delivered a remarkable framework and first pass at the application before the end of the first week of January 2022. 
40:38 12/23/22
Series 2 Introduction - Electrotest
My colleague Stephanie, or Stevie, and I have working together for over six years. We’ve written commercial software that has managed billions in U.S. federal government funds. We’ve written software that helps an airline inspect their ramp operations. In the past, I worked on a team that use software to catch bad guys. The Electrotest project started in December of 2021. The audience for this podcast includes business folks who must manage data, manage software, or manage software development. Additionally, the audience includes technical folk interested in Oracle database application development. I blend story-based narrative with some technology and real-world business examples.We learned of the project during the fall of 2021 as negotiations became an open secret within our team. I designated 06 DEC 2021 as the official start of the project. Reviewing my email one year later, I see that through the middle part of December of 2021, we were transitioning from one European-based client to this new client in Belgium. On 22 December 2021, I have an email with the subject line: een paar issues meaning “a few issues”.  We spent most of that month finding our footing. We set up the tools needed to share code via GitHub. We established our management process with tickets and workflows. In our first European/Belgium project, we were late to the team. We came in with specific expertise. We communicated only with the existing development team who were located in Slovenia and Belgium. We never met the client. Lovely project. We came in as the “pros from Dover”. Through this podcast, I intend to illustrate that:  Writing code is writing. Writing code is elegant. Writing code is story telling. Beautifully written code is beautiful.  Well written code follows a streamline, logical, precise process called thinking. My father, a novelist, once said: “Writing well requires thinking well”. My corollary to that statement is that: “Good code requires good thinking”. No one can write good code without clarity. I derive the same satisfaction from writing code as I do from writing stories. That thought; that vision; that story; that process in my brain needs to be communicated to another. That thought needs to be understood by another. That thought, when communicated, must be logical. My friend and colleague in Belgium seduced me by stating that this project is ours. We will start from scratch, from a white piece of blank paper, from an empty database, from a green field that has never been turned. The statement proved to be a little wrong. Who cares, he proved himself to be mostly correct. Yay! We are a couple of North American programmers based on the East Coast. I am in New England. Stevie is in Virginia. Eli, whom you’ll meet later in the series, lives now in Washington State. Our client and project manager live in Belgium. We got hired for this job precisely because we are experts in back-office functions such as invoicing, regulatory affairs, document management and all of the boring things that keeps our global economy rolling along.Our client is a Belgium firm called Electrotest. This company inspects industrial and residential properties focusing on regulatory compliance and health/safety concerns. These are the guys who inspect lifts/elevators and cranes and smoke detection systems and fuel/petrol stations. If there exists a nexus between safety, health, and human occupation, then Electrotest is likely to inspect it. In some cases, the inspections fall within governmental guidelines. In some cases, the inspections are required by the domestic gas companies of Belgium. In some cases, they provide the home or electrical inspections related to new construction or home sales. For listeners in the United States, this process does relate. Nearly all of us have stood in a hotel lift/elevator reading the safety certificate. In the U.S., this certificate tends to be issued by a municipal or local government official. Following new construction or remodeling of a home or office, a local government official tends to inspect and certify plumbing, electrical systems, fire prevent/fire detection systems. In the U.S. these processes are fragmented by municipal, state, and federal regulations. The Kingdom of Belgium has a population of more than 11.5 million people. The New York City metropolitan area has 20 million residents. New York City metropolitan area is about half the size of Belgium at 12000 square kilometers. Belgium is about 30000 square kilometers. The central government of Belgium seems both a bit more centralized than the US, but also complicated by having multiple cultural and language borders which sometimes have their own regulatory scope. For example, rules in Flanders may differ from Wallonia. Seriously, who wants simple?Writing software for Electrotest to perform and report on their inspections is a bit simpler because of the stronger and centralized nature of these health and safety regulations. In my rural Vermont town where we trade eggs for homemade bacon and hang hams in the basement, I do my own electrical work. I’ve redone most of the plumbing in this house. We don’t do inspections here. There are no inspectors. It simply isn’t a thing. But a few kilometers over the line into Massachusetts, the process follows different rules because it is a different state. And we have fifty-four or fifty-five states (or state-like entities). I know, our flag only has 50 stars. There are 4 million American citizen in Puerto Rico who have no rights to vote in our national election, get no representation in our Congress, have no star on our flag, etc. We exceed others with our inconsistencies and shenanigans. From their offices near Brussels, Electrotest is able to provide inspection services to individuals (particularen) and corporations throughout Belgium. What does Electrotest need?Bluntly, they need everything we can offer. Their staff appear excellent at their duties. Before we met them, they generated nearly 50,000 invoices per year by hand using Microsoft Excel Spreadsheets. I will say this often during the 2023 series of “The Soul of an Internet Machine”, Excel is the world’s worst database. In fact, it is not a database. Oh, go argue with me. Blah, blah, you can query from column and select stuff, blah, blah. Go ahead, I’ll ignore you. Databases are relational and robust. Database use internal rules to maintain data integrity. Databases manage large, robust, complex data with grace and ease (if you have developers like us who make it graceful and easy). I shall not dive deeper in to their manual and internal system. They made the decision to modernize. We praise that decision. To their credit, they have tried numerous systems both commercial and custom over the years to make some improvements.Can we automate systems for invoicing and save them money? How do we do that? Is money leaking out of their manual processes? Are they or were they losing money due to process management? Can we automate processes for pricing? Can we automate the processes needed for taking a service order? Can we automate and standardize the process of generating inspection reports? The first time I saw the CEO of Electrotest get quoted in the press for her endeavors she did not focus on the financial gains. Instead, she revealed several specific climate goals for the software. I never once thought that back-office automation of a national company could or would have a positive impact on climate policies. She made the connection.In an early release, Stevie demonstrated some of our preliminary tools for planning inspections for inspectors. Through our digital connections, APIs, to mapping services at Google and Oracle, we can estimate both the travel time and the travel distance between two appointments. Therefore, this software can and will aid Electrotest in optimizing inspector’s travel. Yes, in days of escalating fuel and electricity costs, reducing the kilometers driven each day has a positive impact on our planet. It also saves the company money. A kilometer not driven is a bit of carbon not launched into our atmosphere. Yay for the home team.Our team has grown since we started in December of 2021. Our internet machine, our software, exceeded several expectations, but not without hard work, small setbacks, frustrations, and immense joy. I love this project. I see how our work positively impacts the hundreds of people at Electrotest. I see that our work increases the value of this company and enhances their competitive position. I feel like a member of a winning team. That’s everything to me. I’ll digress before closing. I spent a year in Iraq as a civilian member of the United States Army during 2005 and 2006. I served as a technical specialist within a military unit. My boss was a major. Together, we supervised the activities of a platoon of soldiers. Their mission was to improve the digital communications platforms in central Iraq, although we travelled to Northern Iraq too. When we arrived with fiber optic or microwave systems, soldiers could call home and talk with family. Yes, all the secret military data moved better too. I walked about 10 kilometers most days in that blistering heat. We called ourselves “The ATT of Iraq”, and yes, we did interface with the local telephone company too. A long the way, we stood up antenna masts and poles. Often in the soft concrete, I would write my name or my initials or my call sign (the soldiers called me “Charlie Mike”). I can still find several of these poles and masts on Google Earth. I cannot zoom in well enough to see my little signature though. I admit the war was ill conceived, resulted in a disaster, and I happen to be there when a civil war broke out between two factions within the country. Basically, that all sucked. I envisioned that twenty years later, I could return to Iraq to see what remained of my work, of our work. That sense of seeing and touch your own efforts years later brings pride. Imagine being part of the team that built the Brooklyn Bridge or having an ancestor that built it. That’s pride. You look and say: “I built that!” Frankly, we are always part of a team. The pride we feel is personal. I look down from Google Earth and feel pride that once I did that. That’s mine. I was a part of that, that 1 pole, that 1 fiber optic line, that 1 microwave shot. That’s everything to me. I love that sense of pride from building something good, yes even in a horrible combat environment. The pride remains. I did that. We did that. I was a part of that. Our work contains a bit of our soul, our personality, our sweat, our tears (yes, occasional tears no matter how many times I insist: “There are no tears in software development”). That is our investment. The reflection of our work whether it is the Brooklyn Bridge, a tall mast tower in Iraq, or software is the reflection of our own effort. We put the soul into our machines. In the early 1980s, Tracey Kidder wrote a book called “The Soul of a New Machine” where he explored the process of building a new computer and told us stories of the people. He gave us a story about people while they built a thing. I challenge you to look at the modern tools around you, the software you use, and think to yourself: A team of human beings made this. That might lend to why? What decisions did they make? That’s what this series is about. How is it that a few human beings make stuff up, make things happen, and build a machine together.What comes next for this series?I’ll start at the beginning and explore the beginning from the perspective of a newbie to a team and a project. I’ll also bring in other points of view from other teammates. My personality will show through including some sour or frustrated opinions of some of the work I had to do. Yuck. And the great things we accomplished. You’ll get to know our team: Stevie, Eli, Dimitri, Bram, Dirk, and others as they join.
31:15 12/9/22
Echoes of a Lincoln Song
 Echoes of a Lincoln SongListeners I am putting out this story for your enjoyment and dedicating it to two friends: Lynda Copeland and Ginny Lemire. I wrote this piece upon request of my mother in 2003, before I moved back to my native New England and before spent a year in Iraq (2005/2006). It is written about the Town of Lincoln MA, the town of my youth.Lincoln sits between Lexington and Concord, famous for the battled of the 19th of April 1775. The bloodiest fighting of that day’s battle and the capture of Paul Revere both happened in Lincoln. My mother wanted a little story for a publication she was working on.Read more: https://ChristinaMoore.us/echoes-of-a-lincoln-song/
10:20 2/3/21
Chapter 12 | Its Just Work
For transcription and notes, click over to https://ChristinaMoore.us/its-just-work/
18:43 1/27/21
Episode 11 | PST Baby: Primary Secondary Tertiary
Show notes, transcriptions and other information can be found at https://ChristinaMoore.us/pst/
24:52 1/20/21
Chapter 10 | How to Hold an Axe
For transcript and notes: https://ChristinaMoore.us/how-to-hold-an-axe/ or follow me on twitter @cmoore_sp
27:30 1/13/21
Chapter 9 | The First Minute
Ever think about the seconds immediately after buying something online? You get an email. You may have been added to a mailing list. In the seconds buying our product, there are 14 steps, 4 vendors, and thousands of lines of instructions. All invisible, all immediate. When it works, money flows into a bank account. When it goes badly, sweat drips, anxiety soars, and bosses pace. Follow the haps and mishaps of a software development team starting a new venture with a new product on the Soul of an Internet Machine.
30:05 12/16/20
Chapter 8 | Okta
Head over to https://ChristinaMoore.us/okta/ for transcript, notes and more
29:22 12/9/20
Chapter 7 | Wayfair Wayside
For transcript and full show notes, head to https://ChristinaMoore.us/the-soul-of-an-internet-machine/
16:53 12/2/20
Chapter 6 | Recurly
Show notes, transcription and more at https://ChristinaMoore.us/the-soul-of-an-internet-machine/
34:58 11/25/20
Chapter 5 | PayPal
For show notes, downloadable transcript and more head to the website: https://ChristinaMoore.us/the-soul-of-an-internet-machine/
22:29 11/18/20
Chapter 4 | Plans
Transcripts and more located at https://ChristinaMoore.us/the-soul-of-an-internet-machine/
15:40 11/11/20
Chapter 3 | The Machine
For transcripts, show notes, and other information please visit the website: https://ChristinaMoore.us/the-soul-of-an-internet-machine/
21:27 11/4/20
Chapter 2 | The Cloud
Exploring The Cloud and its context to business forms Chapter 2 of our story. Show notes are at https://ChristinaMoore.us/the-soul-of-an-internet-machine/
16:56 10/28/20
Chapter 1 | An Introduction
Full show notes at: https://ChristinaMoore.us/the-soul-of-an-internet-machine/
18:22 10/21/20
Trailer
My name is Christina Moore. I am a tool-smith. For over thirty years, I design and build the tools of the modern economy. My craft and the practice of it evolved from an older time with people working over flames, and forges, and whacking things with hammers. I design, build, host, and support software. Software is the most ubiquitous tool of our economy and likely the least visible. You may be listening to my podcast on a computer weighing 200 grams – your mobile phone. In the recent six decades, tool smiths like me have put software into the tiniest of items. We have moved software from floppy disks to phone then into The Cloud.In this podcast, I will explore The Cloud as an evolutionary grow stage of how we manage information and data. By we, I do mean all of us, not just the geekier amongst us. I will explore The Cloud and how it interacted with the design, development, and launch of a new business venture. Two stories for the price of one.Who is my audience? Let’s start with the curious; curious about technology; curious about history; curious about business processes and entrepreneurship; curious about invention and product development; curious about science. My stories involve people pushing the margins of technology and exploring. We explore and fail. We explore and change directions.From the first days of this project, I journaled my experiences as a business owner and technologist. I observed a subtle and massive (is that possible) shift in the architecture of software. In 1982, Tracy Kidder published a book called “The Soul of a New Machine”. He precisely captured the transition between the traditional big-iron landscape of the computing industry as we adopted smaller desktop units. During 2019 and 2020, I recognized that software and hardware had again made a similar step forward. In homage to Mister Kidder’s insights and timing that have named this work: “The Soul of an Internet Machine”
02:59 10/14/20