Development Principles in Software Engineering
Continuing on my last blog post, when developing a product, while the methodology and process itself is necessary for organized, on-time, and effective work, there are also various principles and mentalities to keep in mind during the development process. In a field as complex as software engineering, it is often extremely easy to get sidetracked or lose focus, and with these principles that chance is reduced simply by changing your approach. And because these are principles, not strictly confined to software engineering, they can be applied to just about any process requiring problem solving and teamwork to build a product.
One of the more popular principles (or group of principles), is S.O.L.I.D, an acronym that stands for Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. All object-oriented design principles, these 5 principles help create a program that is easy to maintain and meant to last. Single Responsibility states that every module or class should have responsibility for a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class, Open-Closed says that the software should be open to extension but closed to modification, Liskov Substitution means that the inherited class should complement the behavior of the base class, Interface segregation states that the client shouldn’t need to depend on methods it doesn’t use, and Dependency inversion means that the programmer should work at the interface level and not the implementational level. This principle is pretty strictly software-related, but nevertheless there are some more universal ideas within the S.O.L.I.D ideology.
Another pretty well-known principle is the KISS principle, standing for “Keep it Simple, Stupid”. While this has pretty clear applications to any field, it is especially applicable to software engineering. If a developer keeps their code easy while still maintaining functionality, it will make debugging, modifications, and extensions much easier, and it will also make the code easy to read for an external developer. Also, just in general, more complex code leads to more bugs and more errors, so a simple code that still does the job is always preferred. Following the theme of acronyms, YAGNI and DRY are also popular within the software engineering community. YAGNI, standing for “You aren’t gonna need it again,” is meant to deter a developer from trying to implement all the functionality at once at the beginning of the project. A lot of these functionalities might not even be used, and so only implementing what you need and extending it can save a lot of time and effort. DRY stands for “Don’t Repeat Yourself," which is pretty simple and seemingly obvious, but is very helpful. If a developer repeats a piece of code in different places in the program, if any changes are required, then that will subsequently require a lot of time spent changing every repetition and will open the door to a lot of errors if that is done incorrectly.
There are also important development principles for software that are driven by Test, Domain, and Behavior: Test-Driven Development (TDD), Domain-Driven Development (DDD), and Behavior-Driven Development (BDD). TDD relies on requirements being converted to test cases before the software is developed, and tracking all software development by repeatedly testing the software against all test cases, as opposed to developing the software first and creating test cases later. This style really helps with errors and debugging, since major issues can be identified before the software is finalized. DDD is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. Typically, the structure and language of software code (class names, class methods, class variables) should match the business domain- the classes should correspond to parts of the business model. This helps orient the business necessities, keep a common set of terms and definitions, and helps keep track of everything. The last principle of development, BDD, is an Agile (refer to last post) process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It kind of combines ideas from DDD and TDD, but emerged mainly from TDD, to provide teams with shared tools and a shared process to collaborate on development.
The development principles given so far here are all fairly universally applicable, though most effective in a software engineering environment. Whether SOLID, KISS, DRY, YAGNI, or any of the driven development processes, they all hinge on making the work as efficient as possible, conserving time and effort while still delivering a functional product. If these principles aren’t used and developers just rushed into a project head-first, then that puts the team at risk of overly-complicating the work and having to expend a lot of time and effort debugging and simplifying the code.