The rapid growth of low-code tools, Orchestrations, Form Extensions, and automation capabilities has made development more accessible than ever. But according to Tim Koch’s BLUEPRINT 4D 2026 presentation, accessibility should not be confused with simplicity. Effective JD Edwards development still requires discipline, planning, and a developer mindset.

In “You Have to Fight for Your Right to Code,” Koch challenged attendees to look beyond simply making something work and instead focus on building solutions that are maintainable, scalable, and supportable over the long term. The session emphasized that great developers are distinguished not by the volume of code they write, but by the quality of the practices they follow.

The Difference Between Making It Work and Building It Right

One of the central themes of the session was that many development issues stem from shortcuts taken early in a project. Code may function correctly today, but if it is difficult to understand, troubleshoot, or modify six months from now, it creates unnecessary technical debt.

Koch stressed the importance of fundamentals that are often overlooked. Descriptive variable names, consistent naming conventions, and clear documentation may seem basic, but they dramatically improve maintainability. When developers inherit code from others—or revisit their own work months later—those small details can mean the difference between a quick fix and hours of investigation.

For JD Edwards developers, naming standards become even more important because they simplify debugging and make it easier to identify variable types, business objects, and processing logic. Consistency across a development team creates a common language that improves collaboration and reduces errors.

Documentation Is Not Optional

Koch openly acknowledged that documentation is often one of the first things developers want to skip. However, he argued that modification markers and code comments are among the most valuable investments a developer can make.

Proper documentation improves traceability, simplifies troubleshooting, and becomes especially important during upgrades. When organizations perform code comparisons or retrofit customizations, clearly marked modifications help teams quickly identify what changed, why it changed, and where those changes begin and end.

This becomes even more critical in organizations with multiple developers working across shared applications and Orchestrations. Without documentation, troubleshooting often turns into a guessing game. With it, teams gain transparency and accountability.

Flexibility Through Soft Coding

Another key takeaway from the session was the importance of designing solutions that can adapt to changing business requirements.

Koch highlighted several approaches to soft coding within JD Edwards, including User Defined Codes (UDCs), processing options, and custom tables. Rather than hard-coding business rules directly into applications, developers can create flexible structures that allow administrators and business users to make changes without requiring code modifications.

A practical example involved freight calculations. By storing values in UDC tables rather than embedding them in code, organizations can quickly adjust thresholds or business rules without development effort. What might otherwise require a code deployment can instead become a simple configuration update completed in seconds.

Custom tables and forms can provide even greater flexibility, allowing business users to maintain information such as customer contacts, email recipients, or operational parameters without relying on IT resources for every change.

Think Like an Object-Oriented Developer

While JD Edwards developers may not always think of themselves as traditional software engineers, Koch emphasized that object-oriented principles still apply.

Whether building business functions, Event Rules, Form Extensions, or Orchestrations, developers should focus on creating reusable components rather than monolithic solutions. Large, complex programs become difficult to debug and maintain. Smaller, modular components can be reused across multiple processes and are easier to troubleshoot when problems arise.

The philosophy is simple: build once and reuse often.

This mindset is particularly valuable when working with Orchestrations. Rather than creating a single orchestration that performs every task imaginable, developers should break functionality into logical components that can be combined as needed. The result is cleaner architecture, reduced duplication, and greater long-term flexibility.

Orchestrations Still Require Development Discipline

One of the most interesting discussions centered around the perception that Orchestrations are primarily tools for non-developers.

Koch challenged that assumption. While Orchestrations make automation more accessible, they still require many of the same development principles found in traditional coding. Developers must validate data, handle exceptions, manage rollback scenarios, implement security controls, and account for unexpected inputs.

Simply dragging and dropping components together does not eliminate the need for careful design.

The session reinforced that successful Orchestration development requires understanding business processes, anticipating failure points, and planning for how transactions should behave under real-world conditions. These responsibilities remain fundamentally developer-focused, regardless of the technology being used.

Start With a Design Before Writing Code

A recurring message throughout the presentation was the value of planning.

Koch shared that his development teams are required to create a high-level design before writing a single line of code or creating an OMW project. The design does not need to be formal or complex, but developers should understand the problem they are solving, the tools they plan to use, and the overall architecture before implementation begins.

This simple practice often prevents costly rework later. Developers who take time to think through requirements are less likely to discover major design flaws halfway through a project.

What feels like a delay at the beginning often becomes a significant time saver by the end.

Modern JD Edwards Development Requires Continuous Learning

The session also highlighted the growing number of development tools available within the JD Edwards ecosystem. Form Extensions, Logic Extensions, Orchestrations, UX One, Jet Pages, and other modernization capabilities continue to expand what developers can accomplish without traditional customizations.

However, Koch cautioned that developers must understand when each tool is appropriate. There is no single solution for every requirement. Success comes from evaluating the available options and selecting the right tool for the specific business challenge.

As organizations continue modernizing their JD Edwards environments, developers who embrace these tools while maintaining strong development fundamentals will be best positioned for success.

The Bottom Line

At its core, “You Have to Fight for Your Right to Code” was not really about coding. It was about craftsmanship.

Tim Koch reminded attendees that great JD Edwards development is built on fundamentals: clear naming conventions, thoughtful documentation, flexible design, object-oriented thinking, and careful planning. New tools may change how developers build solutions, but they do not eliminate the need for sound development practices.

Organizations that embrace these principles will not only create better applications today—they will make future upgrades, troubleshooting efforts, and modernization initiatives significantly easier tomorrow.

For JD Edwards professionals, that may be the most valuable development strategy of all.

Want more?

Explore more content and resources to help you get the most from your Oracle investment:

• Visit the Quest Learn Library for blogs, how-to demos, and on-demand sessions.
• Connect with peers in one of our Quest JD Edwards Community User Groups to swap stories, ask questions, and share tips with other users facing the same challenges.
• Bookmark LearnJDE for updates from JD Edwards development.

Not a Quest member yet? Join today and tap into the ultimate Oracle customer network.