Down economies and mergers tend to make people crazy.  They panic and fret over what’s going to happen to them.  How are they going to find another job and pay their bills.  Its a hard reality, but it is only part of the situation.

The company a friend (George) works for was just sold.  His coworkers are upset about what’s going on.  He has taken a very different and commendable attitude.  He sees it as an opportunity.  The company has given them warning that things might change in the future.  It would be foolish to think that things won’t change. 

George feels this is his time to shine.  With others fretting, he’s updated his resume, started blogging, and learning some new techniques and skills.  His feeling is that either he will become a bigger asset to the company or he will already be more valuable as a job candidate. 

It is work, but George is already ahead of the curve with his attitude. 

Forcing a new system and/or procedure on users is never a good or fun thing, but sometimes it is necessary to make the process easier and ensure consistency.

We have a client that has very specific needs when it comes to reporting. Their report is very different than anyone else’s that is generated. It always is a cause for confusion, delay, and concern for consistency and accuracy. My management, like other management teams, doesn’t want to spend too much resources developing small “outside” projects. I don’t blame them, the list of projects for my team is long.

I talked to my boss and explained what was going on. I explained to her that the value of doing such a project long and short term was that it would speed up the process immensely and ensure that the report was generated exactly the same way every time. She liked the idea, but was concerned about the time taken away from other projects. I had her sold on it, but she was concerned about the time. This is when I pulled the switchero.

I had already done the research and had most of a working concept done. I just need the stamp of approval to finish and roll it out. I had just received it. She loved my initiative and the fact that it had not slowed down anything else, as I did it over a period of time when I need a break from other projects.

Essentially I had pushed a system by building it before asking permission. It was a risk, but I knew it had great advantages to the company and to the user who generates the reports.

Sometimes a calculated risk is worth the effort.

Hey Gina, Lifehacker talked about managing your online reputation the other day.  I have a bone to pick with you…

Jeff Atwood recently talked about Curly’s law of doing just one thing. He’s talking about simplifying your code so that it does just one thing. You can take it even one step further and know when you need to refactor and abstract your code. If you find yourself copying and pasting code from one section of code to another, then stop. If you had to do that, then you should create a new class or function that duplicates that code. You will save yourself a world of support headaches in the future.

Technorati Tags: Development, Code reuse, coding, design, refactoring, copy and paste

I just came back from a meeting with a potential customer. The project was typical of his industry. Automate their process and link it with their client database. Seems pretty straightforward. Then he brought up an ugly point. The original developer of his client management database encrypted the database and refused to give him the passkey to it. Thus any time changes are required of the application, they need to go back to the original developer.

I have seen/heard this before and can see why a developer might be tempted to do this: job security. Is it though? It is extremely short sighted and creates bad feelings on behalf of the customer. They paid all this money to have the application made and yet they do not have control over the application. It’s your ball of wax, you can use it but you need to come see me and pay me to get it.

They are valid cases to encrypt code, its a shrink wrapped application or you know that the users have a tendency to peek where they shouldn’t be. In either case, the customer who commissioned the project has the right to ask for the passkey, unless it was agreed upon that you owned the project and they were just buying it as a premade project.

Do yourself a favor as a consultant, think twice before encrypting that project.

Technorati Tags: Coding, Encryption, Consulting, Development