Writing code. Most of the time, finding a reason to stay motivated with good attitude is fairly easy – or at least doable.
There are certain times when a good attitude is challenged in a big way. This post is about one of those challenges…working in crappy code.
Here’s how it happens: You start a new job or contract and you are starting to feel a little less like the ‘New Programmer’. You’re in a team meeting. Then it happens. You hear a whispered voice in your ear saying, “You better hope you don’t have to work on XYZ project! That code is crap! It’s had so many hands in it, it’s impossible to maintain.” You know you’ve been told this for a reason – you’re the new person. You end up in that code base.
Today, I will talk about three topics having to do with crappy code:
In the interest of full disclosure, I’m going to make a confession here. I had to work in code that was developed by my own team. I was reviewing the codebase for an app designed by my company. I needed to write up a quote for a feature enhancement. As I scanned more of the classes and methods, I wanted to scream “What were we thinking??” I was in the middle of crappy code and the buck for that stopped with me. How could I have let this happen. The shame of it all.
Then it hit me. I remembered the events that occurred during the development of this particular app, which I will share as part of my confession.
We’d written a significant enterprise mobile app for a manufacturing company. The design incorporated their specific manufacturing system as the data source in the back end. We built the server using Java and developed the iPad client using Sencha Touch.
All of the pieces of the app had fit together extremely well. We were nearly done with development and were expecting a ‘go live’ date in the near future. Instead of a ‘go live’ date, the company went through a significant change and brought in a different manufacturing system as the backbone of their data infrastructure.
The look & feel remained the same, but everything having to with data was different.You’ve seen the pit crew at work during the Indy 500, right? Well, they had nothing on us as we re-plumbed the entire application.
We became app dev speed demons. We bent existing code into pretzels to work with this new database setup. We had a long way to go and a short time to get there (yes, I know that’s from Smokey and the Bandit). Code readability devolved into nothingness with each retrofitting.
Then we were done. We were heros! The app worked. The UX was the same. Users would never see the massive reconstruction that had taken place. We had also accomplished something else… we created crappy code.
This true story is a perfect example of how crappy code is born. The customer thought we were heros for retrofitting their new system into the enterprise app and we sorta thought the same thing. Yet, a year later I looked at the work of heros and thought ‘What were we thinking?!’
Business decisions are seldom based on whether or not the codebase of an application will be forever stigmatized with it’s new status of crappy code. Honestly, the business side doesn’t care what the code looks like as long as the application does what they want it to do and it is done before they finish writing up the requirements, at least it can feel like that.
The CIO, dev manager and programmers care about creating crappy code, but they placate themselves by saying ‘We will come back to that when we have some down time.’ We all know that there is never a down time in software development shops. Hence, crappy code.
Even crappy code was someone’s Great Idea. Every piece of code has a long history that stems from changing business requirements, changing infrastructure, user requests and bug fixes. Of course, when you first lay eyes on your assigned project that includes some crappy code, spaghetti code or whatever you want to call it, you don’t know it’s history. You won’t know that you may be looking at the work of heros!
Of course not all crappy code has such a glorious history. Over time a codebase is affected by changing business requirements, changes in laws, sales ideas that were good (and some that went rogue), user requirements, new features and the list goes on and on. The thing to remember is the crappy code you are looking at could be the result of heros at work!
I’ve contracted and consulted for a long time. Many times i’ve landed feet first in crap code that was built 20 years ago by 20 different people across 20 different sets of changing requirements. I have learned to volunteer for crappy code duty for the following reasons:
I think becoming a crappy code slayer is good for your career. It increases your value and your level of expertise, both of which result in larger income numbers for you.
Don’t even whisper ‘This is total crap code!’ anywhere in the shop. Never insult the code because you don’t know what it’s been through. Oh, and your project full of crappy code just might have been written by heros and one of those heros might be sitting at the desk next to yours.
My advice is to:
People that work in crap code get better projects, along with more money as time goes on. That’s a promise.