How NOT to Code
I've been extremely busy this week, so sorry no coding challenges. I'll be starting up again next week. In the mean time, I would like to take a moment to show how bad coding has a hugh impact on an industry and technology. Case in point are the large number of comments written to Kevin Lynch's post earlier this week about the Flash on the iPhone issue.
http://blogs.adobe.com/conversations/2010/02/open_access_to_content_and_app.html
You can see a ton of comments from people who describe their negative experiences with Flash based applications. Their frustration is very clear and it could possibly affect many of us if this continues. ColdFusion faced similar problems back in the 90s. Many early applications written in CF were resource hogs and frankly shouldn't have seen the light of day. Partly as a result, the view of the industry to ColdFusion is pretty negative. I always try to point out that there are badly written PHP, ASP, .NET apps as well and it's easy to blame the language when it's clearly bad coding that is at fault.
Flash has had a similar history from the 'skip-intro' era to designers trying to write apps with the Flash timeline. Flex, I think, has done a lot to help, but there are plenty of examples of badly written Flash based applications to this day. This blog series 'How NOT to Code' is designed to help correct this problem.
Bad code exists. Every language/platform suffers because of it, and I know I may be preaching to the choir with this blog post, but I can't explain how important it is for all of us to help prevent these problems. Here are some basic rules or guidelines I hope you can use.
1. The code is to blame. Bad code simply yields bad results. You can try to blame the issues on the hardware, language, anything. But in 99.9% of the cases I run across, it's simply bad code. Simply put, always accept responsibility if it's your fault.
2. Everyone writes bad code. I do it, you do it. The top gurus do it. We're all human and we all write bad code from time to time. The key is to realize when it happens and to fix it as soon as possible.
3. Test, test, test. Look into unit testing and proper usability testing. Create a procedure to test your applications under load and optimize your code. Remember, fixing a bug after the fact takes far more time and resources and can easily kill your productivity.
4. Never accept subpar performance. This is trickly but it's also vital. You may be doing your best, but all the developers on a team need to be dedicated to the process. Managers also need to understand that sending code out quickly will cost more over time. Take a small amount of additional time to ensure quality. For example, I love watching Gordon Ramsey's Hell's Kitchen and Kitchen Nightmares. You can apply the same principles to any discipline. Quality always comes first, not speed. Once quality is ensured, efficiently will develop in time with experience and under proper management.
5. Know your limits. In many cases, I see the wrong tool being used to addressed a problem or a very first attempt to solve a problem being applied. Let's face it, we all know when we have reached our limits. We copy/paste someone else's code or we struggle to work through the problem. This is the point we can cause the most damage. Make your best first attempt, but don't even think of trying to use it. If you have other team members, have them try to develop their own solutions. Once this first round is done, compare the ways everyone tackled the problem. If you don't have team members, ping a coder list, etc. After the first review, make a second attempt - this should be far better. You may be able to use the second attempt, but I would make a point to comment the code or make a note to revisit the problem in the near future. In many cases, I'll revisit the code 6 weeks later and work up a third solution which will work even better.
6. Always revisit code. Management needs to fully understand that time has to be taken to revisit and refactor code. This is trickly if you spend 80% of your time chasing bugs, but it's vital if you want to reduce the number of problems. When revisiting and refactoring code, it's very important to use unit testing. Fixing a bug or problem that produces more bugs is never a solution.
7. Never write 'large' applications. What do I mean by this? I think most developers mess up here. They get a request to build a large app and things just go down hill from there. Every large application is simply a collection of very small apps or components. That point of view is very important. You want every component of the app to encapsulate itself and to be as autonomous as possible. For example, a shopping cart may have a component that determines the shipping cost. Think of that as a very small shipping cost app that the cart calls. When you develop in this manner, the code becomes more flexible and easier to maintain.
8. Always avoid esoteric code. If only you and god knows and can understand what you coded, you made a big mistake. In 6 weeks, you'll forget what it did as well. This is easy to catch and you should understand it when it happens. It's usually very large procedural code, and it runs through a ton of changes or operations to handle a simple problem. This type of code either contains no comments or is heavily commented as the coder tries to explain the logic. Again, break the code down into its parts and rework it. Compare other people's solutions to the problem.
9. Comment your code, but don't over comment. Some comments are completely superfluous and silly. Well written code reads like a novel to me. Variable and method naming should make sense by itself. It may be slightly more to type but it's well worth the effort.
10. Learn, learn and learn some more. Never become a one language developer. Always try learning new languages each year and how they tackle problems. You'll be surprised how much you get from this. A cool thing about this point is this. You actually learn more from your bad code! When you learn a new language - most of your inital code is bad and you make a ton of mistakes. It's in the process of fixing those mistakes that you learn. That's why as developers become more proficient in a single language their skills may actually drop off over time. They solve the same problems with the same tools and never grow.
