Architects vs Developers: Theory vs. Practice? April 15
I have always fallen on the practical side of technical architecture. I think it is because I started my professional life as a developer and have evolved into more of an architectural role on the projects I work on. I have worked with many architects over the years, though, I’m not sure where their background lies as most of them seem to fall more on the theoretical side of the fence. It isn’t too often I run across a so-called architect who has the practical side of software down also.
These theory architects are good at writing documents and drawing pictures, and they even have some really great ideas. The downside of these theoretical architects have, is that though they tend to do a lot of research and generally know what all the best practices are, they don’t generally get down and dirty with the tool set and thus don’t know what the real or potential problems are with some of the practices that they suggest. If there isn’t someone involved in the design who is fluent in the toolset, you could waste a lot of time trying to implement something that isn’t going to work or even just making a lot of small changes that aren’t going to matter in the overall scheme of things.
Regarding this point, I was involved in an interesting conversation with a technical architect on a client’s project recently. This architect is a great guy and in general I respect his opinions and suggestions much more than I generally do when dealing with architect types. However, this time, his tendency to constantly push theoretical best practices over practical approaches was apparent to me and even the client.
In creating an ADF BC layer in JDeveloper, a developer will typically, no always, use the wizard included in JDevleoper (unless, of course, they are using Evo). The way the BC layer is defined, various Entities xml files are created from tables in the database and views are built from those entities. Finally, in what is called an Application Module, the Views are used by defining instances of those views for use in the module. Since these view instances are generated automatically, each view instance has a number appended to it to make it unique. Makes sense, right?
Well, this architect said that it was a “best practice” rename those instance variables into something more meaningful. Now while I agree that it may be nice to rename some of those instance vairables to be something more meaningful, is it really practical, and thus is it really a “best practice” or is it just a good idea?
I interjected that though it may be a good idea, it hardly seemed practical, afterall, if JDeveloper automatically generates the instance names, don’t you lose some of the benefit of the automatic generation when you need to go back and rename all of those instances? At this point, the client joined in the converstation and asked if he had used this best practice in the past.
The architect replied that it is always a best practice to rename files or variables such as those so that the names have meaning. The client asked again, “yes, but do people actually do that in a project? Have you worked on a project in which that was done?”
The architect, much to my surprise, replied with, “well, to tell you the truth, I have never actually seen it done.” I actually had to laugh a little bit. It was actually refreshing to hear an architect say that though something was theoretically a best practice, in reality, it wasn’t done because it wasn’t practical. In a lot of organizations, practicality often loses out to so-called “best practices” many a time. The funny thing was, that in this project, it actually made sense to name our view instances as he suggested, but only because the tool we were using, Evo, would be automatically generating the instance names.
Maybe this article was just an excuse to print one of my favorite Yogi Berra quotes, “In theory, there is no difference between theory and practice. In practice, there is.”