I have a lot of things on my mind this issue. Rather than focus on one central concept though, I'm going to muse about some of those things buried deep in my cerebral cortex.

The Code is the Documentation

In my NOV/DEC 2014 editorial, I wrote about learning from mistakes. The basis of that editorial dealt with going “off the rails” when working on a large-scale payment processing system.

The principle task was to take an existing payment-processing application (built for another department) and incorporate an existing set of business rules and processes into it. The existing business rules and processes were to be derived from existing documentation.

This was one place where we went astray. You see, the documentation, written over numerous years by numerous authors (queue Shakespeare joke here) was woefully inadequate. When looking closer, we found numerous inconsistencies, ambiguities, and other documentation issues. As we all know, trying to keep paper documentation in sync with application code is difficult and arguably impossible. This is why the principle “The code IS the documentation” is so true. After realizing our mistake, we started examining the existing code more closely to insure that the new code properly reflected the current business realities. The biggest takeaway was for next time: When rebuilding code, it's paramount to look at both the documentation AND the existing code.

Sometimes You Need to Venture Out

I have been a polyglot (knowing or using several languages) for many years now. My career started with the FoxPro/XBase language and has steadily expanded to include: include Visual Basic, C#, JavaScript, HTML, CSS, and Ruby. Along with these languages, I've also used a lot of frameworks and toolsets. These toolsets have included: WinForms, WebForms, ASP/MVC, Ruby on Rails, Nhibernate, Entity Framework, Bootstrap, WordPress, and many others.

There's a major benefit to knowing and, more importantly, actually using multiple frameworks: being an informed developer. When building applications, each framework presents its own set of unique costs and benefits. If you're using a framework properly, you quickly learn what it's good at and what it's not so good at. As an example: ASP/MVC does a good job managing Controllers and Views (the VC part of the MVC pattern) and falls flat in the area of Models. Now, contrast this with Ruby on Rails. Ruby on Rails has a great Model story with its ActiveRecord implementation. While not perfect, ActiveRecord does a pretty good job managing data interactions.

I like using this comparison as an example to show how using one framework informs developing with another. Taking the great concepts from ActiveRecord and moving them into ASP/MVC allows me to create a best�of-both-worlds situation.

Getting Off the Bleeding Edge

“Venturing Out” has another added benefit. While I was off in Ruby on Rails Land, ASP/MVC and other technologies I'd been “knee deep” in kept moving forward. Upon returning to ASP/MVC, applications were more maintainable, had better structure, and incorporated some very useful features. It took some time to become familiar with the new structure, but when I did, it became clear that this framework had really moved along over the years.

Contrast this with Ruby on Rails. This framework has the development velocity of a speeding comet. A “benefit” of the 3.0 Ruby on Rails re-architecture was the ability to make sweeping changes in a rapid fashion. The core Rails team has lived up to that promise.

As a line of business developer, I've found it difficult to keep up with the velocity of Ruby on Rails. Developers were faced with numerous cost/benefit calculations on a daily basis, especially when adopting technologies. The main question in this equation is: What's the long term cost of using this feature? Should I adopt CoffeeScript? What about Turbolinks? What about the asset pipeline?

Each edition of Ruby on Rails seems to pose these questions and in my estimation, it's a very costly calculation every time a new technology is introduced.

I've used my “Getting Off the Bleeding Edge” concept when it comes to Ruby on Rails. I stick to the basic concepts and slowly introduce new technologies when they seem to be “winning” in the developer space. Picking a winner is a bit of an art. You need to be plugged into the development community and see what people are writing about. You also need to carefully weigh the cost/benefit. To further explore cost/benefit analysis, take a look at the editorial John Petersen and I wrote in the SEP/OCT 2014 issue of CODE Magazine.

Thanks for Venturing with Me!

The world of software is a great place to work and we're in an ever-changing landscape. If you're like me, you probably face similar problems and ask similar questions. I'd love to hear from you about the things concerning you today.

Thanks for wandering with me!

Rodman