OLC 2.0 Problems

OLC 2.0 Problems

1. Project complexity underestimated

   • Primitive development approach
     • No unified effort - SBU teams work in silos
       • Wildly different development approaches
         • Project management
           • Different task-tracking software used across SBUs
             • Jira
             • Devops
             • Sharepoint
           • Different developer's responsibilities
             • Developer has to consult others to understand the business processes
             • Software development is only one of their responsibilities
           • Effort planning and tracking
             • Tasks and Incidents are scattered throughout Planner, SNOW, Sharepoint and Excel workbooks
             • No Sprint planning to set priorities and expectations
             • No traceability of tasks/bugfixes to OLC versions
             • Project / Incident status meetings lack a reliable source of information
           • Incident resolution
             • SNOW tickets abandoned
               • Look into DWS side of the story
             • SNOW incident dashboard doesn't exist
           • Not leveraging existing proven software development methodologies (Agile, Scrum, Waterfall etc.)
         • Different architectural patterns
           • Single Form
             • Single form used for the configuration of all series
             • Integrated Solution Finder
           • Multi-form
             • Multiple forms used for the configuration of a single/multiple series
               • Dramatically increased maintenance and development burden
             • Requires separate Solution Finder
         • Main source of logic
           • Mostly in-form logic
             • Won't work when AEM migrated from on-premises to the cloud
           • clientlibs
             • Outdated ES5 javascript
             • a collection functions scattered in 100s of standalone .js files
           • Complex logic running exclusively client-side
             • Bloated forms
             • Slow forms
     • No testing
       • No Unit Testing of the code
         • Dramatically slows down the development
       • No integration or UI testing
         • No way to test the workflow
       • Every codebase update has a potential to introduce new bugs
         • Ruins user experience & lowers confidence
         • Makes project planning more difficult
         • Potential to miss business opportunities due to delays or mistakes
     • Bare-minimum development environment
       • Not a Node.js environment
         • No ability to run Unit Tests
         • No ability to call functions from other modules
         • No ability to use third-party libraries
       • Vanilla JavaScript
         • No type safety
       • Can't run the code locally
         • clientlibs have to be built and installed on the instance
           • Development is very slow due to constant fix-deploy-fix cycles
         • Can't contribute to the development of OLC Portal
       • No linting or formatting
         • Resulting in very different code formatting styles
         • Trivial bugs introduced which could be spotted by linter
       • No access to server logs
         • Server-side info not visible to the developers
       • Access to the data in CRX is restricted
         • Makes debugging very hard
     • No mechanisms for talent development
       • No training or time dedicated for upskilling
       • No code reviews or pair-programming
         • No regular feedback from more skilled colleagues
         • Stuck doing your own thing to the best of your ability
         • Lack of awareness of bad code / bugs
     • Not utilizing AEM custom components
       • Lack of AEM Forms skills & knowledge
   • Lacking code documentation
     • Implemented functionality is lacking documentation
     • Onboarding of new team members is difficult
     • Cross-SBU collaboration not possible
   • No UI design
     • The need for UI harmonization meetings is a consequence of missing UI design
     • Inconsistent look and feel between SBU OLCs
       • Lead form (MD) to be followed
         • Poor practices
         • Not possible to "follow"
         • MD design is what looks good to them (didn't follow MT guidelines)
   • Requirements are not formally signed off
     • Communicated verbally
     • Communicated via emails or random calls
     • Developers can't refer to requirements documentation
     • No process for requests or validation of requirements