|
Cant agree more. I mean, if your development budget (and your profit margin) is big enuf, sure. If not, think of it this way: Did your client pay for the quality and features?
|
|
|
|
|
If it takes less time to complete the job using the buggy tool, I'll use it.
Certainly every development environment has more bugs than Notepad, yet no-one uses Notepad for stability reasons (some do because they fear IDEs).
However if working around problems and restarting after crashes takes more time than the new features saved, I'm more productive with the stable software.
For the software I'm writing, I always try to get it stable first because "Fixing bugs+Implementing features" is simpler and faster than "Implementing features+Fixing bugs" (every bugfix is a breaking change and can cause new problems in the other features)
|
|
|
|
|
That is why I choose SharpDevelop. From my experience, it seems to be stable, and allows you to work fast.
Pumk1nh3ad illustrates that Intelligent Design oft goes awry. - Ed Gadziemski
You did'nt get it. I over estimated you. - Josh Gray
|
|
|
|
|
I too like a little bit of both. But I use VS2005 since a couple of months (since beta 1 actually). Its stable and I love the way it lets me develop my software.
WM.
What about weapons of mass-construction?
-- modified at 12:08 Wednesday 23rd November, 2005
|
|
|
|
|
The poll is first asking: "I prefer a product that allows me to work faster"
but then the voting option assumes that the buggy piece of software with more producttivity enhancements will allow someone to work faster, and that the stable piece of software will be slower to work with. These options dont aswer the initial question, since I feel a stable piece of software will generally allow me to work faster.
Troy
|
|
|
|
|
I'm with you on this one Troy. I thought the same thing. I can't count the times I've had a buggy app GPF on me right after I fixed one of the worlds problems. In fact, just had one the other day where it barfed on me as I attempted to save my work. A buggy piece of software saving time? I think not.
|
|
|
|
|
What a dumb quesion.
A program that is not stable does not allow me to work faster!
|
|
|
|
|
is not always true 
|
|
|
|
|
Agreed, what use is an app that crashes every hour?
Besides, I usually find those so called "productivity" features are just gimicks that look cool at first, but you soon release are actaully getting in the way and you end up just switching them off. Better to concentrate effort on the key features of your product and usability
|
|
|
|
|
Jim A. Johnson wrote: A program that is not stable does not allow me to work faster!
Not true at all.
Let's say a program has some features that cut your work time by 20%, but due to crashes you spend 10% of your time restarting and recovering. You're still ahead.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Unfortunately for me, the time spent subduing my frustration, or in daydreaming about having the development team against a wall with an automatic weapon in my hands, reduces my productivity far more than just the time spent recovering from crashes.
Software Zen: delete this;
|
|
|
|
|
So take a xanax and get on with life.
|
|
|
|
|
Paul Brower wrote: So take a xanax and get on with life.
Actually, I "take a xanax 6 mile run and get on with life".
Software Zen: delete this;
|
|
|
|
|
I've tried many productivity tools that may be stable but are useless to me because they don't fit into my workflow. I can't imagine not having intellisense even though it doesn't always work.
Same goes for tools like make. Reliable, predictable and a royal pain to use.
|
|
|
|
|
Until it decides to open as Wordpad instead !
|
|
|
|
|
Ever heard term, "rule of thumb?" It is often claimed that the term originally referred to the maximum size of a stick with which it was permissible for a man to beat his wife. http://en.wikipedia.org/wiki/Rule_of_thumb
|
|
|
|
|
Give me productivity!
When you constantly have to pull miracles out of your hat like I do, this is an absolute must. I'm talking reacting quickly to the competition, customer/management feedback, and just getting it done within a very short time period and with good quality.
That said, of course stability is a factor. If the app crashes a few times a week or worse, corrupts files, then I don't want it. In that case, the app's instability takes away from its productivity. If it's too unstable, then its not productive period.
|
|
|
|
|
Hello,
I agree with you, the gains must outweigh the drawbacks. If the app is instable, the gained productivity is lost due to application failures.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
notepad were never designed to program applications... 
this way, why not using the plain old edit.com DOS text editor ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
-- modified at 7:00 Wednesday 23rd November, 2005
|
|
|
|
|
No good having a stable software if it takes you 6 hours to get a 1 hour task done. It'd be better to have a fast app that may crash once or twice but still get it done in under 1 hour.
|
|
|
|
|
|
I write dev tools all the time. they're never fully baked but always increase my productivity. in that sense, I'd rather have a half baked tool than a stable one that has less functionality.
If I'm writing it for me, then the answer is "I prefer a product that allows me to work faster"
if someone else wrote it, and I'm buying it, it will be stable before they get my money.
/bb|[^b]{2}/
|
|
|
|
|
The choices are:
- Smart but unreliable (productivity enhancements)
- Dumb but predictable (stability)
I'll take "dumb but predictable" every time.
I've had it with so-called "productivity enhancements" that crash, corrupt your data, and don't produce repeatable results. One C++ compiler (not Microsoft's), for example, couldn't produce a release compile predictably. Why? The compiler's optimizer chose different levels of optimization depending upon memory and CPU loading conditions. Compile a piece of code twice in a row, and the object code generated would be different between the two. That kind of thing is totally unacceptable in a production environment.
That said, I'm still a continual upgrader. At work, I insisted we upgrade from VC6 to VS.NET 2002, and then to 2003, as soon as they were released. Similarly, our target environment has followed the release path for Windows: 2000, XP, and 2003 Server. Visual Studio consistently meets my definition of dumb but predictable. When a new version comes out, I'll spend a while learning (and grumbling about) its quirks, and then go on.
Software Zen: delete this;
|
|
|
|
|
For a bit of sound engineering wisdom you offered up you seem to contradict it by first saying "I'll take 'dumb but predictable' every time". Then adding: "At work, I insisted we upgrade from VC6 to VS.NET 2002, and then to 2003, as soon as they were released." So which is it? My guess? you probably work for M$ based on the example you spew forth... Then you say: "Similarly, our target environment has followed the release path for Windows: 2000, XP, and 2003 Server". I say this: You take alot of risks in your environment and I would hate to be financing that! My "Engineering" preference is more conservative... Let people like you cause all of "it's quirks" to get worked out, then make the shift once the technology has been matured to the point of allowing me to weigh a much more real estimate in terms of cost and productivity increases versus risk and net value. 
|
|
|
|
|
What I was pointing out is that there is a second boundary to consider, one between conservative engineering practice, and resisting all change, good or bad. Projects in the latter category eventually can't be maintained, because the environment or tool set can't support the requirements for future development. I worked on one of those once; Marketing decided they didn't want to spend the time or money to convert an MS-DOS application to a Windows app. We had to stop selling the product (even though there was still demand for its functionality), because the customers would no longer accept running an MS-DOS application.
There are plenty of shops out there still maintaining code using VC6, without a valid business reason for doing so. Typically, their only reason for not moving to VS.NET 2002/2003 is a dislike for the changes in the IDE.
My insistence we upgrade was a considered engineering decision. It was based on a pilot conversion of part of our product from VC6 to VS.NET 2002. My recommendation was based on the success of that conversion. Similarly, our decision to support each new revision of the OS was based on lab testing. Note that we wait for released versions; we've never used beta tools or an OS.
CodeStalker wrote: you probably work for M$
No, I've worked for Kodak Versamark, Inc.[^] for 15 years now.
CodeStalker wrote: You take alot of risks in your environment and I would hate to be financing that!
I'm going to get flamed or derided for this, but here goes anyway: I don't consider a choice to upgrade a Microsoft development tool or operating system to be a substantial risk. My experience with using 20 years of Microsoft development tools and operating systems is that, by and large, They Just Work. Of course they have bugs; all software does. I've used compilers from IBM, Borland, and Watcom that break source from one version to the next; what compiled yesterday won't compile today, not without a rewrite. I don't get that from using Microsoft tools.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
