As I transition from full time employment to being fully self-employed (starting in September), I’ve had the wonderful opportunity to talk with a number of potential clients from all industries, with all types of past experiences and varied budgets. In the last month alone, I’ve talked with over 20 different companies. During these talks I’ve learned one major thing that surprised me. I suppose because I’ve been working for individual companies for so long I didn’t realize there were so many misconceptions about developers, web development, and productivity out there in the business world.

I’m only going to discuss one misconception in this post, if you want to hear more about the many issues of web development and putting a team together, come to the open Tampa Bay WaVE meeting on 9/20 – cohosted by TBTF’s Emerging Companies Network where I’ll be on a panel discussing how to avoid pitfalls in website development.

The most major disturbing trend I’ve observed is the sole reliance on hourly rate to determine overall project cost. In other words, a developer who charges $45/hour is far cheaper than one that charges $75 hour. Make sense right? If you paid for 10 hours of work, it costs you $750 vs $450. But if you calculate development costs that way you are leaving out the #1 most important factor in development: time.

It takes time to code anything, but if you think rates among developers have a wide varied range, you may have no idea just how wide the range is in productivity. It can be so extreme as to be almost unbelievable. There have been numerous studies over the years demonstrating this to be as much as 10:1 or even 100:1. In my 15 years in IT, I’ve observed this range in productivity to be extremely common. I’ve had many managers who actually double and triple development estimates depending on which of their developers they plan to assign the task to. It’s really not unlike typing. If you wanted to pay someone for data entry and paid for the hour, wouldn’t someone who types 120 words a minute be cheaper in the long run to hire than someone who types 30 WPM, even at 2 or 3x the rate?

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

Consider then, that if you decided to hire the $45/hour developer and it takes them 40 hours to complete a task. The project took longer than you’d hoped, the software isn’t quite as fast as you would like, but its completed and you are quite pleased that it only cost $1,800. But what if you had hired a more experienced developer, one who is more a ‘Software Engineer’ than a programmer, and that person had completed the same project in 10 hours? At $75/hr (which is still a steal), your total cost would have been $750, and most likely perform better, be more stable, and be better able to be expanded and supported in the future. Or even if it had taken 20 hours, the total cost is still only $1,500 for very likely a better result.

If you aren’t convinced this issue exists, ask around. Talk to CEOs and Founders of startups and ask them for their early experiences of hiring developers and just how well it went for them. I’ve heard horror story upon horror story, and a good percentage of my projects over the last year have been to fix poorly written code written by teams that were hired on the cheap.

Sometimes the code is poorly written because those hired are unethical or believe themselves to be far better than they really are. Other times, its not that the person you hired is a bad person, its just that they haven’t yet put in the time on numerous projects in a wide ranging set of challenges to have gained the experience necessary to increase one’s productivity and quality. I’m not attempting to disparage any of them. Everyone must start somewhere, and everyone has or will. I’m speaking to owners, CTO, founders, and anyone in the position of deciding what rates to pay and what developers to hire to make them aware of the other side of the cost equation.

It’s a simple plan of action to help ensure you don’t pay more in the long run. When you ask for an hourly rate, recognize that you have only asked for half of the information needed to determine cost. You cannot decide to hire one person over another based on the rate. Make sure all your inquiries include both hourly rate and hours estimated. It’s the total project cost you have to calculate. And even with that, this simple calculation leaves out future costs of maintenance, likely hood of needing to hire someone more experienced in short notice to assist the cheaper developers when they are faced with an issue they can’t resolve, etc. I’ve heard so many stores in just the last month of estimates provided by the cheaper developers that in the end resulted in 3 – 4x the hours they originally estimated…and paid for.

I love seeing products come to completion. I love seeing a Founder’s vision realized. I know from experience its very exhilarating to see an idea from your head actually result in a finished working product. Equally, its so disheartening to hear of startups and companies unable to get their product to launch because of poor hirings, particularly when so many of them seem to have been entirely based on finding a low rate.

Here are a few questions to ask before hiring a contractor/freelancer to work on your project…in addition of course to asking for both an hourly rate AND an hourly estimate:

• How many projects of this size have you provided estimates for in the past? Can you provide contacts and recommendations from clients about those past sizings?
• What are you basing your sizings upon? What past projects provided similar functionality to my project?
• How many projects of this size have you completed in the past? Can you provide contacts and recommendations from those clients?
• How and when will you communicate to me if the time you originally estimated isn’t enough? How soon will I know?
• If the deadline is approaching and it doesn’t look like it will be reached, what is your strategy for increasing productivity and still meeting that deadline?

Nothing can ensure a perfect development process and no set of questions or advice will completely prevent hiring the wrong person or spending too much. But the more you know the better the decision you can make. So please, never let me again here the one and only question: ‘What’s your hourly rate?’ Ask for the rate, that’s fine, but follow up with some sample projects and ask how long they took. You might be quite surprised how fast some developers can complete projects.

Do you have any development horror stories and/or suggestions for dealing with these situations? Leave your thoughts in the comments below.

I recently received this question about the Agile method of developing software and thought I’d share it and my answer.

Q. I am doing some research on agile methods, and wanted to know what you think about the use and application of agile methods? Will they continue to be used more in the next decade in internet software development? And what agile methods do you use?

A. Many startups have been using a more “agile” project management methodology without really knowing it. It’s the formalness of the “official” Agile and Scrum practices that are gaining in adoption now. As to if that official set of rules will stay around for a long time it’s impossible to predict, but judging from history, I think certain exact sets of guidelines come and go in popularity. The principles behind what is considered Agile however, I believe will last a long time. Many of us have seen the failure of planning out year long projects, holding daily hours long meetings to discuss statuses, and building 100 page analysis documents before anything is ever built.

Small, lean, flexible teams, working on shorter production cycles will always produce better software than rigid, bloated teams working on long drawn out project timelines. But most teams will do so without ever getting certified as a Scrum master or some official title for following some group’s rules as to how to manage a project. They do it because they observe the failures of the opposite through experience, particularly if they ever worked in a large corporation and had to follow the time wasting mess of project management that typically emanates from such places.

For me, following rules for how a project should go is not agile enough in itself. Guidelines are great, and I recommend understanding the Agile method so you can learn from it’s principles, but true agility comes from fitting the process to the specific team and project at hand. So I recommend never becoming allegiant to a certain methodology of project management, nor even to a certain development process. Use them as guidelines, but adapt them to your specifics and let them grow with you as you learn and experience more. Ensure the team shares in the understanding of why the agile process is better versus things like the water fall approach. Once they do, wether you stick to the Agile Manifesto or not will not be the significant deciding factor in the efficiency of your software development. It’s the underlying principles that matter, and those I believe will be with us for a long time.

As I mentioned previously in, Everything Changes, I switched from PC to Mac about two months ago. I’m still just as excited about it every time I turn it on as the first day, so I’ve compiled a list of what I love about my Mac. By the way, I previously used linux as my sole computer for almost five years and Windows before that every year since it came out.

These are only in the order I thought of them…too hard to order them:

1. Ability to use a PC keyboard seamlessly (maybe I’ll write later about why I prefer this, and I tried the Mac keyboard for a month before switching)
2. Quicklook
3. TextMate (have to save the wows on this for another post, too many to list – goodbye eclipse, netbeans, texteditor, notepad++, text wrangler, sql tool and wordpress blog gui)
4. Adium (better than gaim, trillian, gtalk, etc)
5. Auto mute when I take out my headset (just like I asked for last year)
6. Mighty Mouse (best mouse I’ve ever used)
7. Ability to use external monitors (love my Gateway FPD2275W, 22″ DVI-D with built-in 4 port USB 2 hub and PIP)
8. Font rendering (improves the entire Internet browsing experience)
9. Fluid (use this for bloglines, remember the milk, gmail)
10. Unix underneath
11. Running Windows on VMWare Fusion (when I unfortunately need to test something in Windows, but at least rebooting is not as painful and it seems more stable)
12. Quicksilver
13. Coverflow in Finder
14. Finder’s 3 pane folder view (genius!)
15. Dashboard
16. Intel Dual Core
17. Slick, streamlined case, and lightweight
18. Cheap memory upgrade (through crucial.com of course)
19. Firefox never crashes! (well, maybe on occasion, but it crashed consistently before)
20. Hardware just works, from bluetooth devices to external usbs and hard drives
21. Wifi just works (don’t get me started on Linux and wifi)
22. iMovie and ease of using digital video cameras…plugged it in and iMovie sucked all the video in, with thumbnail generations, and sorted all the clips by date!
23. Auto recognition of other devices on the network (lets see how do I connect to that linux server, hmm never done this, oh wait, why is it listed in the finder already…it already found it!)
24. iSight, easy video chatting and recording
25. the dock (love Mac’s take on this)
26. Expose!
27. Using external monitor as the primary and laptop screen as secondary monitor
28. Running everything all at the same time while watching full screen video (on the laptop screen), running mongrel/Rails, mysql, textmate, firefox, and no problems!
29. FrontRow
30. Controlling my Mac with Ruby (instead of ActionScript…but haven’t actually tried it yet)
31. Easy VNC with Vine Server
32. Super easy installs (ugh, goodbye linux install tools, and command line builds) and uninstalls
33. Small well-designed power brick, with fold out plug (don’t even need the 2nd part of the typical plug and brick)
34. Being able to test my web development on all the main browsers on my laptop: IE 5 – 7, Safari on win/mac, Firefox 2/3 on Win/mac (see Running Multiple Browsers for Testing)
35. The remote control
36. Long battery life, excellent battery conservation when unplugged
37. AppFresh
38. Force quit
39. Overall feeling that everything is more intuitive, more stable, and better integrated

I can definitely see uses for this, including having one browser running for the project site I’m working on (from Fluid):

Using Fluid, you can create [site specific browsers] to run each of your favorite WebApps as a separate desktop application. Fluid gives any WebApp a home on your Mac OS X desktop complete with Dock icon, standard menu bar, logical separation from your other web browsing activity, and many other goodies.

Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.