This project has moved and is read-only. For the latest updates, please go here.

Quality of Terminals

Topics: Developer Forum, Project Management Forum, User Forum
Jan 12, 2008 at 6:56 PM

This is a message to the devlopers and coordinators of this project.

At first blush and at looking at the screenshot, this is exactly what many people managing multiple servers need. Did you ever wonder why there aren't more downloads? Because the people who need it most, won't use it due to it'sd "APPARANT" low quality. And I say that respectfully.

First of all, most people working in business-critical environments with many servers they manage vy way of RDP, do ot want a tool like this that will blow up in their face. If one app is managing multiple RDP sessions and the one app wihc manages them, such as yours, generates an exception, then all RDP sessions are gone which can be a disaster in a 100%-uptime-required environment. Also, when folks are using a session, the last thing they want to worry about is the RDP session acting flakey. After all, they are already RDP'd in to the server to chase some strange problem where they need to look at events, services, log files, performance monitors, etc., etc. -- the last thing they want to worry about are sttrange UI issues. Micxrosoft RDP has evolved to that stage -- zero issues. It has never failed me in four years.

So, to download and use a product like Temrinals, the first thing any reasonable and experienced developer (30 yrs, myself) will do is look at the historical bug list. I did that and I must tell you it frightened me -- I work in the business-critical environment I spoke of -- very high-volume transaction processing systems on a highly fault-tolerant secure network, your bug list scares the crap :-) out of me. Every time you issue a release, it almost sounds like it is an attempt to stabilize but the next release has as many or more bug fixes -- either because they were always there, or because some new features (?) were added as part of the bug releases.

I propose you focus more on bug fixes and less on enhancements -- and only fix bugs reported for the most recent version (i.e., kindly ask people who report bugs for earlier versions to use the latest and see if they can
reproduce it). I suspect it is tempting to add all those features that you do but all it does is increasing the risk of failure and scare people off like me. If you don't think people out there feel this way, take a poll. This same thing happened witn a Src Diff/Merge open source project -- it used to be a rock-solid tool and then a new set of developers went nuts with adding unneccesary features -- to the point where now ris iddled with bugs and believe it or not -- it fails to compare files correclty -- among many other problems -- thereby destroying all confidence in it's most important feature. I told those guys the same thing and they did not reply.,

This is an interesting phenomena -- how one trades off quality with features. I see it going more and more on the side of giving up quality. You are not some corporation faced with the famous three trade-off factors: time-to-release, quality, and features. Since you are not a corp trying to make profits, you only have to deal with two of these quality and features. And you clearly lean towards features and less to quality. It's a shame. A better balance is needed, in my opinion.
Jan 14, 2008 at 7:30 PM
I am not connected to the developers, (except as a grateful user) but, whilst I understand your comments, I personally don't really think they are fair or accurate.

Short answer
If you want the stable version try 1.01 and see if you like it. If you don't mind being a beta tester that try one of the newer versions.

Long answer

It is the nature of products such as this, that stability will increase and decrease and increase again as features (and bugs) are added, bugs are fixed etc, so the main criteria is not whether there are bugs (or how many) in the latest release, but whether there is a stable and useful version and I think this project does have that in 1.0 (or maybe 1.01, which is supposed to fix problems that I have not ).

I have been using version 1.0 almost every day (except Sundays) for almost a year and I can not recall any problems with it, so I would consider it 'business-critical' quality. I have tried the newer version 1.6f, but there are bugs in it which make it un-useable (eg the "Rectangle '{X=0,Y=0,Width=0,Height=0}' cannot have a width or height equal to 0." error that others have reported, so I will continue to use 1.0 until the newer versions become more stable. Some of the newer features are of no interest to me, but others (such as connecting to VNC or Citrix servers) are, so I will continue to monitor this project, but meanwhile I will continue to use 1.0. I am not sure whether the developers would agree, but I consider 1.0 or 1.01 as the stable release and 1.6a to 1.6f etc the alpha/beta versions and we the users are the testers or those versions. I'm not even sure if 1.6 is feature complete yet. (Version 1.0 and 1.01 are cleared labelled 'production' so I am assuming the developers do agree with me). So there really has only been one version on which you should judge the project. The nature of the Codeplex forums make it difficult to determine whether the bugs you are reading about apply to the release or beta versions.

Your suggestion that bugs should only be fixed in the newest version, is not ideal, in that, if I encounter a show-stopper in the stable version, I would like it fixed, rather than being forced to upgrade. However in practice, I would suspect the developers do not have resources to do this. The best compromise is that there are two supported releases, a stable version and the latest version, but sometimes even that isn't practical.

For what it is worth, I remember (years ago) beta-testing a product which was away ahead of its rivals in easy of use, but suffered from numerous bugs which meant it could not be used for real. But rather than fix the bugs in the current version, the developer(s) went through various re-designs/improvements, all with good intentions, but never actually got any releases which were really useable. And so the users drifted away, ironically to a product designed by one of the early beta-testers who got fed up waiting for a good release and wrote his own.

However, as already stated, I do not think this is the case with this project (otherwise I won't be still using it).

In a kind of weird reverse logic, sometimes the fact that people are reporting bugs (for a established project) is a good thing in that it indicates that people are using the project, and finding it useful, which (IMHO) says more about the quality of the program than anything else.

I must not be a 'reasonable and experienced developer' - I hoping I am reasonable, so I guess that means my 20 years isn't enough to be considered 'experienced' -) - but looking at the bug list isn't the first thing I do. In my experience, a good quality program used by thousands of users will usually produce more bugs if than a bad program used by a handful. So I prefer to download and try out the program first. Even at home I have two machines, one for real work and one for testing programs, but no-one (apart from other programmers) understood that, so I ended up saying that one was for work and the other was for games. (That got a bit tricky if they wanted to play the games, as I can only think of one game that I have bought in the last twenty years ).

Obviously all this in my humble opinion (and certainly no offence meant)

Regarding the source Diff/Merge project, if there was a rock-solid version, then why not just stick with that and forget about the latest versions?
Jan 15, 2008 at 5:36 PM
My favorites list has around 40 windows servers in it. Our IT team uses terminals daily to manage corp servers and Internet production servers in an 100% uptime environment. Terminals once in a while gives us a GPF error when we try to connect to a server but we just restart the application and it's fine. I had to come up with a workaround regarding disappearing toolbars but that was no big thing. Yeah there are some areas that need more polish. But overall it works just fine.

What we get out of it is a great tabbed multi-desktop terminal client with a ton of configurable options. It blows microsoft's remote desktop client away. It's not as stable as say VNC (a decade of development) or PC Anywhere (commercial, expensive) but it is plenty reliable for production use and offers a lot of free value. It's actually quite an amazing achievement. Maybe there is some commercial alternative out there that I don't know about that is much more stable and complete - but for our team Terminals is a fantastic tool.
Jan 30, 2008 at 4:30 PM
I had to use a release I got from another site (1.6) that was much more stable than 1.01 (had many crashes with it). And of course any of the new versions 1.6a~f are quite unstable. None is useful for me yet.
Jan 30, 2008 at 4:30 PM
Edited Jan 30, 2008 at 4:31 PM
Double post (not made by me but the site).