Every field of engineering has a core set of practices that they follow and software engineering is no different. But what are they?
The answer seems to depend upon who you ask. There is no overall consensus in our field about what the right standards and practices should be. We have many languages, many frameworks, and many programming paradigms to draw from. Part of the reason for this is that we use software for many different reasons. The tools and techniques that you use for simulating physical properties such as gravity a very different from the techniques you use when constructing an accounting system. Yes, there are some fundamentals that most problems have in common but there are also differences. So, what are those fundamentals?
I’ve written a lot about some of the fundamental practices that I’ve learned which have helped me and others as software developers but there is so much more yet to be discovered. The way we build software today is radically different than the way we build software in the 1990s. Sometimes progress seems gradual when you’re in the middle of it but looking back we see that the prior generation of software development was very different than how we build software today.
Incremental software development where we build features in iterations and emerge our designs as we go has proven itself to me to be an efficient way of building software and produces a far better end result that’s more maintainable and costs far less to extend later. This should be the real goal of software development, to build software that’s resilient and extensible. It’s not enough just to make the computer do something if the way we do this makes it difficult to change later.
Procedural code like the kind I used to build 30 years ago in C, Fortran, and Basic was mostly unencapsulated. Every subroutine shares data from a common source and this is manageable for the small kinds of systems that I was building three decades ago. But building an enterprise system in this way can become a nightmare. This is why we’ve moved to the object-oriented paradigm. We can more accurately and completely encapsulate processes and we can use that to minimize the impact of future change in a system if we understand that that’s the purpose of building systems in this way.
Object-oriented programming is a magic key that gives us this rarefied gift of extensibility but only if we use it correctly. We must take that key and apply it to unlock the tight bonds of coupling in our systems because the root of all software problems can be seen as coupling issues.
Building decoupled systems is both an art and a science. It involves a series of technical skills as well as a strong design sensibility. We have to be able to apply logic as well as abstraction, the two fundamental processes in human thought. Object-oriented programming gives us a development paradigm where we can model anything that we can imagine and name.
All of the developer practices that I advocate help us more accurately create models that represent the domain that we are working in. As I often say in my software design classes, if I only had to give you one piece of advice for developing extensible, resilient systems it would be this: create your designs to reflect the nature of the problem as accurately as possible by building a detailed and consistent domain model. That means that all the concepts, ideas, and entities in the problem domain are represented in separate classes in your domain model. This is how we build robust software and when you follow this advice it can help you discover many of the core developer practices.
Previous Post: « SO what?
Next Post: Makers and Menders »