R2R journey and its problems
The journey from requirements to release (R2R) consists of 3 major phases. Design, Develop and Deploy (3D). There exists no clear distinction when one phase ends and the next starts. All three phases need to go in parallel to continuously build upon a starting seed idea to get a final end product. But, frequently changing design impacts the development phase leading to developer fatigue and hence to bad and buggy code. On the other hand designers need to wait a long time before seeing their design working and hence having to come back and recall designs to make corrections and modifications. This leads to loss of the thread of thought and hence missed opportunities of forgotten designs.
A number of SDLC processes has been followed starting from waterfall model to agile methodologies to overcome these problems. Yet one or the other major drawbacks still exist in each methodology. The waterfall model forces designers to to know all the requirements and think through all the scenarios, before development begins. It is obviously not practical to know all the scenarios unless a working product is tested hands on. The agile methodology tried to overcome this by designing small pieces at a time. But this has introduced the problem of “No vision”. The designs have become too fragmented and a lot of rewrites and redesigns have been introduced.
On the whole, having a feature development cycle that is stretched by manual coding and mired with human made errors, is detrimental to the product.
What is needed?
What is really needed, is to reduce the 3 major phases to just 2 major phases. Design and Deploy (2D). Development NEEDS to be incidental and code be easily created from the design in the shortest possible time. The agile methodology works only if design and coding can go hand in hand without delays and without having to compensate for communication failures between developers and designers. The current implementations of the agile methodology is stretched to a 2-week cycle and driven by the speed and understanding of the developer. Higher the speed and better the understanding of the developer, easier it is to pivot the design as required.
On the surface, while design and develop seem to be different phases, they actually are just one phase. They are split into two phases either because the designers do not code (differing skill sets) or the designers are too experienced to want to spend time writing and debugging no-brainer code and getting dragged into the nitty-gritty of low-level coding that any fresher can do. The developers themselves are either inexperienced or know zero about the domain to be able to design to requirements. Code generation solves such problems, but the amount of code generation currently implemented is limited to POJOs or database saves that emulate a certain pattern pre-thought out by the technical designer or supported by IDEs.
The NEED of the hour is a tool that allows continuous incremental cycle of design. In a continuous incremental cycle, the designer must be able to design functionality, generate code, test functionality, adjust design, generate code, test functionality and so cycle over and over again, till the final design is agreed upon. Once the design is finalised, the final code can be generated and pushed to production. PoC It provides just this. Model your designs and UIs, deploy and test and incrementally change the design to get to the final state.
How is it done?
Central to all applications is “business data”. For eg., in a e-commerce application “Product” is a business data, “shopping cart” is a business data, in a order management system “Order” is business data. Business data has various states. For eg., in the e-commerce application “shopping cart” can be in “empty”, “items added” or “checking out” and so on statuses, in the OMS system, Order can be in “order placed”, “paid”, “in transit” and so on statuses.
Different business transactions and events occur on these business data based on their states. In the e-commerce system, “Check Out” event cannot occur when the “Shopping Cart” data is in the empty status, in the OMS system “Cancel Order” is an event and can occur at any states of the object.
PoC It allows you to model these business data, business events and finite state machine for each business data. Along with the state machine, PoC It also allows you to specify which event occurs at what state and what must happen when the event occurs. Once modelled, code can be generated. This generates POJOs for business data and events. Events are exposed as REST API with JSON communication formats which can be called from your UI.
PoC it is backed by a server that inherently supports a lego block architecture. This architecture fits multiple pieces of code like pieces of a puzzle to form a bigger logic that helps process requests. So, generation and deployment of of simple POJOs achieves a lot in the server. The server is able to weave around these POJOs a number of complex functionality using state machines and LEGO block architectures.
UI pages can be designed with the inbuilt UI designer that uses Polymer and material design. These UI pages can then call the REST APIs generated from the previous business event models.
Published on Java Code Geeks with permission by Raji Sankar, partner at our JCG program. See the original article here: Requirements to Release (R2R) Opinions expressed by Java Code Geeks contributors are their own. |
