|
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;
|
|
|
|
|
Gary R. Wheeler wrote:
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.
Sorry, but the typical reason vor not moving is that going from VC6 to a newer Studio is a lot of work. An in a short term view its work which brings nothing. (changing the IDE/Compiler brings normally nothing for the product because you still have the same code/functionality)
So you spend a lot of time (=> money) for nothing (short term view of the salesperson/customer)
I don't say you shouldn't upgrade espacially in a long term view there is no way to avoid it if you want to be competitive.
But you also have to compare the benefit with the cost?
for example:
7 licenses for VS 2005 costs over 7000 €/$ (a rough estimate) and than you have at least 1 weeks before the developer learned to work efficient with the new tool
(7 users * 5 days *average cost of about 70 $ = 2450)...
This is nearly 10.000 Bucks!!!! thats a lot of money
--
nobs
|
|
|
|
|
16 years in the PC software industry has taught me that software will always crash. There are just too many variables that *no* software developer can take onboard, not even the mighty Microsoft.
So, software that allows me to do my job faster and better will always be more useful. I can cope with crashes and bugs. That's why they invented auto-save.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Michael P Butler wrote: I can cope with crashes and bugs.
But can your customers?
You sound like most of the smaller vendors I've dealt with who rate success by getting that latest release out the door, on schedule, regardless of what might be wrong with it. The "O'well" mentality is just a highly contagious disease that hurts everyone elses productivity. You probably save time for yourself, but I can all but guarantee you not saving time for those poor souls who have to waste their time reporting bugs back to you.
I'll remember never to purchase any software with your name on it. I've got better things to do with my time like test my software first so my customers can get their jobs done on schedule. Do it right the first time!
|
|
|
|
|
bob16972 wrote: But can your customers?
My customers always get the most solid product I can produce. I wasn't talking about my customers, I was talking about what I feel is acceptable for my own use.
The poll was obviously inspired by the less than perfect release of VS2005 and it was from that base-point that I based my opinion. The productivity boosts far out-weigh the annoyances and bugs.
bob16972 wrote: You sound like most of the smaller vendors I've dealt with who rate success by getting that latest release out the door, on schedule, regardless of what might be wrong with it. The "O'well" mentality is just a highly contagious disease that hurts everyone elses productivity. You probably save time for yourself, but I can all but guarantee you not saving time for those poor souls who have to waste their time reporting bugs back to you.
Maybe you should ask my clients. My work is always well received. I'm never happy until I have a solid release. I hold my software to a higher standard than the work of others because I know that my non tech users haven't got my threshold for software problems.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
One could only logically conclude that software written with buggy tools probably has bugs within it. Saying the buggy tool is only buggy for you while your coding and compiling but your compiled products are clean and free of defects from that product is not a logical conclusion.
If a vendor cut corners on their development tools, would their runtime be in any better a state?
|
|
|
|
|
bob16972 wrote: One could only logically conclude that software written with buggy tools probably has bugs within it. Saying the buggy tool is only buggy for you while your coding and compiling but your compiled products are clean and free of defects from that product is not a logical conclusion.
Actually one could logically conclude that whether or not a text editor has any bugs is irrelevant to what the compiler generates.
Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
|
|
|
|
|
I guess you should read the survey again...
"If you had the choice between using a product that increased your productivity but was buggy, versus a product that was rock solid but missing some time saving functionality, which would you choose?"
third party products can include class libraries, controls, and dll's as well as IDE's and compilers.
They have time saving functionality in the sense that they are already written and you drop them into your app. However, if they are buggy, your customers will soon realize this as they use your product which includes their source code one way or another.
|
|
|
|
|
You're on the right track as my thoughts. I see too many developers who make decisions based on what's faster and easier for them. Software development is about making the lives of customers easier, not the life of the programmer.
To comment on bugs...I'd rather have software that does what it says it does without issue but be lacking in features than software that does more but doesn't work well or crashes.
|
|
|
|
|
Harrier wrote: Software development is about making the lives of customers easier, not the life of the programmer.
5!
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Harrier wrote: not the life of the programmer.
I was with you till that. Computers are tools for anyone. They are supposed to make the lives of everyone/anyone easier including developers.
That said I think we need to clarify what we are arguing about. There are two areas that pertain to this discussion: IDE bugs and Compiler/Output bugs. Compiler/Output bugs are 100% unaccpetable, IDE bugs are up to the tolerance of the developer.
Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
|
|
|
|
|
I guess you should read the survey again...
"If you had the choice between using a product that increased your productivity but was buggy, versus a product that was rock solid but missing some time saving functionality, which would you choose?"
third party products can include class libraries, controls, and dll's as well as IDE's and compilers.
They have time saving functionality in the sense that they are already written and you drop them into your app. However, if they are buggy, your customers will soon realize this as they use your product which includes their source code one way or another.
|
|
|
|
|
|
Actually I was thinking about beta software in general. I'm a bandit for installing beta products in the elusive search for new features that will make my life easier. Sometimes, though, I hit this point where I wonder whether battling with not-quite-fully-tested software is worth the "savings" in time I make.
Usually the answer for me is "yes".
The absolute worst, though, are products that seem like they work and which aren't fully backwards compatible with previous versions. You get sucked into the cool new features then hit a bug that won't allow you to move forward. Can't go forward, can't step back.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
It would be great if large apps like VS were more modular. That way you can add and add up your own comfort point.
You could also swop out parts that don't work that well.
Cheers,
Simon
> latest article :: animation mechanics in SVG
> blog:: brokenkeyboards
> another site of mine :: JeanPant.com
> CV :: PDF
|
|
|
|
|
CURIOUS??? Is anyone else whom has installed the VS2005 suite experiencing regular crashes of their Computer Browser service? It's now happening on 3 of 3 developer machines at my workplace... 
|
|
|
|
|
I have been installing and using it without trouble since pre-beta and never encountered this.
Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
