Wow. There are moments in life when you think you know everything. These moments are inevitably followed by moments where you realize how little you actually know. Before it became a cheap buzzword, this was called a “paradigm shift”.
I haven’t written a post in over two months. I’ve been more obsessed than usual in the past few weeks with work, both on a professional and a personal level. In my new position, I’ve been tasked with the construction of a framework library using .NET 2.0 that supports the development of new applications, as well as seamlessly integrating them with the existing legacy code. It’s our hope that the framework will be used in all new development efforts throughout the engineering division, so as a result, I’m also doing my best to evangelize the framework and the ideas contained therein.
In order to better understand what’s required, I’ve been “deconstructing” the source from any framework-type project that I can get my hands on, including Spring.NET, CSLA.NET, the Castle Project, the Enterprise Library, and ObjectBuilder. As a result, I’m doing my best to absorb a very large amount of information. I’ve been exposed to a lot of new ideas in terms of software development, and I’ve undergone a major paradigm shift. Inversion of control, dependency injection, aspect-oriented programming, configuration-driven development, test-driven development, domain-driven design, loose coupling via interfaces, the list goes on and on.
I think every developer goes through a series of paradigm shifts as they gain experience. In high school, I was satisfied when I used a pointer in C and my program didn’t crash. (Although, as I recall, I didn’t quite understand the difference between the
** operators.) In college, I was satisfied when my program would compile and fulfill the predetermined requirements in the assignment. In my first job, I was satisfied when my program made the client happy and it was deployed and used in the field without too many support calls.
It’s funny, because at each juncture I was certain that I understood how software was written. I’ve always been aware that I was learning new things (and I’ve always been obsessive about finding new things to learn). But it’s only now that I’m coming to understand that it’s not only new technologies that we as developers need to learn. We also have to keep abreast of new ideas and methodologies, and challenge the way that we write software to become better at what we do. We can’t fall into the common trap of saying “it’s always been done this way, so that must be the way it’s done.” To the contrary, we have to constantly ask, “why is it done this way?” and “how could I improve the way we do things?”
I have a great opportunity at my new job to play the role of “architect” and help bring these new ideas to the other developers at the company. I hope to also write about them here, including our successes and failures in using them. (First I need to stop being so obsessed about work!)