Agile Development vs. Object Oriented Design

For this installment in ‘The Adventures of Software Engineering’, we will explore the intricacies of Agile Development and Object Oriented Design. As we compare and contrast the two, the things that make them tick differently, yet end up on the same time at some point, will become evident. The main difference between the two is the process either one employs to get to the end product which is the software. Agile software development encompasses a group of software development methods based on iterative and incremental development; whereas, Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. The main thing to note in these definitions is the fact that one involves planning and the other uses incremental and emergent development strategies.

Agile Design Methods employ some practices and principles which may be frowned upon by other developers who prefer to plan and implement a plan as opposed to ‘coding blindly’. One of which is that design models don’t need to model every single detail. The models don’t need to be perfect, and they don’t need to be complete. This is simply because of the iterative approach employed where no details are being worked with, but rather, they are worked on in tandem with the software product itself. Another is relating to the documentation that is used. Documentation, while important, is not emphasized as it is in the OOD. Instead, unit tests form much of the design documentation.  Now as you develop using agile principles, with no previous document showing a roadmap that could be signed off on by the boss and/or client, feedback is your friend. Whether from co designers or from potential clients, accept the feedback. Because of the iterative nature of the method, you work a bit on requirements, do a bit of analysis, do a bit of design, some coding, some testing, and iterate between these activities as needed.  You will find yourself jumping between tasks and trying to find a balance and ensuring that each dimension meets the standards of its counterparts.

Most of what was mentioned gives the impression of blind coding, which is where so many go wrong in their judgment and analysis of this design methodology. While planning and design for implementation may not be as in-depth as in OOD, its plays a huge part in knowing how to move forward and knowing how to integrate the desired features and requirements into the existing structure. It is critical to think through how you’re going to build something, to actually design it, before you build it.  These design efforts may take the form of a white board sketch; or a simple test that you write before you write business code; or something conjured in a modeling tool. This is very important and needs to be done in short intervals. This means, that this is not something that is just done early in the development stages, but a progressive aspect of the entire development process.

Agile software development methodology is not without fault and it is most certainly without criticism. One such criticism is that it is developer-centric as opposed to user-centric. One claim is agile software development focuses more on the process of getting requirements and developing code than on product design. Another claim is that agile methodologies can be inefficient in large organizations and certain types of projects. They say agile methods seem best for developmental and non-sequential projects and so many organizations believe that agile methodologies are too extreme and adopt a contextually inappropriate hybrid approach that mixes elements of extreme and plan-driven approaches.

Object Oriented Design on the other hand has been touted as the next great advance in software engineering. Its design techniques seeks to reduce development time; reduce the number of resources required to maintain existing applications; increase code reuse, and provide a competitive advantage to organizations that employ it. But before we get into the intricacies of OOD, it is important to understand its foundation which is Object Oriented Programming. Object-oriented programming or OOP for short is a programming paradigm that uses objects, which are instances of a class, consisting of data fields and methods, to design applications and computer programs. Ways of using these classes and their objects are data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. While most, if not all, paradigms employ OOP, OOD uses the classes as the entire building block for the software to be developed. Every method, every data field, every aspect of the software, should be represented by some form of class or object. In the planning stages, a conceptual model is developed which is the result of object-oriented analysis. It seeks to capture concepts in the problem domain. Use cases are also very important as they outline how the different objects will or should respond when given a specific stimulus. This goes hand in hand with a System Sequence Diagram which shows the different methods or each class being called to action as the use cases is being processed. Other documentation will include a user interface mock up and a relational data model describing how data will be used. The one recurring feature so far, is the heap of documentation that is to done before one line of code is written. Having used this method to develop an application (in Java) once before, I actually saw the use of all this initial documentation and feature outlining. It created a clear roadmap and allowed me to develop with vision and purpose. It is noteworthy though, that the amount of time it took me to figure out half of this stuff, I would have already been knee deep in code and working along quite fine.

As with any development technique, there are pitfalls with OOD. One such pitfall is that OOD requires more discipline, management and training than classic software development does. It is argued that the steep learning curve involved with OOD, may not be conducive to the realistic timeline given for a project. This point may not be a sore one, but it points out that OOD is not completely independent, but employs a strategy used by agile methods. That is the iterative analysis and design. The project is prone to change along with the initially developed classes and objects. As a result, each of these aspects needs to be updated accordingly. Class, object and reuse fallacies also exist. The use of inheritance, encapsulation, the relationships between the classes a d the time it takes for the developers to know exactly which class has what function and avoid recreating them inadvertently, all count as downsides to OOD.

At the end of the day, it is as we say in Jamaica, “Six of one, half a dozen of the other”. Either method poses its promises of happy ever afters when used to develop a software, while containing fine print with all possible side effects that may be slightly mentioned as in a heart medication advertisement. The point is, and this is purely my opinion, that a hybrid of these methods would be the best approach to use. Agile is malleable enough to be used in tandem with another plan driven development method and this combination of the two is no different. One provides a clear roadmap that can be used to outline exactly where you want to go, and the other allows you the freedom to get there in fine and unique and even personal style. Merging them would probably make everybody on a development team happy, as that is usually the hardest thing to do from the very onset.

Leave a Reply

Your email address will not be published. Required fields are marked *