Jun 7 2012

The Cost of Doing it Wrong

As the saying goes, if a thing is worth doing, it’s worth doing well. It has been proven that doing a thing right the first time is most efficient and cost effective. But what is the cost of doing something wrong? In terms of money, I’ve seen cases where something is done incorrectly and then had to redone at a loss of $100k. In terms of time, you can model it in the following thought experiment.

If a task takes x amount of time to complete and it is done wrong the first time, how long does it take to fix it?  More than 4x. It takes to x amount of time to complete the task the first time, probably at least x amount of time to find out it was done wrong, another x amount to figure out what the first guy did, and finally x amount to fix it correctly.

We all can agree that time is money and if a task is done incorrectly it may cost at a minimum as much as four times as much as it would cost if done correctly the first time around.


May 28 2012

The 80 Percent

I always give 110% to any task I set out to complete. If you ever give anything less than 100% then you get the following logic…

It’s okay if we do 80%, but the 80% needs to be done 100%… We can’t deliver 80% of the 80% we actually attempt of the 100% we are committed too.


Mar 26 2012

The Code Rules

Rules to code by…

  • No consultant code.
  • No complacent code.
  • No crappy and sloppy code.
  • No cut and past code.

Mar 5 2012

It’s Always Your Problem

As a business, if any client has any sort of problem using your software then it’s your problem. Non technical users will have trouble using your software because of an array of issues, such as permissions, settings, configurations, other software, and external devices. No matter what, you have to make the effort to get them started using with your software or not. I’ve seen issues at different client sites because one software application required one version of Java and another required a newer version. Typically you can have multiple version of Java on a computer, but these two applications demanded that only over version exist and that it be the one they require. I’ve seen issues where end users print from an application and complain because they don’t see the document printed in their laser jet, it was printing in another printer in another floor and they didn’t know how to configure it correctly.

As a development lead, if any programmer has any sort of problem with your architecture then it’s your problem. If someone doesn’t understand an design and they have to work with it, they will make changes that can cost you in the long run. If you make a system overly complex, there will be a time that you will have to delegate that to someone else and they will not understand it as deeply as you and will make changes to fix the bug of the day, but cause another problem to be discovered later.

Whether an end user doesn’t know how to change the printer or a new developer doesn’t know how to implement your design, it’s your problem and it should be addressed with something other than blaming the confused.

Sometimes it’s because you took on the wrong client, or hired someone without the technical background, but it is still your problem. Often times, the problem is basic communication and availability of training material. Always, examine these situations and see how you can improve the process, training, and communication of your team.


Oct 12 2011

The Four A’s of Email

I like to adhere to the AAAA rule of email. The four A’s of email reminds you to check you email for four items before you click the send button. Check and double check for correct Address, correct Attachments, correct Attitude and tone and state an Action you want from a recipient.

Recently, a developer in distress sent the following email to the whole company.

I can’t delete any data from any UI screen.

That test doesn’t read like an email, it doesn’t even make sense as a tweet, it’s like an unfortunate cookie message. The email should not have been sent to the whole team, which include sales people, it is to vague, does not have any clear action or request.

Communication is vital for any team and the teams running on full speed need the right level of communication in the right medium. If you are interested in learning how to effectively use email to communicate with your team I recommend the following posts.

There is a fifth A; don’t be an Ass.


Oct 11 2011

Keep Code Statements Simple

I don’t count my progress by the line of codes but at the same time I don’t take pride by over engineering a solution. Writing code is like writing for a publication, you have to know at what reading level you are writing for. That said, the one type of code statement that gets under my skin is what I call the run-on code statement. A Run-on code statement is one that has multiple method calls in one statement. Here is a made up example of a run-on code statement.

DataManager.getInstance().refreshData(obj.getAsInteger().toString());

In the above run-on code statement there are four method calls. I’ve seen worse. The reason whey run-on code statements are a pet peeve or mine is that if anyone method call fails because of a NullPointerException or some other error it’s difficult to quickly know what segment of the code statement failed. This is also annoying to debug if you want to step into one method out of the four.