Framework

Success in developing a software application depends entirely on the people. A client can short cut some of the risks by engaging a team that carries experience working together. Some clients hire individual programmers wishing that skills and techniques prove compatible. They think: I need software. I’ll hire programmers. A better practice involves finding a team where the individual possess individual expertise and a history of collaborating successfully. They build software together, support it together, then take on another project.

Show Notes

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 failures

Often 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. 

What is The Soul of an Internet Machine?

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

3 | 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 touch 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. He had the same email address at FedEx. Our lives had changed during the decades. When revisiting 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 failures. I prefer success. Instead of journalling each step, I must research our efforts and timeline. It all happens so fast. Here is Slack for team communication. Yes, let’s use Jira again for managing our tasks, assignments, due dates, and progress. Ok, we’ll use Confluence for documentation. We will talk with Dimi via Zoom. Stevie and I talk via Microsoft Teams. When I communicate with folks outside the team, I use Goto Meeting. Stevie uses Microsoft OneNote extensively for note taking. Me, I used Notepad++. We create our VPN tunnels. We establish the necessary SSH tunnel with in that to further encrypt our data traffic. Dimi established the Oracle database, the schemas, and Oracle APEX instance for us. We set up our SQL Developer to connect to the database. We store away our usernames and passwords in various encrypted tools.
Every tradesperson experiences this process. Here is your ID and your access code. Here is where you park. You put your tool chest here. Your raw materials stand there. Meet Dirk. Meet your client Electrotest. Unlike other trades people, I work from home and have done so most of my adult life. Even working for FedEx twenty-five years ago, I got hired while living in Anchorage Alaska. The software development I joined lived and worked in Colorado Springs. My projects resided in Anchorage and Oakland California. Plug me into the internet with a fast reliable connection and I am at work.
I admit to being slow to writing web-based software. My career to an odd turn in 2000 after the weirdness of the Y2K kerfuffle. I got hired by Cisco Systems. I had been involved with software development over a decade by then. I had already been a contributing editor and technical editor on four books about programming. Suddenly, I spent years designing the internet. That’s over stating it, I designed systems using core internet technology as a network engineer. A lot of programming, even in that job. As that career progressed, I gradually slipped down a slope towards projects for the United States Government and our military. Within a year or so, I had military identification and military clearances at a high level. Then Iraq. In 2008, I returned to programming and returned to Oracle-based technology, y’know writing apps that people actually see and understand. I needed jump ahead eight years in writing applications. In the 1990s, our applications were not web based. Yes, we had client-side technology and server-side technology as we do today. The level of sophistication of browser-based software took off during those years when I was away. I knew internet technology intimately, a gap existed in my knowledge when I returned to writing code in PL/SQL. That gap spanned the internet that I had been helping build. Confused? The skills to build and design internet technology are different than the skills required to ignore the internet and write software that runs on both sides of it: the server and the client.
The travel ground me down. Happy to be home. Happy to have a lovely home. Here I sit in a room with light blue walls, a few mementos of my career on the walls, a comfortable chair stood at the right height. The video camera already ready for a quick call with a new colleague and a new friend.
In lieu of being shown the job site then learning where my tools go, I shuffle into my office each day. Instead of losing friends at the end of projects, I opted to build a small team around me. We have our loses and sadness, all part of the human experience. My life results in a softer transition between projects.
Often 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 or two ways. I recommend finding a team that had built their credentials and products working together. They arrive 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 succeed, 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.
When Stevie and I joined the project in December of 2021, the project lead handed us data table definitions for 132 tables, the necessary Oracle infrastructure, and a project schedule. He communicated his expectations. Dirk, as client representative, handed us massive pile of data from their legacy system, codenamed DAX.
The legacy data provided insights to their business practices. No, I could not read the Dutch very well. The terminology all focused on industrial stuff, health/safety stuff, and thus seemed recognizable. Autolaadcrane is a self-propelled crane. Like with data table definitions, I could infer a lot from the data.
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.
How did a team of two develop two functional applications in a few weeks? The answer is Oracle APEX?
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.
I hate worrying about compatibility between browser platforms. Oh, this doesn’t work on my Microsoft Explorer, or the Big Blue E or is it Edge today? Apple and its products don’t want to play with the same rules as either Microsoft or Google. Client-side compatibility requires specialization that I do NOT have to possess. Nor does our team require these skills. APEX makes this magic happen for us. For that I am appreciative. I thank you team Oracle for making this product.
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. When 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.
Being agnostic about your own operational environment is a superpower. Oracle, once, said: We know what we are. We are the best database engine in the world. Probably true. I celebrate that arrogance. Oracle says: Run my database anywhere. Therefore, I get to focus on the luxurious complexity of modelling business operations with database software. Their agnosticism become our agnosticism. Their arrogance become our arrogance. Doubt me? I am writing a database application that resides on an Amazon Web Services platform in Ireland, for users in Belgium who run the software in either French or Dutch (or English). They can do it from any computing platform: mobile, tablet, laptop, desktop; and execute their duties from any operating system: Microsoft, Apple, Linux. I don’t care what browser people use: Chrome, Firefox, Safari, or the browser from Microsoft with an “E” in it. (Listen Microsoft, it is the same damn product, stop changing the name. Nobody cares to waste brain cells tracking that stuff). Agnostic.
Oracle’s decision to step clear of the hardware and hosting wars permitted me to step clear of those same topics. I want interesting work, good pay, and the joy of building cool things.
In order to discuss applications and application framework, let’s visit the geek side for a while. First, guys, there is zero difference between software, a software application, and an app, unless you are discussing an appetizer nibbled with wine. That kind of an app is not software. Software is not edible. Yes, for some reason people argue about these terms. Rarely are the experts telling me that differences exist between an “app” and software have never written a line of code. Please dude, remove the expert patch from your sleeve.
Ugh after decades of writing software applications or apps, I can barely define the term for you. Within Oracle APEX, an application works within a database schema. It presents information and gathers information from users. Users log in via a web browser with credentials. And users log out of the application. And yes, this is entirely true for the apps on your phone whether it is candy crush or cribbage pro or a navigation system, you get logged in. That’s the bloody scary thing about apps on your mobile phone. Your phone often manages that login and authentication process for you automatically. It passes your credentials seamlessly behind the scenes. That app, and the owners of that app, know exactly who you are, how long you logged in, where you were, and what you did, even if you think you did not log in with a username and password. I promise it happened on your behalf.
Within an application of 2021, we encounter menus and options. We provide a color scheme and a look-n-feel that ought to give you a cozy feeling of familiarity. For our client, we immediately created two applications. One application focused on the behind-the-scenes management and maintenance of the primary application. Cleverly, we named the app: “Admin”. The other application provides (or will provide) all of the customer management, order management, invoice management, and inspection management needed by the client’s staff. A third, and even fourth, applications are discussed. We may provide an app for clients to login to. A client could review past inspections, plan new inspections, review invoices, and do all sorts of cool Client-type tasks. The potential fourth application may be a portable application used by inspectors in the field – specifically optimized for their tasks.
Our two applications are linked so that if a user logs into one, they can jump to the other, if the user has the correct credentials. They can jump back and forth easily.
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.
Stevie and I knew this was a rouse to develop confidence in a better plan. This rouse of serving as middleware further explains why Dirk met us with complete set of data tables. We had to interface with external legacy systems.
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.
The client, Electrotest, communicated their expectations with a colorful Microsoft Excel spreadsheet. Have I ever said that Excel is not a database? I shall rant about this concept frequently. Why? Not because Excel has a few database-type tools. No, but because Excel and databases store and manage data differently. When a human being with years of experience and familiarity with Excel thinks about data and organizing data, it often comes to us an Excel spreadsheet. That mindset limits the discussion, curtails the power of what the database can and should do. Please take this Excel spreadsheet, keep it the same, then make it a database but have it look like Excel. I’ll come back to this again, I promise. To the client, Excel ought to be treated as just-another-legacy system.
Stevie did an amazing job creating a spreadsheet-like look for the user authorization process. People in accounting get full access here and here and here. Inspectors get read-only access to this, and full access to that. Stevie replicated what they drew and delivered what they wanted. That earned us credibility and opened the door for a long-term project.
She was right in doing this. She showed off nicely.
In time, our challenge must be to train the client to provide the business requirements to us. Describe the workflow, and the constraints. Let us employ our expertise in making it elegant, flexible, and functional. Give us the freedom to lay the data out. Clients save money this way. Stevie first had to build the user permissions process the “Oracle way”. Then she invested significant time to make it look like an Excel spreadsheet with colors and such. More than sixty percent of the effort involved trying to make an Oracle database process look like an Excel spreadsheet.
That’s a balance I struggle with. 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 did 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.
We had no formal design nor requirement documents from which to start our work. Yet, we created hundreds of web pages within weeks that installed confidence in our work. Our first pass at the two applications, Admin and Customer Service, met with the client’s enthusiastic approval.
Blasting out a client profile page when given the exact data fields is easy. One pops into APEX says: Hey, I want a new page. You select your desired table from a list. Bish, bop, boop: there’s the page. APEX puts all of the data fields in order of appearance in the table down the page neatly aligned on the left column. It adds three buttons for you cancel, save, and create. A few basic rules get created. And APEX sets up the data management for you. When a user edits a record, APEX resolves issues with data conflicts and simultaneous edits. The wonderful thing about having Oracle database experts create the process of retrieving then storing data and resolving conflicts is that I do not have to. They did it. They likely did it better than I did. It is done the same way on every page in APEX. These principals we learned during the early part of the 20th Century as we build manufacturing plants.
The structure and order of data tables, improves speed and efficiency when creating these data entry pages. When you organize your data tables well with important stuff at the top, less important stuff at the bottom, APEX blasts these fields up on a page as “page items”. If you name your data fields well and without awkward abbreviations, then you barely have to touch the names that the user sees. If you use clean, complete, and unabbreviated English, then when translating to Dutch or French, those tools have an easier time translating: Invoice becomes Facture (factuur in Dutch). Had the phrase been abbreviated to INV or INVC, then the translation tools get stuck. You saved no time, no typing, no effort and may have increased cost.
We had a U.S. client a few years ago who hired three young programmers. Each programmer arrived with different backgrounds academically, socially, and linguistically. Each came from different employers. The database administrator for their legacy database system, yes, written in Oracle, but old, had his rules. All tables must have a primary key named: ID. The second field in every table was the date the row was created. The third field, the name of the user who created the row. We call these the audit fields. Good practice to have them: who created, when, who updated and when. They are the least important data in every table. This DBA’s experience which spanned many of the same decades as my own, stated that field names must be less than ten characters; a rule that forces developers to abbreviate field names. The result is that when these younger programmers started laying data entry pages with APEX, the page layout required another hour’s worth of work. Fields needs to be shifted to follow a logical progression – likely with the most relevant and most important at the top. Field names had to be retyped because the truncated versions constrained to ten characters did little to help human users of the system. Sure, did look like a 1970s system running on an old monochromatic monitor. Furthermore, as different users had to hand type these field names on the pages, they introduced variations in the naming: Invoice Number in one case; Invoice ID in another; Invoice # in a third and one through the common and familiar techniques we all use for identifying some as basic as an invoice number.
Does this seem trivial? Really no. That polished consistency marks a professional trades person or crafts person. People judge with their eyes. We love balance and symmetry.
A great web-based application requires a great database design. Data structures that are messy, non-intuitive, result in either messy non-intuitive page designs – or messy data structures result in significant investment in modify these pages one field at a time. That’s a waste and results in errors, inconsistencies, and the like.
I started this episode discussing the importance of order and procedures.
• Step 1 – gather requirements, operational practices, and the like
• Step 2 – Develop a data model
• Step 3 – Develop working applications and pages
Three steps grossly simplify the efforts and focus on the pragmatic investment rather than the dogmatic employment of fashionable terminology. 1-2-3 tends to be a good practice. At the opening, I whined about skipping steps. Then bragged about the value of expertise. To build the basic framework for large and complicated application starts with easy to execute simple steps. We have hundreds of lookup tables: This table defines the permitted languages; This table defines the invoicing methods: email, postal service; This table defines the invoice due dates or payment terms. That’s just work. When it comes to laying out a customer profile page, gee we’ve all seen that page hundreds of times. We must make it logical and attractive.
We had terrific details on the security profile based on an Excel spreadsheet. I admit frustration with the start, we delivered. When it came to the process that matters, we took that one. Yes, we invested days to get the data table structures in a fashion that permitted us to blast into web page design immediately. We knew that relationship. If you get the tables right, those early pages get built right.
Starting a project requires getting acquainted with new people, understanding new objectives, figuring out the interpersonal dynamics. During December and January of 2021, I described myself as the anti-hero within the narrative. I expect specific process and structures. I expect them because I learned them with past successes. Furthermore, I see things – I see data relationships and data patterns that others do not. I often fail at communicating these insights well. Often, I sound like a nutter standing on a plastic bucket in a city center decrying the end of it all. Occasionally, I am right. Occasionally, we can find a way around the mess I foresaw. Regrettably, sometimes I am tired, whiney, in pain, and just an ass. Sucks being human, doesn’t it?
Like that high school physics lesson where light is both a particle and a wave of energy simultaneously, we must embrace that process and results tangle and weave together. Get too dogmatic about process, you miss the joys of building a great product. Get too focused on the elegance and beauty of the product, you risk missing necessary complexities and inconsistencies that the client requires. Only going through the rigorous process of requirements gathering, design communication, and constant feedback will an application include all the elements the client needs. It is both, simultaneously.
All members of the team: client, business analysts, software developers, project leaders – we must all embrace the complexity and inconsistencies. Yes, whether technical, linguistic, or interpersonal. A ought to come before B. I agree. 1 before 2 and so on. But sometimes, just sometimes, it works anyway just because we want it too
See you next time. Be well and do good and have fun.