I noticed that a good many of you who read my blog also read Jake's...or at least you used to. Despite his best efforts to alter the entire known human population to the fact that his long awol blog is back online, in case any of you were left in the dark - check out Jake's blog. Jake - how we have missed you.
Also, in an earlier posting, I made reference to a colleage of mine. I did not realize that he had a blog (shame on me). So here is a link to Mike's blog, as well.
What a crazy bunch of guys I work with :)
Friday, November 18, 2005
Thursday, November 17, 2005
Who Should Pay for Development Tools?
I work for a consulting company, and a question was posed to me yesterday about the cost of purchasing something like Red Gate. This SQL diff tool will help me deploy changes in a faster, safer way to my client's production server. So should my consulting company invest in this tool, or should my client?
In the case of the SQL diff tool, in order for the tool to work best, I need to have access to the database server that holds both the production and the development databases so I can compare them. This tool needs to get installed on my client's database server, so they need to purchase it. Should my company also purchase this tool so we can use it on other projects?
What about tools like CodeSmith? CodeSmith helps my company deliver a lower-cost and higher-quality solution to my clients, since templates can spit out our DOM library code quickly and without human typo errors that hand-cranking the code would produce. So since my client is benefiting from the tool, should my client share in or take full responsibility for the cost of the purchase?
I think that when a client needs to install a tool on their environment, they have to pay for it. I think that when the client does not need to install the tool on their environment, my company should pay for it.
The reason I feel this way is because I see these tools as investments. Tools that help my company deliver higher quality solutions quicker than our competition can, could potentially cut down on the billable hours we spend on each project. While this may seem like a loss for our company to some, I see this as giving us an edge over our competition. Today, theoretically, we could deliver an identical solution to one we provided before we had this tool at a lower cost. This lower cost, since it was attained by removing some of the manual, labor-intensive busy work, should result in higher quality. Since we removed the manual labor piece, where we get bored and are prone to make errors, we now have a higher quality solution.
I feel that this edge we now have should result in two layers of benefit. On the one hand, we should be able to win more business - even if the business we win is at a lower cost. If we can do the same things as our competitor, but for less money, we should win the business.
On the other hand, the tools should enhance our ability to attract and retain both clients and consultants. If we deliver higher quality solutions, our clients will rave about us and bring us more business in the future, right? If we don't have to spend as much time deploying, troubleshooting syntax or synchronization errors, and maintaining inconsistent code we should have more time for our consultants to spend designing, creating, and learning.
I know I may have simplified the argument a bit, but I do feel that the small investment in a tool like Red Gate's or CodeSmith should pay off exponentially. I feel that the pay off can help our clients, but in doing so, help my company even more. So I think that if a consulting company wants to remain competitive, they should welcome tools that will take the busy work out of software engineering to open the door for their consultants to invest in being innovative instead of having to invest time in bug-fixing, manual database synchronization, or the writing of repetitive code.
In the case of the SQL diff tool, in order for the tool to work best, I need to have access to the database server that holds both the production and the development databases so I can compare them. This tool needs to get installed on my client's database server, so they need to purchase it. Should my company also purchase this tool so we can use it on other projects?
What about tools like CodeSmith? CodeSmith helps my company deliver a lower-cost and higher-quality solution to my clients, since templates can spit out our DOM library code quickly and without human typo errors that hand-cranking the code would produce. So since my client is benefiting from the tool, should my client share in or take full responsibility for the cost of the purchase?
I think that when a client needs to install a tool on their environment, they have to pay for it. I think that when the client does not need to install the tool on their environment, my company should pay for it.
The reason I feel this way is because I see these tools as investments. Tools that help my company deliver higher quality solutions quicker than our competition can, could potentially cut down on the billable hours we spend on each project. While this may seem like a loss for our company to some, I see this as giving us an edge over our competition. Today, theoretically, we could deliver an identical solution to one we provided before we had this tool at a lower cost. This lower cost, since it was attained by removing some of the manual, labor-intensive busy work, should result in higher quality. Since we removed the manual labor piece, where we get bored and are prone to make errors, we now have a higher quality solution.
I feel that this edge we now have should result in two layers of benefit. On the one hand, we should be able to win more business - even if the business we win is at a lower cost. If we can do the same things as our competitor, but for less money, we should win the business.
On the other hand, the tools should enhance our ability to attract and retain both clients and consultants. If we deliver higher quality solutions, our clients will rave about us and bring us more business in the future, right? If we don't have to spend as much time deploying, troubleshooting syntax or synchronization errors, and maintaining inconsistent code we should have more time for our consultants to spend designing, creating, and learning.
I know I may have simplified the argument a bit, but I do feel that the small investment in a tool like Red Gate's or CodeSmith should pay off exponentially. I feel that the pay off can help our clients, but in doing so, help my company even more. So I think that if a consulting company wants to remain competitive, they should welcome tools that will take the busy work out of software engineering to open the door for their consultants to invest in being innovative instead of having to invest time in bug-fixing, manual database synchronization, or the writing of repetitive code.
Wednesday, November 16, 2005
SQL Diff Tool
I know it has been forever since I last blogged, and the slew of comments I have gotten in the past few months has deterred me from posting. Apparently, there are thousands of companies out there who think I have a "Great blog! Keep up the good work! By the way...please [get a new mortgage/enter our sweepstakes/buy our ultimate diet plan/etc]." Maybe I need to start paying someone to host my blog so I will keep out the riff-raff.
Anyway, Mike Hodnick recommended a database tool to me today that I am in the process of testing. It is very cool. I have not used other SQL Diff tools, so I am a first-timer. This thing rocks! I ran a diff on my production database and my development database. Not only did the tool tell me about the schema changes, allow me to choose which changes I wanted to resolve, and allow me to choose which database should get altered, it also brought some issues to my attention in the production environment of which I was unaware. For some reason, my foreign keys were missing. The tool generated a script, which I reviewed and then ran against my production database. I did have to clean up some data due to the missing keys, but now I have a quality production database that matches my development environment. I love it!
The tool is called SQL Compare and is sold by Red Gate. By itself, the compare tool cost $295, but you can download a 14-day trial. Check it out.
Anyway, Mike Hodnick recommended a database tool to me today that I am in the process of testing. It is very cool. I have not used other SQL Diff tools, so I am a first-timer. This thing rocks! I ran a diff on my production database and my development database. Not only did the tool tell me about the schema changes, allow me to choose which changes I wanted to resolve, and allow me to choose which database should get altered, it also brought some issues to my attention in the production environment of which I was unaware. For some reason, my foreign keys were missing. The tool generated a script, which I reviewed and then ran against my production database. I did have to clean up some data due to the missing keys, but now I have a quality production database that matches my development environment. I love it!
The tool is called SQL Compare and is sold by Red Gate. By itself, the compare tool cost $295, but you can download a 14-day trial. Check it out.
Subscribe to:
Posts (Atom)