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.

We start a project, without the complete specs for it (of course). We make choices based on an incomplete view of the project. The choices could be whether or not to re-use existing software, which framework to use, or whether a custom framework should be written. Of course somewhere in the middle of the project we start to receive more functionality requirements. We start to patch the software to make it work. We do it again and again. Then we start to reflect on better ways we could have done the project. Better choices that could have been made along the way. We start to wonder how long it would take to rebuild it with our knowledge and the full spec.

Have you ever been in this situation? Depending on the size of the project, it can sometimes be doable and advantageous. The trick of it is sneaking the work past your boss. They never see reducing future work, just that you’re stopping the forward progress to re-code something that was already done.

This is the coding equivalent of cutting your losses and re-investing.

I’m currently in the middle of a large project that would require so much re-tooling it would just not be possible to switch to a more suited framework or methodology. However, had someone six months ago said,  ”go ahead and scrap the current design and do what is right”, it would probably be done now.

In all fairness, it seemed as though the project would be done any day now. With that in mind, what manager would approve even a partial rewrite?

I dug this old post up from a blogspot blog that I have and never use anymore. This was from circa 2004, but still holds true.

I can’t tell you how annoying it is to have advertisements that play any kind of sound when the page loads. These are usually flash advertisements. This is very rude, this is like talking to someone while they are trying to read the newspaper. This gets even worse when the noise coming from the advertisement is some voice over speaking. Please, I did not come to the page to view all the ads, so only speak when asked to. Mute the damn thing by default. Let me un-mute it if I’m interested.
This is a new form of popup, and if your not careful, you’re advertisements, like pop-ups will be disabled with browser plugins or extensions that are already available but not widely used… yet. If such ads were to become annoying enough and numerous enough then you might see browsers including flash and/or ad blocking technology built in. Be cautious with the annoyingness factor of your ads. Be courteous of how you’re perceived or you may be shut off altogether. This goes beyond sound at startup, this advice should be taken for all annoying assuming aspects of the ads. Please don’t pop up floating divs, or expanded flash viewports that must be closed manually. These are other annoying aspects that may be turned off if it persists further. This would mean a shut down of valid browser features for webmasters that deliver wanted content.

In your face sales is annoying. No one likes it.

Webmasters - Demand that your ads adhere to a set of non-annoying guidelines to avoid people leaving your site or blocking your ads altogether.

Marketing guys behind the ads - Adhere to the same guidelines, else you may find yourselves getting blocked completely.

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.