Page 1 of 2

The true costs of development tools

Posted: Fri Nov 04, 2005 8:35 am
by redmonkey
In a spin off from a comment that was made yesterday where essentially a solution/method was dismissed because it 'cost money' as it was *thought* to be only available as part of a commercially based licensed application.

This left me curious as to what the general perception is with regards the true cost of development tools.

My take, personally, regardless of license type, the 'best tool for the job' is the one which maximises your productivity and work flow. If that particular tool costs money, it will pay for itself over a period of time by virtue of your increased productivity. Surely accepting a solution/tool/method based purely on the fact that it's cheaper/free although may job done at a sacrafice of productivity, it will ultimately cost you more in the long run?

For what it's worth, my 'day to day' development tools consist of a range freeware, shareware, open source, commercial and in house developed tools. I wouldn't class any free or low cost development tool as inferior to their commercial couterparts without first evaluating it, similarly, I don't assume that a commercial tool is superior in any way just because it costs money.

Posted: Fri Nov 04, 2005 9:49 am
by Chris Corbyn
I agree completely. Just go for the best tool for the job. If there's not much in it I'll obviously go for the cheap option though :)

As an example I've shelled out for Zend Studio a while back... used it heavily, loved it, then for some reason (probably the fact we don't use it at work), I don't use it now.... I just use plain old Kate so that was perhaps a waste of money.

I don't pay for operating systems neither.... I believe that if you're developing, Linux is the best thing to use, but I use that at home too.

Posted: Fri Nov 04, 2005 10:35 am
by redmonkey
Considering the cost of a commercial PHP IDE which is typically $100 - $400 (yes I realise there are more expensive applications out there) which if you are a freelance PHP developer (in the western world) equates to only a few hours of your time, if that IDE averages a 20-30% increase in productivity, it's going to pay for itself over a very short period of time.

Agreed, if I evaluate two or more applications and they all offer very similar functionality and features then I would most likey opt for the most cost effective option.

With regards OSs, my desktop development environment of choice is Win 2K Pro at present, I'm currently evaluating Mac OS X with a view to switching over to that, I haven't spent too much time on yet but so far I'm quite impressed with it's base features/functionality. There are a few things thus far that seem odd/quirky but I'm sure that's the case whenever you are working on a different OS from your norm.

I also have Win XP and various Linux distros setup as desktop workstations but these are only for testing purposes.

For servers I use *nix, typically Debian GNU Linux.

Re: The true costs of development tools

Posted: Fri Nov 04, 2005 11:50 am
by Jenk
redmonkey wrote:In a spin off from a comment that was made yesterday where essentially a solution/method was dismissed because it 'cost money' as it was *thought* to be only available as part of a commercially based licensed application.
Pretty much offtopic, but no it wasn't dismissed because it cost money, it was dismissed because there is a perfectly viable method to fulfill the role already, which doesn't require any other software, free or not, to be installed ;)

Posted: Fri Nov 04, 2005 12:18 pm
by yum-jelly
I think for some things you can get by with many different options. But a IDE is important if you want to maintain integrity across developing platforms! What goes for other stuff pretty much anything in my case will do. But the core of my development. Is moving in and out of different environments so having a IDE that is the same when I am working in Unix, Linux, Windows, Mac is really important to me. It allows for me to maintain my code libraries and create tools that I can use across the scope of my projects. That includes shifting in and out of PHP, Perl, Ruby, Python and .NET. It also makes it nice not having to learn new ways of doing things. I use Komodo because it's cross language support is worth every penny that I paid for it! I still use other tools even open source tools because some are really good even better than what I pay for. But like I said my core work flow always is centered around my IDE.


yj

Re: The true costs of development tools

Posted: Fri Nov 04, 2005 12:18 pm
by redmonkey
Jenk wrote:
redmonkey wrote:In a spin off from a comment that was made yesterday where essentially a solution/method was dismissed because it 'cost money' as it was *thought* to be only available as part of a commercially based licensed application.
Pretty much offtopic, but no it wasn't dismissed because it cost money, it was dismissed because there is a perfectly viable method to fulfill the role already, which doesn't require any other software, free or not, to be installed ;)
That was not how I interprtued your comments so I apologies if I have misunderstood you.

With your response, you have, possibly inadvertantly, contributed to the purpose of this thread.

Personally, and again I acknowledge that your method can be used to get results, I don't believe that any method which sacrafices productivity (as your method would in my case) can be classed as 'perfectly viable', useable yes, but not perfectly viable. Of course it may well be that you are a extremly proficient with the 'echo debugger' and my points are null and void for your circumstances.

Posted: Fri Nov 04, 2005 12:47 pm
by redmonkey
The idea of developing on multiple OSs seems a bit odd to me, I really can't see a need to have your development environment replicated across multiple OSs/machines? However if you have that need then Komodo probably makes this quite easy with it's shared toolboxes etc...

My collection of development tools extends further than just an IDE as I've yet to come across an IDE that has/is capable of everything I need.

Posted: Fri Nov 04, 2005 1:13 pm
by timvw
If you're thinking about buying software it comes down to the following:

- How much does it cost me to create an equivalent product ourselves?
- How well does the product meet my needs?
- How much time do we need to invest in study etc?
- What about support?

I'm happy with writing java with eclipse, php with crimson editor, cobol with realia2 and c# with visual studio.
And for a quick correction i usually prefer vim.

Re: The true costs of development tools

Posted: Fri Nov 04, 2005 1:23 pm
by Jenk
redmonkey wrote:
Jenk wrote:
redmonkey wrote:In a spin off from a comment that was made yesterday where essentially a solution/method was dismissed because it 'cost money' as it was *thought* to be only available as part of a commercially based licensed application.
Pretty much offtopic, but no it wasn't dismissed because it cost money, it was dismissed because there is a perfectly viable method to fulfill the role already, which doesn't require any other software, free or not, to be installed ;)
That was not how I interprtued your comments so I apologies if I have misunderstood you.

With your response, you have, possibly inadvertantly, contributed to the purpose of this thread.

Personally, and again I acknowledge that your method can be used to get results, I don't believe that any method which sacrafices productivity (as your method would in my case) can be classed as 'perfectly viable', useable yes, but not perfectly viable. Of course it may well be that you are a extremly proficient with the 'echo debugger' and my points are null and void for your circumstances.
Just how does it sacrifice productivity?!

Re: The true costs of development tools

Posted: Fri Nov 04, 2005 3:58 pm
by redmonkey
Jenk wrote:Just how does it sacrifice productivity?!
By 'sacraficing productivity' I mean it would take longer therefore you acheive less in a given time period, they say an example is as good as a thousands words....

Today I've been writting a MySQL class, and I wanted to just double check a small section was doing what I had intended it to do.

The code/function in question is this....

Code: Select all

<?php
  function connection_id()
  {
    static $conn_id;

    return is_resource($conn_id) ? $conn_id : $conn_id = DB::connect();
  }
?>
Specifically, I wanted to ensure/check that the ternary was acting as intended and that $conn_id contained the resource link for the DB connection after the first call to the function.

So, with the file open I set a breakpoint as can be seen in this image (the red dot next to the line is the breakpoint marker).

Next, I run one of the scripts (which query the DB) within the app through the debugger, and the debugger pauses script execution as soon as it hits the breakpoint as can be seen here. From that you can see that all is intended so far as this is the first call to the function $conn_id is_null as expected. At this point, I 'step into' the code to ensure the intended code flow is as expected and indeed the call to DB::connect is being made.

Next, I hit 'Go' which again runs through until it hits a breakpoint, which in this case is the next time it hits the function, this time you can see at the bottom of this image that $conn_id is indeed populated with the intended contents. Again, I then 'step into' the code, this time to ensure that the call to DB::connect is not being made.

Total time was approx 5 seconds, to carry out the above using an 'echo debugging' method would for me, take a lot longer.

Note: this is a very basic example and in no way truly highlights, the full benefits/advantages that a true debugger has over echo.

Hope that helps.

Posted: Sat Nov 05, 2005 2:45 am
by alvinphp
If an editor saves me 10% then I would pay quite a bit for it (okay my work would), however if another ide exists with the same features and it costs less then I would go with that.

And debuggers have saved me a lot of time. They do not just point out where the error happens, they tell the values of all your variables across all your objects at any point in time you need to see.

Posted: Sat Nov 05, 2005 9:59 am
by Roja
redmonkey wrote:The idea of developing on multiple OSs seems a bit odd to me, I really can't see a need to have your development environment replicated across multiple OSs/machines?
Well, its quite odd to me *not* to develop on multiple OS's.

Let me explain why, and maybe that will help clarify why its an important issue for me.

First, I primarily work (in my "spare" time) on opensource games that people download, install, and offer to the general public on their server - for free.

That usually means that the admins (the people running my game) want to keep their costs as low as possible. As a result, they want to offer the games on the servers that they already pay for. That results in a huge variety of platforms - OpenBSD, Linux, Windows, FreeBSD, etc.

So when a user has an interesting problem on one of those platforms that are unique to that platform, how can I test it?

Right, by having that platform to test on, and reproducing the problem. Now, I certainly don't have every platform represented in my modest house. However, I do manage to hit the majority fairly easily. I have a windows box for gaming, which (usually) covers most of the windows compatibility issues. I have a linux box for development, and that covers most of the hosting platforms running linux (although there are substantial differences between distributions!). My server that I host sites on runs FreeBSD, and I have a VMWare OpenBSD session I can test against.

But whats interesting is that I've made sure to build a full development environment on almost all of those. Specific editors, revision control systems, file transfer utilities, diff, merge.. all available.

You find it "odd", while I find that it would be a huge decrease in my producitivity if I didn't do it that way. Thats why you posted the original post, I hope - to understand why other people make different choices than you do. :)

On another point you make..
redmonkey wrote: I wouldn't class any free or low cost development tool as inferior to their commercial couterparts without first evaluating it, similarly, I don't assume that a commercial tool is superior in any way just because it costs money.
For me, I'd rephrase that substantially. The issue for me isn't cost v. no-cost. If I did not already own a copy of windows to allow me greater access to games, I would not develop or test on windows at all. I don't test db-compatibility on MS-SQL, and don't support proprietary solutions. Why?

Because I deeply believe in the value of freedom software. Software that allows me to see what the root cause of annoying behavior is. Software that allows me to contribute in a group fashion to repair problems - and even roll my own if I need different things than the original compiler did.

Freedom software isn't about just getting to "see" the source, isn't about just being "no cost", its about having the freedom to figure out WHY its crashing, fix it, and be able to move past the issue without relying on a slow, unresponsive single vendor to respond to my unique and specific need.

Thats why the majority of my work is done on code under the GPL. I absolutely *do* classify a non-freedom software package as inferior in many ways without ever using it, purely on the license alone. Having my hands tied on what I can fix and workaround isn't a tradeoff I'm willing to accept generally. Doing so deeply reduces my productivity just like not using a debugger slows you down. :)

Just to save some future posts, I have and do contribute patches and bug reports to the majority of software I use. Linux, Nano, Apache, PHP, adodb, smarty, the list goes on. Notably, I have yet to see any responsiveness from my bug reports to Microsoft, while the rest of the list have all been patched since. Thats the power of freedom software, and it absolutely does make sense to assume that proprietary software can't touch that with a ten-foot-pole.

Posted: Sat Nov 05, 2005 10:11 am
by redmonkey
It the idea of developing *on* multiple OSs that seems odd not developing *for* multiple OSs.

I do test on multiple OSs, but I only use a single OS environment to code/develop, I have a myriad of boxes here with various flavours of OS and hardware.

Most of the time I have code on my machine which is not checked into the code repository as I'm still working on it. If I had to switch between multiple OSs I could not guarantee that I would be working with the same codebase on each machine.

Posted: Sat Nov 05, 2005 12:05 pm
by Roja
redmonkey wrote:It the idea of developing *on* multiple OSs that seems odd not developing *for* multiple OSs.
Its odd for me to decouple the two.. When I'm developing, I want to jump in and make changes real time - and see the results, on that platform. Then I just do a svn commit, and its all good.
redmonkey wrote:Most of the time I have code on my machine which is not checked into the code repository as I'm still working on it. If I had to switch between multiple OSs I could not guarantee that I would be working with the same codebase on each machine.
Thats precisely what subversion is for. If you keep your repository up to date, you can switch between machines easily with just a svn update. :)

Or put another way, because you are choosing not to commit often ("I have code on my machine which is not checked in"), you don't get the benefit of being able to quick switch between machines, environments, developers, or even continents. :)

Posted: Sat Nov 05, 2005 12:19 pm
by redmonkey
Roja wrote:Or put another way, because you are choosing not to commit often ("I have code on my machine which is not checked in"), you don't get the benefit of being able to quick switch between machines, environments, developers, or even continents. :)
No, it's because I work with 17 other developers and I'm not prepared to risk breaking the build process by checking in potentially 'half baked' and untested code purely for my convenience of having that code on another machine. Code which doesn't function is one thing, but checking in code that doesn't build is very bad. Perhaps you can get away with your method of version control usage if you are a single developer but as part of a team, I do not believe that this is the way version control is intended to be used.

What I do is develop on one machine then if I need to test on another OS/machine I simply transfer my local source to that machine and build/test the code from that.