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.