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.

Isn’t it funny how everyone has a good idea for a website/service that will make money?

Does this ever happen to you?

Every now and then one of my friends or colleagues gives me a call with a new idea for a website or service to offer. They call with excitement and a tone of voice that sounds like they believe they’ll be rich soon. They never do any due diligence to see if the same exact service or niche is already being filled. Even when their idea is unique that seems to be all they want to do, tell me the idea. Tell me the idea and collect some sort of paycheck for basically doing nothing but talking to me like a lush would to a buddy during a long night out.

It’s a real shame too, some of these ideas are genuinely good. Unfortunately, I only have so much time. I usually require them to do some leg work.

• Something like research what other services are out there that compete or are related. Make a list. 
• Define an initial feature set.
• Brainstorm our business model.
• Define costs
• Brainstorm marketing ideas

Most people never get past step one. This weeds out the majority. Some will actually define a feature set, but then tend to drop off past the business model. Defining costs almost always loses everyone else.

I may start giving quotes to these people with the ideas, but that would require more questions that they probably wouldn’t ever get back to me on.

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.

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.