To subscribe to our newsletter (no charge) click tom@tomingraminc.com and enter SUBSCRIBE

(or UNSUBSCRIBE to stop)

Newsletter

  Home Page   

Forgotten Fundamentals

Software Success Lessons (Including AI)

• Technology Second!  
• Payback First!  (Results / Cost / Benefit / Risk / Time)
• 12 Defects, 12 Artifacts, 12 Lessons

663

Architecture

Why No Code / Low Code Solutions Have Limited Effectiveness

Forgotten Fundamentals:  Architecture Checklist

Following is a summary of our group discussion from August 24, 2026.  

The checklist is intentionally brief – to act as a reminder – not fully discussing each item.

Thanks to Cal Smith, a Salesforce Technical Architect, for joining us and helping create this list.

Finding Good Work for Senior Software People – Implications

•           This checklist and the checklist in article 657 “AI Code Generators, Low Code, No Code Solutions” show where Vibe Coding, No Code, User Development and similar approaches run into trouble – and become unviable / impractical. 
•           This is where we want to look for work – where the magnitude / complexity of the workflow gets beyond AI’s capabilities
•           NOTE:  It is becoming clear that AI Large Language Models have inherent flaws in producing the same, repeatable output from a set of instructions.  This is a HUGE PROBLEM for Code Generation and Complex Workflows
  •         Preparing your AI Code Generation with a common set of strong instructions is a necessary solution.  “Frameworks” mentioned below are the beginning of managing this need.  More to come…
•           REGULATED INDUSTRIES may be a place to look for good work because they have less tolerance for “AI slop” and inconsistent outputs that are tolerated by other industries.

GENERAL DO’s to Consider

1. Reuse of Code:  Great in theory but very real costs and time required.  Often abandoned in press to deliver

2. TESTING
   1. Unit Test Coverage – built into code packages
   2. Negative Testing – test what should not happen but possibly could
   3. Control of running tests regarding agents
   4. Testing automation 

3. Coding Conventions
   1. e.g. A class can’t be longer than 300 lines
   2. e.g. Class name standards
   3. e.g. Claude- you must tell it what conventions to use (Prompts – reuse and refine)

4. Interfaces
   1. Read only 
   2. Read write
   3. Tools, APIs e.g. Mulesoft making integration much easier

5. Performance under load
   1. Transaction volume

6. End points:  What devices do you have to support?

7. Lifecycle of software:   P.O.C. / Throwaway vs. 10 year+ usage for some applications

8. AGILE Considerations:  e.g. need architecture / solution preparation built into Agile cadence, in advance of the development story sprint.  Usually cannot cram architecture and development into a single two week user story / sprint.

9. Security:  (Huge topic – covered in later sessions) 

10. Technical debt
    1. Old systems – what are we inheriting / must deal with?
    2. New code – what are we creating?  Is it avoidable?

11. Release plan  (Tom’s favorite tool for managing scope / change requests)

12. Upgrade path  (for the application itself plus the underlying tools used)

FRAMEWORK EXAMPLES

1. Error handling framework
2. Triger class framework
   1. E.G. ...runs after DML type save 
   2. E.G. …rolls back if not completed
3. Design Pattern / Framework.  Something repeatable, known to work.
   1. E.g. Service Cloud Oriented (Salesforce)
   2. E.g. Microservices
   3. E.g. Design Checklist for developers that Tom created at Elbit with Doug D oversight

SOFT ISSUES

1. REAL LIFE:  Architect CS removed from Covid app project because he objected that solution was not HIPPA compliant
2. BEST TECHNICAL PEOPLE TEND TO BE INTROVERTS.  After a few bad experiences they become extremely reluctant to speak up
3. PERVERSE INCENTIVES:  See Tom’s published research.  Too many people benefit while not materially contributing to project outcomes
   1. E.g. Architect ST had multi-million dollar project highjacked by peers advocating pet tool with no substantive benefit

GENERAL TOOLS / APPROACH

1. Object Oriented
2. Microsoft 
3. Linux et. al.
4. Open source
5. Database
6. Customize or not
7. Cloud vs. on premise
8. Developer environments
9. No code / low code role

DON’Ts / TRAPS TO AVOID

1. The “FrankenApp” Problem… one person crams too much complexity into a single chunk.  Sometimes due to ego or inexperience.  Sometimes job preservation.  Problem goes by many names:
   1. “God Class” problem
   2. “Rambo Coders” Luis Okhuysen
   3. No Code / Low Code – trying to do too much in a single workflow – Cal Smith and Tom saw examples with Salesforce workflow tools
   4. SOLUTION:  Must break down logically into small understood chunks e.g. psuedocode
2. A VERY BIG PROBLEM WHEN COST / BENEFIT DOES NOT JUSTIFY DOING IT RIGHT!  Tom saw this devastate a $400 million company
3. “Go Do” Trap
   1. We will always have time pressure
   2. E.g. Unit testing, integration testing so often under done in rush to production

To be continued…