SDLC or the software development life cycle is the different phases that is present in the development an entire application (any type, web, server, mobile) from requirements to release and continues further into a continuous maintenance phase. Many SDLC processes exists such as the waterfall, iterative, spiral, agile, lean, dev ops and so on methodologies. Each of them come with their own advantages and disadvantages. The waterfall methodology is very strict and does not take into consideration the fact that requirements cannot be known upfront. Requirements change as understanding of the problem evolves, hence it is not possible to design everything at one go before starting development. The iterative process tries to fix this, but the cost of fixing becomes pretty high. The agile tends to fix this to an extent by designing for what we know as the requirements now and adjusting them appropriately as we go further, but this leads to too fragmented design which cannot be easily fixed if a developer is not willing to re-write code when a re-write is warranted.
Over time two core conflicting problems have emerged that erode software processes. The first is “Requirements change.” and the second is “Designers and developers are human and always tend to oppose change, especially fast changes.” Why are these conflicting? Requirements drive design and design drives development. If requirements change often, design changes and hence should development. Since designers and developers are opposed to frequent changes they tend to do a patch work to make it work for this instance and hence what we end up having is a product with a lot of patchworks even in the beginning of the program being written.
So while the waterfall, iterative or the spiral models had a high cost of correction, the product written in the beginning was with lesser patch work and optimized enough to atleast sustain and be maintained for a few years of rough handling. But, with agile method, the first version of the product that comes out is already a patchwork that the sustenance of the product is in question from the day it is released!
While the agile is good for enhancements and bug fixes, trying to adopt it for a product development from scratch has done more harm than good. We cannot start with a backlog of features to develop when we are developing a new product. We have to start with a initial base set of features to first design, around which other features need to be added. Agile with it’s backlog and 2 week or a fixed short time stories and epics surely has fixed the “Requirements change.” problem, has put the lime light on the second more serious problem “Designers and developers tend to oppose change”. A new product cannot be broken down into stories and epics that can fit the short time frame of development! This has led us to develop eroded products even in the first version.
Looking at the problems that we are faced with, it is pretty clear that we cannot do away with the problem of “Requirement change.” It does not matter what. Requirements change as understanding changes and understanding only comes as time passes and we are able to get our hands around some concretely working piece of software. That leads us to the second problem. So, how do we fix the problem of an underlying human tendency to oppose fast changes?
I believe the fix can only be found if the underlying reason for the opposition to the change is understood. Products tend to have large modules each having unwieldy designs interacting with each other in a network of interactions that remembering all the modules and their interactions off the top of the head is very difficult. Design documents exist but with changing requirements these tend to get out of date and cannot be relied upon. Hence while changes in the beginning of a product development phase will be welcome and done fast, as the product development has progressed, the impact of even small changes becomes difficult to analyze. While in a waterfall model, where bigger chunks are grouped to be developed, the impact can be easily arrived up by looking up the bigger chunks, the agile with its short stories and incremental changes added along the way, the impact of a change is very difficult to analyze and pin point all places of propagation of a change.
This can only be fixed if there exists a snapshot of the accurate existing functionality as of now which always tends only to be the code. So, can we use code or the current product version to detect impact of change. This can only be done if design directly translates to code without manual intervention or in other words code generation. If we have a system that can use design as input to generate code, then changing latest design changes code before deployment without any doubt of missed points.
In other words, we need to remove the unnecessary waste that is present in product development of typing in code for a design. The advantages that this gives us is many fold. The tedious step of converting design to code is totally avoided ensuring opposition to change is minimized completely.
The requirement of a project manager with statuses to track a single product or project development is totally done away with, and only project management between various projects is needed and only needed during implementation time. Quality assurance is only needed to test code generation accuracy, once done, testing can be automated. Customizations for customers can be a regeneration of code based on incremental design insertions for the given customer. The advantages of such a method of developing a product is many as opposed to the single disadvantage of “It takes time and effort to build such a code generator”. This is the what is provided by pocit.online. Try it here.
Published on Java Code Geeks with permission by Raji Sankar, partner at our JCG program. See the original article here: The eroding of the product developed Opinions expressed by Java Code Geeks contributors are their own. |
In my opinion a new project should always start with a solid design using the traditional SDLC process, and during the design phase the requirements should be validated with business users and changes should be made alliteratively before the development phase starts. Agile is good for maintenance purposes and for short projects. Large projects cannot be done without a solid design in place including documentation.