Should we ever put up with hacking bad code to make it work for right now? Is there such a thing as a temporary solution? Every so often I fight this mentality at work to just patch the code and make it work for right now. The “we need this yesterday” solution without ever thinking about the future consequences of our actions.
As much as I fight against, sometimes I have to do it. I hate, hate, hate hacking something up. I preach the fact that there is nothing more permanent than a temporary solution. I know it’s going to come back to bite me in the ass. The very second a change is wanted it will.
Why do I hate patching the code? I hate it because the blame will later get placed on me for bugs in the software due to design decisions out of my control. I guess I wouldn’t mind making the quick patch as much if later, when bugs are introduced because the code is so very unmaintainable and bugs are introduced with ease, they would take the blame for the issues. But no, it’s now my job to stay late and work harder for shitty decisions made by someone else who was unwilling to take advice, or forced the issue of not worrying about maintenance. God knows I hate more work, tedious work at that, for something that could have been avoided. Should have been avoided, was foreseen and cautions ignored.
You know the kind of code I’m talking about. The kind where you need intimate knowledge of every working part because all the code is so tightly coupled that making one modification means accounting for it in 15 different places or it will break. The kind where we decide that writing out javascript inside a string, passing it into a function, later to eval it is a good thing. See example -> http://club.cmstheme.com/demo100/Interface/templates/Interface/effects.php
So back to the original question. Should we hack it up? I say no. It will come back to bite you in the ass. Almost no one that is asking you to do it understands the implications. They don’t understand that writing bad code is a future of longer development times and is a ticking time bomb. But they will likely blame you when it does break. Of course there will be times when this is unavoidable, but make the best of it and rewrite small sections at a time. Or make the change, but make sure the next time you touch the code that it is understood that re-factoring time is mandatory.

It seems lately that there are a number of OOP “experts” coming out of the woodworks preaching the design pattern goodness. I’m fine with the design patterns, in fact I use them on a day to day basis. It’s the, don’t overuse strategy, that I hate being preached to design pattern beginners. This brings about a fear of using them. I say, “Use them!”. That’s how we learn. Of course we’ll misuse new technologies when we’re learning.

Don’t get me wrong, I’m not saying, “make the solution fit the problem”. That’s not the solution either, but with someone that is new to design patterns, you need to try them in different situations. You need to fuck up for yourself. This is how I learned quite a bit of programming and procedures. Not everything should be learned from what others preach because someone who has a soapbox at the moment says so.

Try implementing in your day to day work. This is what work is for, learning. Your boss may think it’s to get project A done, but he’s wrong. It’s to always learn new skills and evolve. Else he should sit at his typewriter and snail mail his rebuttal. I’ve shoehorned patterns into simplistic problems that could’ve done without a formal OOP pattern. Definitely overkill, but along the way I’ve learned to find a balance that has helped tremendously with larger scale items. It’s like learning algebra for the first time. You may know what 10 – x = 3 is without balancing the equation, but the point is to learn the procedure. So when bigger problems come along that can’t be done in your head, we can use what we’ve learned to solve them.

You can go back and cleanup. Whenever I revisit my code for adding features or fixing bugs, I usually apply what I’ve learned since then and do some spring cleaning.

I was moving the location of the mysql databases on my Ubuntu EC2 instance to an EBS volume. I had a little trouble. Small problem, but eventually found the solution. Did the normal things:

1. Shutdown mysql
2. copied the data files
3. Double checked and fixed as needed the permissions
4. edited the my.cnf to point at the new data location
5. edited the apparmour mysql cnf
6. (the part I forgot) restart apparmour
7. then start up mysql server

I had edited all the proper files. Poured over the permissions. Read the syslog a million times wondering why mysql couldn’t write the file. Finally restarted the apparmour service and voila! Mysql started up without a hitch.

Updated hellaphone. Finally fixed the download button bug. Also a few styling improvements.

The new hellaphone at github can now monitor the queue and updates the progress. More to come soon.

What’s on the immediate horizon:

• Look and feel updates
• Slimming down the code for less to download
• Ability to reorder, pause, and delete from the queue

New release of hellaphone. I scrapped the old code, got rid of cakephp, rolled a lighter, custom framework. Got rid of the installation troublesome mod_rewrite dependancy that cakephp required. I may even end up with a super light MVC after it’s all done. Grab a copy at Github here.

I was getting a new install of hellanzb up and running and noticed that it wouldn’t download the nzb’s from newzbin. I found that the problem was an old uri path in the python scripts. My file was located at /usr/share/python-support/hellanzb/Hellanzb/NewzbinDownloader.py.

Right after the class definition “url” is defined. Just search for v3.newzbin.com/dnzb. Change http://v3.newzbin.com/dnzb to http://v3.newzbin.com/api/dnzb and save. 

I hope this helps out others until hellanzb gets a fix up. I haven’t checked, but this may already be in HEAD.

Can a coder have too high of standards?

I overheard someone say they dislike someone with too high of coding standards. As if this is a major problem!

The reasoning behind this thought process was this: They usually aren’t pragmatic enough to be goal oriented to meet deadlines and are more concerned with technology.

I say, “Bullshit”! These are not mutually exclusive.

• Well written code can help meet deadlines.
• Code that is easier to read always takes less time to add features to.
• Code that is well designed saves time modifying and/or adding features
• Fixing bugs is always easier in well designed code

I’ll concede that the first time something is developed, writing it to be modular and not one off takes a good programmer a little longer. The second time around though that time is made up and then some. Of course this is not an issue if you never have any changes, scope creep, or a boss/client that knows exactly what he wants and specs it out perfectly the first time.

I’ve been in many projects that are rushed and shortcuts were taken. The code is unbearable by all but the original coder. Even he takes awhile to get things done. Not that it’s ever my job, but I always spend the time rewriting reusable, elegant code then documenting it. I always spend more time than I would have if I had just patched it, but I save time for me next time and anyone who must maintain it.

Sometimes the rewriting is pieces at a time. This means making everything backward compatible with what is currently written and being used at the time of being written. As I replace parts of the code, I go back and remove the code that was made backward compatible for the pieces being replaced. Eventually the old unmaintainable code is replaced by lean, easy to read, documented code.

Gotta love this.

Don’t like the php namespace? Here is your solution, especially those of you who don’t have a backslash easily accessible.

Almost as soon as I announce that I was going to stop working on Hellaphone, I start using newsgroups again and start on the project. Partly because I keep getting emailed how to set it up. I didn’t spend any time creating an installer when I released it. In fact I hacked it up real quick to be a single user system.

I always planned on releasing it as a service, but became dis-interested and open sourced it. So now I’m concentrating on bringing the service up again. The project is still open and located at http://code.google.com/p/hellaphone . Check it out, contribute, or just use it.

(Update) There is a newer git repository at http://github.com/buck2769/hellaphone/. This is being actively developed.

Most clients and employers only think about 1-2 days ahead of the project. They want it done now.

“Take shortcuts”, “Fix it later” seem to be their war cry. They fail to remember that they change their minds at least 10 times during the development process. Those shortcuts they made us take, the ones they insisted we take to save a half a days work, they just added 2 – 3 days work of going through dirty code that wasn’t cleaned up or refactored. Let’s go ahead and multiply the time it adds if another developer must be the one to work on it.

Is this the Client’s fault? Partially. We should take some blame here too. We should have an answer or rebuttal why they should not take these shortcuts. We need to be able to convincingly give an argument that supports proper code architecture and design. Why taking the time to create something right is beneficial in the long run.

This is easier said than done. A lot of programmers just aren’t confrontational people, especially with their boss. A lot of bosses are. The boss generally mows them down with phrases like, “it needs to be done yesterday”, and, “We’re losing money by not having this right now”. Unknowingly, they probably put the project behind by not having a plan and enforcing a rush from step to step in the project.

Should you stand up for yourself?

I say, “Absolutely!”. If the man (or woman) in charge is any kind of reasonable, then they will respect your opinions. After all, this is what they hired and continue to pay you for. You will have to sell the reason why you do something, especially when at first glance it seems to take longer than rushing through the project. If you don’t and the project takes too long from you caving in to the pressure of your client, they will only blame you. You will not have any excuses, because theirs will be, “I thought you knew what you were doing”, or, “Why didn’t you tell me that was the wrong way”.

How to avoid being misinterpreted and being looked at like a person who just thrives on arguments.

I don’t know if I can be much help here. I’m always being misinterpreted as I shoot from the hip, rather crudely sometimes. In my old age I’m starting to be a little more manipulative considerate and helping others understand me better. I’m starting to reflect more on what I can do to ultimately get the job done. This means being able to identify the feature and benefits of proper development procedures. Identify how it will either make life easier or make the person more money. This can be by cutting future development costs (future can be within the same project when the client changes his mind) or by creating a better product due to the extra time you’ll have not sorting through the undocumented spaghetti code you wrote just 3 weeks ago.

Unfortunately, sometimes standing up for yourself or telling the client no will ultimately lead to a dismissal of your services. Whether it be an employer or a client, these things can happen. You need to decide what your limit is, and whether it’s for the best. I’ve always felt that most clients must be saved from their ignorance.

HellaNZB.com linked me up on their home page and I’ve started to receive a lot of interest in HellaPhone. I’ve decided to make some time to further complete HellaPhone and add functionality that I wanted. Since I created HellaPhone a few things have changed. The most important one is the introduction of iui. This will help greatly in bringing some interface improvements that I wanted to do the first time around.

I plan on adding live monitoring for the downloads and queues of HellaNZB. That is my primary goal. At some point in the future I would like to be able to support all mobile devices, but I don’t have the time nor the equipment to test with at the moment.

If anyone has any suggestions or features they would like to see, please drop me a line and let me know.

I logged into Zecco yesterday and noticed the site was broke. I was using Safari. The layout looked a little different (Most of it was broke), so I tried opening it in Firefox. Aha! It works, and it had been changed. I sent a nice email off to a contact person listed on the Zecco.com site.

The new layout is horrible for Safari. I haven’t tried it on my iphone yet, but it’s probably pretty similar.

Ok, so maybe not terribly nice, but as you can see from the screenshots, not un-truthful either. The following reply I received surprised the hell out of me.

Hello Buckley,

Let me start with the short answer: Zecco does not support Safari. The reason is this:

Zecco supports the following four dominant OS/Browser combinations:
Windows + IE6
Windows + IE7
Windows + Firefox
Mac + Firefox

We have tried to also support other (Mac) browsers, like Safari and Camino for instance. However, optimizing HTML code for these often means sub optimization for the four dominant OS/Browser combinations.

So please switch to Mac + Firefox.

Hope that helps. Thanks,

Zecco Editor

PS: I am a Mac and iPhone user too.

What really surprises me is that this is a fairly large broker who depends on it’s website for it’s business. We’re not talking about some small, short sighted “web development” house that is just ignoring a large portion of mac users.

It’s really a shame these days to not be cross browser. It’s one thing to not support some weird, hardly used browser, but Safari makes up most of the Mac users. The worst part is that it easier to develop for Safari and Firefox and gracefully degrade for IE. They support Firefox, but can’t make the layout work with Safari?

On the mobile front it’s worse now the iPhone is out. This is the most capable browser on a mobile phone. Before you Google geeks scoff, android uses webkit, as does Nokia highends.

It also says they support the four dominant browsers [used on their site]. Of course Safari will not show up there, it doesn’t work! How about, use web standards that degrade gracefully for stupid browsers (IE) instead of “optimizing” (whatever that means in his terms).

With that same type of thinking we as a society would not have anything new. Could you see any would be car company at the turn of the 20th century creating a new product and investing the time and money to sell it when no one was using cars. Of course no one was using cars, there weren’t any available yet.

It’s this kinda of reasoning that should be illegal for accessibility’s sake. It’s this sort of reasoning that keeps a 6 year old browser in the mainstream. No one wants to switch to a better browser when developers aren’t whole-heartedly supporting newer technologies. When I say newer, I mean 3-4 years old. When moron web developers who don’t know how to create a cross browser site, they encourage moron, Microsoft Systems Admins to discourage anything other than IE for their users just because they like to use a site made by inept web developers.

I’m surprised by this attitude mainly because the company runs like a web 2.0 company. They don’t charge for standard trades and they make their money on advertising and premium services. Hell, they even have a social networking section with an investing twist. Maybe I can help make enough waves to change this deficiency in the Zecco.com website.

HellaPhone 

I currently use hellanzb for all of my usenet downloads. It’s much simpler than anything I have used before and is a simple install. Very simple if you are on a Debian (Ubuntu), or Darwin System (Mac OS X).I developed this interface for my own personal use and nothing more. That being said, there is very little error checking if any, and even less error reporting in the interface. I planned on releasing this when it is more complete, but I have not had the time to spend on it due to other projects that put food on my table. The app does work pretty well for a quick newzbin search and download to your existing hellanzb install. It just doesn’t monitor the downloads or report an error if the download doesn’t initiate. I planned on rectifying that at some future date.The requirements are:

•  php5
• cakephp 1.2.x
• allow_url_open – (maybe, I may have changed it to curl, can’t remember, don’t care)
• hellanzb install with allowed network access
• newzbin account

If enough people show interest I may make time to work on it some more. Please, if you are interested in upgrading or continuing work on this project, Leave it in the comments. And of course donations are always welcome. Download from the HellaPhone page  Some screenshots