Review of New Relic

I just received an overview of NewRelic today.  My initial thought is that it looks awesome. If you haven't check out the video, it is worth it.    Ref: http://newrelic.com/why-new-relic/how-it-works

Quality Assurance - Quick Read

Joel, as much as I don't argue with, wrote 2 articles that I think are great....

The Joel Test: 12 Steps to Better Code

1.  http://www.joelonsoftware.com/articles/fog0000000043.html

Top Five (Wrong) Reasons You Don't Have Testers

http://www.joelonsoftware.com/articles/fog0000000067.html

How To Do Work You Don't Want To Do

I was recently given a very complicated task: installing a highly dependent project in a complex environment ( one of 30 different configurable environments) without VMs or root privledges. Now, to complicate things, image that you don't have any guidance, not one thing written. All you have is a poorly documented configuration file known in Maven as the POM, 10 sets of property files, and a git directory. To make matters even worse if possible, you have never touched this code and you can't write any of it. You can only compile, build, configure, install, and troubleshoot. Oh, the developers who wrote the code are in remote offices and you are installing this complex software in a remote network, without access to the internet. Number of external services requires for integration = 10+ rest based with encrypted services. The challenge is daunting. These are the steps that I took to finish: 

1. Procrastinate - That's right, I said it. I solved a few other issues knowing that this task was looming.  So I am not the only one advocating being lazy, you can read this supporting column.     Who knows, maybe someone will cancel the task and you  wouldn't have to do it , right?

2. Control It - Create a teaching aid to teach someone else. When you teach something, you must learn the material better. It it only through teaching that you really learn. I turn to documentation as not only a helper for those that follow, but more as a motivator. Face it, compiling and configuring someone else's work is just about the worst job out there. When you think of the benefits and value you have by building training material, just about any task is bearable. If you have control, you are going to be much happier.

 3. Acknowledge your Pain - When doing something very difficult, remind yourself... it is going to suck at first, bad. Then, it will get easier. It always does, provided you have the prerequisite knowledge to complete the task. If you find yourself without the basic fundamentals in place, you will always struggle until your foundation is correct. You are human and this cycle is natural. I acknowledge the pain by swearing at my computer some times, if you choose this option, make sure you do it quietly. :- )

 4. Don't give up - work through the pain and don't give up. Grab a coworker and talk through a problem you are having. Even if they don't know how to solve it, it can feel better or help you work through something.

 5. Celebrate - By now, maybe is it 1 day or 5 days later, you will have solved the problem and become that much sharper for it. Realize that when you can do hard jobs, other people around you will value that skill, even if they don't say it.

6. Do it again - As soon as possible, volunteer for the same job. Taking the hard jobs means that you are typically going to grow your skill set. Even if this boss doesn't realize how valuable these skills are, remember, that one day, you will find someone who does appreciate them.

7. Expand Your Influence - If you can influence the work so that it is easier to do, then that is even better. Train a coworker - grab someone and help them through the steps that you just completed. Take the time to work with the remote developers building your code to make the task easier to complete. Your customer will thank you for it!

The Man In The Arena

Often quoted during plebe summer in 1996, one of the greatest quotes that I have ever read and appropriate as ever.

"It is not the critic who counts, nor the man who points out how the strong man stumbled, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena; whose face is marred by dust and sweat and blood; who strives valiantly; who errs and comes short again and again; who knows the great enthusiasms, the great devotions, and spends himself in a worthy cause; Who, at the best, knows in the end the triumph of high achievement; and who, at the worst, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who know neither victory nor defeat."

~President Theodore Roosevelt

Speech at the Sorbonne

Paris, France

April 23, 1910

Donating To Wikipedia

I donated to Wikipedia for the first time.  I love the service, love the mission, and use it almost everyday.  The site gives me hope in humanity.  :-)

7 questions to ask before taking on a new software client

This article is geared towards a small services company or freelancer that is looking to build software for clients. There are probably many more questions that you should ask, but these seems to be the most important.

1. Can you make a profit? If you cannot make enough money on a project, you will not be able to earn enough to live (bad) or save enough to get you through the rough patches (really bad). Having cash reserves is the only way to survive the time gaps in between work for you or your developers. Managing an efficient bench of developers is perhaps the most difficult tasks in software services. Having money is the only way to do this.

2. What is your client's experience level? If you are dealing with a client who is new to software development and the bumps that happen along the way, then you will need to spend some extra time with them to educate them and get them comfortable with the process. It is important to size them up appropriately.

3. Is the work doable with the budget? When a client asks how much their custom software costs to develop, my first reaction is to cringe. It is difficult to determine as many times the client is thinking of behavior they expect to have without communicating it effectively. As you already know, software is expensive. It is very important that you set expectations clearly. This is tricky because you want to secure the work, but you must be honest. If the customer does not want to do work with you because you are telling them something that they don't want to hear, you are much better off not taking them on.

4. What benefits are there other than money for the work? Can you gain some useful experience from a project? Is the technology something that you want to work in? Can you use this client as a valuable resource? Is the network of people they are connected to valuable? There are some basic questions here that you should think about. Beware however, clients could potentially over inflate their social value in order to obtain a better deal from you.

5. Do you have the time and resources to serve them? You must think very carefully about this. Software development is all about pipeline management. If you overextend yourself, your client and ultimately you, will pay the price. If you take on a high value client and cannot serve them, then the damage could be catastrophic. Taking on less work will lead you to a higher quality product, happier clients, and less money in the short run.

6. Can you say no? If you cannot say no to a software project, then you should not be doing the software project. Backing yourself into a corner means that you are less likely to use good judgement. Having the power and ability to say no is critical.

7. Did you read the Prisoner's Dilemma for software development? If you haven't read this and you are working for clients, you are missing out big time. This article should be required reading for all freelancers. The summary is that you must be able to stop work if a client isn't paying. If you don't, you will get burned.

Thanks for reading. If you have any other questions I should add to this, let me know and I will post them.

Software Project Leadership -

As a leader, you have 2 switches. It is on or off. There is no middle ground or treading water.

If you can take a project on and have the bandwidth to lead it, great. If you don't have the bandwidth, you had better put someone on place who can lead the software project.

What does it take to lead a software project?

1. Have experience - You need to know what you are talking about

2. Have Top Cover - Make sure you can make mistakes and push forward. If you don't have top cover, you are destined for failure.

3. Be smart - change something that isn't working. Don't stick to convention when it isn't serving you.