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