Fighting Stagnation: Learning how to grow your skills in a stagnant development environment
Maintaining a legacy application can be a challenge, especially when the team is reluctant to try new techniques. Increment new methodologies gradually so as not to scare off developers stuck in their ways.
“Ugh. This page is written in cfscript. I hate script. From this point forward, I don’t want to see anything you write anything in script. Tags only from now on.”
I’ve been given that directive from my current contract. At the moment, I work for a very small company. There are less than 10 employees total. From a developer standpoint, it’s me, and the owner of the company, who is also a developer. Being the owner, he sets the priorities and he dictates how things get built. He has been developing the company’s primary application for almost 20 years. There’s more work than there is time in the day and we are frequently reacting to the needs of our clients rather than responding to them, which may explain the architecture of the application as it stands. Here’s how the application is built:
- Each page is its own stand-alone template.
- Starts out with <!doctype>
- Has all of the ColdFusion processing, queries, and data manipulation at the top of the page.
- Includes a common “head.cfm” in the head tag.
- Includes a common “header.cfm” at the top of the body tag.
- Has inline code for the display of the page.
- Includes a common “footer.cfm” at the bottom of the body tag.
- Sometimes, reusable code is included using <cfinclude>. Other times it’s not. The same query can exist on multiple pages, hard-coded into the page.
It’s a very “I’m new to ColdFusion” approach to building a website, and the owner himself will admit that he figured out how to solve a problem many years ago, and once he was comfortable with a solution, he implemented the same technique moving forward. He never adopted CFCs. He never tried to implement a framework, or MVC. There’s no real source control. He doesn’t build things as APIs. Welcome to web development circa 2000.
That’s not to say that the work is bad. I actually feel very productive in my contract and I know I bring a lot to the table when it comes to getting the job done quickly, efficiently, and professionally. Sometimes the work can be a pain in the !@#$% because of how it was built, and there has been more than one instance when the words “what the actual f!@# is this?” have been announced out loud; but it is what it is… improving a legacy application is an iterative process. Make improvements where you can.
To that end, the owner/developer hasn’t stopped learning… he’s willing to learn. Years ago, I had a friend tell me that he wanted to find a web development job where he could work flexible hours, remotely, and not have to learn anything new. At all. I just gave up on helping him right then and there. Learning means growth. If you refuse to learn you refuse to grow. My current contract is willing to learn. He’s not as willing to implement different methods of doing things.
Here’s the thing; there’s nothing inherently wrong with an application built like this. It’s more difficult to maintain, and there tends to be a lot of discovery to figure out why something works the way it works, but it’s not wrong to build every page as its own silo, and only using tags. The application works. And it serves thousands of users.
Hearing the owner say that <cfscript> was forbidden made me feel hamstrung. It forces me to develop the application the old fashioned way. During my time as a developer, I’ve heard a lot of “best practice” or “new way” methodologies that I’ve adopted in order to become a better developer. At one point, Ben Forta said “all your queries should be in CFCs moving forward” and at the time (CF 5? CFMX maybe?) it seemed weird and unnecessary. Now I just consider it standard practice.
Enter our previous developer who tried to come in and dramatically change the way everything is built. I swear… this guy bought a book of computing design patterns and flipped it open to a random page each morning and said, “there! This is what we’re implementing today!” He created services, and factories, and beans, and tried to MVC everything, and create service layers and presentation layers, and everything an enterprise application would have by default.
But this isn’t anywhere near the scale of an enterprise application.
The owner couldn’t adapt quickly enough to the changes. The developer ran off on tangents and tried to change the world, and, well… he flew too close to the sun.
I’ve been marginally more successful, and I’ve done so using the following techniques:
- Introduce unfamiliar concepts incrementally and in limited scope.
- Get buy-in on why a different methodology is better.
- Have coding sessions where a very small part of a concept is introduced and explain it every step of the way.
Things are getting better. We’re rolling out some CFC’s… we’re starting to use some different ways to call APIs… <cfscript> is still forbidden, but I’ve seen the owner/developer look at script code and not get frustrated with it any more… so… baby steps.
The important thing is to always be learning, always be willing to listen to different ways of accomplishing tasks, and always be willing to get your feet wet in a new way of coding.