Re: Windows forms application without Managed Code?

See below...
On Sat, 03 Mar 2007 10:34:52 GMT, Daniel James <wastebasket@xxxxxxxxxxxxxxxx> wrote:

In article news:<nmggu2h90qk85up7s0c3p59vnbiha05s94@xxxxxxx>, Joseph M.
Newcomer wrote:
Note that as long as the development environment runs, there is no need
to change.

There's certainly no need to change it for what I might call routine
maintenance purposes.

If it were proposed to add significantly to application then it might be
that a newer environment and tools could bring sufficient benefits that
moving development to those tools would more than pay for the cost of
moving.
****
And that's why we still have a Win16 system. Wer would not convert the Win16 code to
Win32 for the sake of having a 32-bit version, even, if at this point, someone produced a
32-bit library of the sort we need. We've learned too much about the program at this
point, and want to do a major rewrite for other reasons as well. But we also recognize
that a complete rewrite is going to cost $50,000. At some point we're going to have to
convert it, but we have to see the 50K in benefits. And at the moment, sales are flat,
and there's enough to cover tech support for the existing product, having me do a bug fix
or minor feature addition every two or three years, and that's it.
*****

In that woolly phrase "sufficient benefits" I'm trying to cover the whole
gamut of features from a possibly more productive development environment,
better debugging support, more correct code generation, availability of
more and better plug-in components, more powerful language features
(supporting better defensive programming idioms) ... etc.
****
Well, I admit the time warp of going back to VS1.52c is getting weirder and weirder. But
the code generation is perfect, we need no plug-in components, and the language features
don't buy all that much at this point. Cost-benefit analysis is critical. As a
programmer, I say, "Sure, let's rewrite it in VS2005 MFC" because (a) I make lots of money
doing it and (b) I can finally trash that massively obsolete VS1.52c and (c) I can stop
worrying about segmented address spaces. But after the massive investment, we have, well,
essentially the same functionality as we had before. Nicer development environment, nicer
user interface, but, utlimately, it does exactly what it is already doing. It is
well-matched to its problem domain, and we don't see a need to add new functionality. Just
make a nicer interface. That doesn't justify the high cost, and I have a responsibility
to my client to not just take their money for the sake of taking their money. (But as
soon as he says "We have the money, let's do the rewrite" I've got a complete new GUI
design ready and waiting...as well as a better interface to our own library, which I've
now specified in some detail and know how to write)
*****

If one plans to add sufficient code to an old project it can certainly be
cheaper to upgrade the tools (and the project) than to do significant new
work with old tools.
****
In the last round of major upgrades, ca. 1999, I used the old tools and added a docking
toolbar, status bar, tree control, graphical 2D layout interface, and a few other
features, for a fraction of the cost of converting the program to new tooling. I would
have been happier doing these in VS6, but that just wasn't a cost-effective option.

Anyone who dealt with the Y2K disaster can tell stories about how it is cheaper to hack
existing COBOL code than convert to Java or .NET. I know one person who got quite wealthy
with an automated COBOL rewrite tool that added special COBOL code to handle Y2K. His
comment: "You can't rewrite 10 million lines of COBOL code in Java no matter how much it
makes sense to move to a modern development language."
****

That's not always going to be the case, though, as you say. Each case must
be considered on its merits.

You don't need dazzling visual styles for running code. This is part
of the mythology of apps. They don't have to look cool, they don't
have to be dazzling.

It was Ashot Geodakov who first brought dazzling features into this
discussion. As I read his comment I got the impression that he was talking
about useful "must-have" features, not visual styles.
****
There's a lot of fascination with coolness. Which might be fine if your market is
12-year-olds. But your typical business user needs (a) no changes that involve retraining
(b) no changes that add gratuitous cost to an upgrade without adding functionality (c) no
new bugs. Hmmm. I wonder what 12-year-old was hired to redesign VS6 into VS.NET, since
VS.NET violates all of the previous criteria.
****

Someone must think that "cool" apps sell better than merely functional
ones ... otherwise no software company would ever authorize the budget for
developing the glitzy timewasting crap that we see so much of today.
****
It is a problem of keeping programmers employed. If Microsoft hadn't decided to redo VS,
Office, etc. into their current forms, they might have had to lay off programmers because
the tools had reached a level of effectiveness where all they needed were fixes and
improvements, not major rewrites. Or am I being cynical again?
****

Software that works beats software that is flashy any day of the week.
Microsoft lost sight of this when they did VS.NET. It's modern, it's
flashy, it sucks, and it is full of bugs. VS2005 retains all the old
bugs and adds a whole lot of new ones, as well as having the same
horrible interface.

We're in complete agreement there.

Cheers,
Daniel.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Another great example of how Word 2007 "brings commands closer to the surface"
    ... trashing and replacing Word's total interface and method of operation was ... remake the entire Word user interface to produce these new features? ... since the "majority" of users don't create custom toolbars and ... Hey, folks, the "majority" of users also never create a macro, ...
    (microsoft.public.word.newusers)
  • RE: how to integrate ms project 2003 with a 3rd party system?
    ... features it might need that would make it more useful, ... about Microsoft Project ... alone system I want to develop does not interfer with MS Project but it uses ... MS Project as a main interface for user input. ...
    (microsoft.public.project)
  • Re: Could Falcon 9 compete with the Stick?
    ... >> Ed Kyle wrote: ... >> built to government specs, ... include this option, instead reducing the cost. ... features drive the first 90% of the cost, and the last 10% of features ...
    (sci.space.policy)
  • Re: Robots and astronomy
    ... interface to alternate sounds and generate sounds. ... tools that people don't see that come with a Windows OS. ... In 1989 I had dim features in my ... are made to be precise in a factory and repeat millions of sequences ...
    (sci.astro)
  • Re: Agile developement ... more than just extreme programming ???
    ... then we can more or less ignore the cost of deleting code. ... design, then we could begin to work on, doing things incrementally. ... features might be delivered before full robustness is put in. ... - How much learning about the application comes from early release of some ...
    (comp.object)