Relationship Development Life Cycle (RDLC)
how to develop a relationship based on software engineering principles
published: , updated:
Note: Design recommended but not limited to teams of 2 members.
Being a software programmer, I have a tendency to follow the development life cycle models in almost anything I do these days. So it did not come as a surprise for me when I realized that development life cycles applied to relationships too.
While seemingly absurd, the idea has some credible applications to its use. Relationships can be dramatically self-balanced if all the resources involved(usually occurring in pairs) adhere to the model set by the development life cycle. Effects such as anger, frustration, failure, etc. which are common in software projects can be dealt here in a similar manner. This variation of applying the software engineering approach is what I term as the Relationship Development Life Cycle(RDLC).
A short walk-through of each stage in the RDLC –
- Planning: The phase where both members plan out the how & when for the coming stages of the life cycle. This usually involves befriending, maximum time spent together, sharing of intimate jokes, occasional flirting and in rare cases – stalking.
- Implementation: The most important tipping point of the project. Estimates indicate that over 90% of relationship projects never make it past this stage. Failure results in outright rejection, proxy wars, hate mails and more commonly, a painfully recurring bug called friend-zone. Relationship projects affected by this bug are estimated to crash about 99% in their life time. The system goes into a self-sustained loop which permanently blocks the development for moving forward. Any activity may crash the system, thereby effectively terminating the viability of the project. One of the members may resolve to taking extreme measures causing system overload and over-heating. Both members are advised to move with extreme caution and prejudice.
- Testing: Once clear of the critical phase, the testing phase is comparably a breeze to get through. Both members are excited over the outcome of the previous stage and work hard towards system stability. Failure rate at this stage can be as low as 0.2%. Although negligence and corruption of disk states can result in the numbers going as high as 15%. The members actively engage in eradicating bugs and work towards achieving high performance.
- Documentation: While not necessary per se, but any sort of documentation actively helps in resolving bugs and conflicts which ultimately increases the morale and provides good environmental conditions for work. The members can keep various kinds of documentations depending on individual ability and need. Most common variations include highly exaggerated team documentation passed between members; commonly referred to as love letters. Enthusiasts also keep a journal or a diarydepicting the project scenario at various points in time. While highly encouraged, thebug list can be daunting if one of the members is averse to it. Interestingly, women have a 85% chance of rejecting the bug list after which the failure rate of the project can increase 70%. For others, total discretion is advised.
- Deployment: Contrary to popular belief, the planning and implementation are one-shot stages in 95% of the projects. The cycle comprises of testing, documenting, deployment and maintenance stages.