Congratulations on your new job! You are the master of the coding universe and you are going to show everyone that you are the ultimate truth. The first day of your new job and you stroll into the office, strutting with your shimmering Starbucks mug, trendy new clothes and carrying your new laptop that could whip anybody. You sit down and fire up the PC and login for the first time to the codebase that will become your new digs. After booting up you look over your various accounts, check to make sure your email works and everything is running smooth. Finally you get into the codebase and suddenly your perception of what hell could be comes to reality.
“I must be in the wrong codebase. This is a hot established company and yet I am seeing code here that makes me cringe! Where am I going to start? I can see 10 bad coding practices in the first function alone. This may be a bit more tedious than I thought!”
This type of thing happens all the time. Industry code can get messy and often times the longer the company has been around, the messier it gets. Often times the code is a reflection of the internal health of a company… its foundation if you will. While a company may have a wicked marketing team that makes the company look really hot on the outside, they can’t hide the code that makes up some of the company’s soul. Obviously no company is perfect and legacy code often becomes a reality at some point. But even new code can be fraught with danger that “may work” but also contain a dozen hidden bugs that just haven’t been found yet. A house of cards that could crumble down in any minute due to a hacker or rogue program etc.
So how should you go about fixing all this stuff up and make a good impression? Or should you even try? I am a firm believer that you should try to make every effort you can to clean things up in a company even if your efforts will never be seen on the face of the company. The work you do to streamline code, remove potential problems, sniff out code smells and squash nasty bugs will reap benefits for the company in the future. They may become more productive, they may be able to become more flexible (such as being able to interface with new APIs or services they couldn’t before) and all that will eventually filter to the bottom line… the dollar value that your company’s senior management gawks at. If you are lucky, they will ask why the sudden decrease in costs to know what they are doing right. Hopefully that investigation will lead back to you and your group. Programmers are not a cost center! They can be revenue generators! Here are some of the steps I use to work through company code and make the world a better place.
1) Identify what can be done quickly and with the most immediate impact. This usually means, look for lines you can cut out to gain an immediate speed boost. If you see useless lines of code that you know are not doing anything, cut them. The goal here is to cut the codebase down so that the next steps are just easier to do. It is much easier to correct and clean up 10,000 lines of code than 100k. The immediate impact will also be seen by your superiors and they will gain confidence in you that you are contributing to the company rather than sitting there tinkering with syntax they see as little consequence. After all, it was probably bad tinkering that lead to the bad programming to begin with. More trust means more leeway in letting you do the remaining steps. Just don’t forget to retest after cutting the fat.
2) Simplify and Refactor. Out of the remaining lines that made it past step 1, can we simplify any syntax through a quick refactor? Look for patterns. Do we see any functions that seem to repeat what another function is doing? Do we see long nasty 200 line functions that do nothing but a task over and over with just a different element? Can we loop it or use a collection or an array to cut those 200 lines down to 10? Could we use a simple function from the Coders Lexicon Code Library?
3) Increase readability. Sometimes this might be step 2 instead of step 3 depending on the number of lines you are dealing with and the relative shape it is in. Step 2 above may cut your lines down further and it would be easier to rename variables or classes after that. However, it might be step 3 if the lines of code are either small or terribly complex where renaming would help you understand what is going on first before attempting to simplify. Switch these two steps at your discretion.
4) Reduce number of steps in the process (aka streamlining processes). Now that you have cut the lines down, simplified the remaining lines and renamed everything to be easier to read, you can get to the point where you will see how tasks are being done. Are there too many steps to accomplish a simple task? Here we are looking to cut out steps and make things more straight forward. Can you cut out the middle man and have something done quicker? Are they still looping through the entire array to find the value instead of bailing the loop when the answer is initially found? This step may require you to talk with fellow programmers to ask why something has to be done that way. There might be a business case around why something is done the “long way”. 9 times out of 10 though you will find out that it had to be done that way because of either the bad programming you eliminated or the programmer who wrote it first was under a tight deadline.
5) Document everything. Yeah yeah, we know you hate documentation. That is why you should do little bits as you go through steps 1 – 4. At this stage you can write comments (or full documentation guides) on why you made various changes or showing improved results from your testing. You need some firepower to show to your superiors. Remember, you should ALWAYS tie your decisions back to the bottom line.
Always keep in mind that while you are doing the company a service they may never thank you for, you are indeed helping the company do things better and produce higher quality products and services. This will lead to more sales (or reduced operating costs) which is a thing the CEO understands. It also makes you and your team more responsive to changes in the future. “You want me to hook our code into this new API? No problem, we can do that and have it ready in 2 days.” This is the type of stuff that leads to promotions. Besides, you will save your sanity and not have to stare at disastrous code day after day that you hope is working.
Lastly, the most important tip of them all (which I eluded to in step 5 above), always tie your changes to results. Most likely senior management are business guys and they look at numbers and charts. They really don’t care that you cut a function down from 100 lines to 2. They do care to see that because of the change the program is 10% faster and uses 30% less resources translating to $100k more a month in sales. Don’t be surprised if they start calling you their “rock star” programmer.
Thanks for reading! 🙂
