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