I do not know what brought you here today, but maybe it was that things seem to be getting more expensive time or money-wise with your code. Perhaps it is that things are running slower. It could be that bugs are slowly seeming to be more prevalent, or even that things are getting harder to fix. Whatever the reason, we are going to take a look at 5 very true, happens to everyone, probably should have known better reasons why your code, more likely than not (especially if it is more than a year old) probably sucks rocks.
Let me start out by saying none of these 5 reasons means that you have or are a bad programmer. These are mistakes, but often do not rest of the programmer, and are often related to each other. As a matter of fact, we categorize these problems as “the workload problem.” More often than not, these issues arise because of not enough time, not enough resources, and a need for moving forward fast. So remember that if you identify with these issues, remember to do it better next time, or find the time to correct your course.
If you are a stakeholder in a company, cross-check your developers from time to time to ensure they aren’t making these mistakes. If you are a developer, pay attention, because avoiding these mistakes might just make you the best developer in the room.
Issue #1
The first of our five issues is the “if you do not do it now, you will never do it” issue. This may not sound like an issue, but we call it this because we want people to remember the truth, not the problem itself. The problem comes in many forms, but it usually goes something like this, “I will have to fix that tomorrow.” In comes the truth. If you do not do it now, you will never do it. Tomorrow has its own set of problems, and chances are they are more important than the problem you did not fix yesterday. 300 days of “tomorrow I will fix it” and I can almost guarantee you will have 300 problems. Just remember, if your current self and your future self were two different people – this promise is your current self creating debt with your future self that they can never pay because your past self doesn’t exist anymore.
Issue #2
The second dilemma is that it is often very hard to remember when and where you did something in a specific way. That means as your codebase grows, so do the different ways you attempt to accomplish the same task. It may be a good way to grow and learn, but it is often a trap that makes your code difficult to maintain, and often it becomes impossible to find every instance of a specific way of doing things. This means, that if there is a mistake in how you did something, it can be very difficult to find all the instances of that mistake, making your support a nightmare.
Issue #3
Next, we have the “more important things to do” issue. This in itself leads to issue number one but is also the excuse for never fixing issue one or two. That is the life of a coder – there is ALWAYS something more important to do, until you are done, and you are never done. This issue will often give your brain the excuse to skip over issues when you see them in the code, especially if they are not critical, and move on to the “more important thing” instead of pausing for a moment to document, and review, or fix that known issue. These issues could be anything; bad patterns, bad logic, slow code, easy code to misunderstand, you name it.
Issue #4
Continuing down that vein an important thing to remember, and one of our issues is that good patterns change when better solutions are discovered. That means what used to be good code, might now be bad code, or “worse” code than what it could be, and because of issue number three, you have more important things to do than fix it right now. If you remember the truth in issue number one, if you do not fix it now, you will never fix it.
Issue #5
Our final issue is both a problem done by the developer, and encouraged by the stakeholder. Many times the stakeholder will push – out of necessity many times – to do it faster, cheaper, whatever. I have seen it repeatedly. “We must have this done in two days.” The developer’s ego lights up and says, “I can do this in two days.” I know it well, my ego has screamed that from the mountaintops 100+ times. “Sure I can,” is the mantra of this mistake. Do not believe it. Always ask if there is a right way and a “cheap way,” and most importantly weigh the cost of the cheap way when you keep issue number one and issue number three in mind.
Wrapping Up
From a stakeholder perspective, think about it like this. Software development is directly related to the business process, and often linked directly to profitability in many companies. Stakeholders often do not want to pay for something they perceive should have been “done right” from the beginning. The speed at which stakeholders ask for deliverables can sometimes reinforce bad practices. As a result business demands can overload and prevent developers from “going back” and to make changes to things that are in an acceptable (albeit bad) state, until of course they break.
That is it. Take stock, keep those issues in mind, and while you are writing code, or if you are a stakeholder, while your developers are writing code ask or remind them of these issues. It’s never too late to course correct until it is. You will know when it is too late, and you will not have to ask, trust me. No more money, no more time, no more clients, that is when it is too late, until then the right path is only a few more keystrokes away.
Recent Comments