Amen!!!

Every once in while I see something posted like this and then we get the next version of the technological panacea and not only does it not address the major underlying issue, if anything makes it harder to develop applications that match the user needs.

I agree with your article, you hit the nail on the head. I have one remark though:

Not all frameworks are written because what's available isn't up to par. A lot of the einstein-elvisses write frameworks because they think it's necessary as they're suffering from severe NIH strokes.

I also think that a lot of the developers don't want to use old tech simply because they think it will make them look bad.

This is great! However, it raises questions.
If all we need is VB3, then why did you not continue to develop your framework in it's original vb form? Why did you 'take advantage' of .net technologies, if they provide no ultimate benefit?
VB3 and COBOL (both of which I am intimately familiar), and I add now, VBA are no longer being used by me because they were not easily testable. OO languages like C#, vb.net and java are MUCH better in creating verifiably testable code. The practice of TDD is enabled by these languages and while VB3 might be just as fast from the users point of view, I believe proper use of TDD can demonstrate that more recent code CAN be better code.
Your last paragraph is a GREAT argument for the user of tools in organizations like bizTalk that automate graphically the execution of processes that are important to the business.
Perhaps that is why such tools exist and why developers do not understand them.

This is actually pretty ironic when you consider the source.

Bottom line, most "developers" trash "app generators" because:

"I don't have enough control."
"It's too much like magic."
"I don't know how the code is written."
etc.

Yet, with a product like Iron Speed you can create a usable applications in a fraction of the time, cause you are letting the tool deal with the plumbing, eh!

But, isn't this what you are talking about. Make application development about telling the tool what you want, what rules to apply, and it takes care of the rest?

Actually, I think we are getting closer. With MDA/MDD and things like Windows Workflow Foundation things are becomming more declarative. The bottom line is most business apps have 3 basic forms:

1. List of some item/entity.
2. Single edit form of some item/entity.
3. A form to launch a data processing task.

Within each entity you define the rules such as what attributes to show on the list, which to show on detail. How to validate individual attributes and how to validate the full entity. The entities generally have various states and the rules vary by state.

We are also getting closer to "software factories" where you use a tool to describe the above, and it writes the code. Oh, and your factory can create a 2-Tier Windows/Server app or a 5 tier distributed app with a service layer for a .Net or J2EE server all from the same declaritive meta-date about your app. When we get here business application development will be efficient!

BOb

Y'know what drives me nuts?

Software is the one field in which everyone from the janitor, to the bell boy to the nurse to the lab technician to .. u name it .. tells the doctor what to do - as the patient is dying.

And lets take the issue of "Inter process communication" -

RPC
DCOM
MTS
.NET Remoting (over tcp)
.NET remoting (over http)
.NET Remoting (over IPC channel - for single machine)
Web Services
Indigo
WCF
WTF

... Does the end user really *care* about all those acronyms? NO HE DOESN'T.

So I have to stop the train and ask "Why do we need Indigo"? Because it's a better way of doing, what we've been doing for the past 20 years? - try telling that to the customer.

SM

If I'm a consultant called into a company to build a line of business application, I have two "users," the application users in the accounting department, AND the inhouse developer who must maintain the application. In this sense, it does matter a great deal to the user whether I write the application in c or vb.net. It does matter if the web server is running cgi or asp.net. One of the reasons that software is such a mess is that developer only considers the front-end user (accounting office), and not the back-end user, the support staff that needs to keep the application running. I see the latter user as the driving force behind the technology wars.

I feel that a lot of the platform innovations (java, .net, etc) is of great benefit to the IT user, the people responsible for maintaining applications. They are also the ones that choose the back-office infastructure (windows or unix, oracle or sql server), so its hardly surprising that MS and Sun have put so much effort into java and .net. Mort benefits from this, while Elvis suffers. Mort can get paid as much as $75k, while Elvis must settle for $90k.

I really doubt that your explanation for offshoring holds much water. You said "our users feel they can get the same crappy software at a tiny fraction of the price by offshoring". Replace 'crappy' with 'great' and you have "its no wonder users prefer to get great software at a tiny fraction of the price of developing the same great software at home." Perhaps Elvis is partially responsible for the offshoring. Consider Thoughtworks, a the ultimate Elvis corporation's offering "We allow clients to capitalize on the economic benefits of a global work force, while leveraging ThoughtWorks proven delivery expertise. " (wwwDOTthoughtworksDOTcom/services.html). I suspect it is just like everything else ... jobs go oversees so the big boys can make more money. Mort looses his job, and Elvis gets cut to $75k. Suggesting that rank-and-file developers are responsible for this is gratuitous self-guilt/self-hatred.

I disagree with you on this one! Are you suggesting that software has gone backwards since VB3? I think software has become much more complex since then; what our users DEMAND from software is far greater. Intergration to telephony, pushing software out onto devices (pocketpc's, smartphones, etc), offline capabilities, work flows, accessible from anywhere, and a whole load more. These are capabilities that are now very simple to include in today systems. In VB3... you'd have been spending lots of money on hiring really smart people to do these things.

In a previous project, contractors were able to take their pocket pc onsite, jot down their measurements in their own handwriting using digital ink, get home, connect up to their home wireless network, press "GO!" and that's it. Job done. They used technology very passively. In the era circa-VB3, they'd probably have had to take a trip into the office, duplicate what they had in scrawled on their paper notepad, into a bulky, slow, difficult to use data entry application. Ask if they want to go back to that?

I refuse to believe that we haven't made progress on behalf of users.

I'm proud of my work within software, not because I get to tinker with 'cool' technologies, but because I see my software solve real business problems without people really knowing they're using my software. Like the example I provided earlier, I can now make my software more passive, so people focus on their jobs not on the technology that makes it possible.

Perhaps we can draw a comparison to primative man vs modern man. We had legs then... and arms, and a brain that was just as capable of learning. 10,000 years ago man could walk, he could run, he could think problems through. He could do all these just as well as we can today. I'm sure even 10,000 years ago, we were physiologically able to put a man on the moon. Why didn't we? Because we didn't have the background knowledge we've gained over the last 10,000 years. We're in the same situation with software right now, we could do the basics then, capture data, store data, etc. These are the basics that haven't changed (walking, running, thinking, right?). It's the more advanced things we do now with software that we couldn't do then, just as primitive man couldn't go to the moon. Does this make any sense, or am I just rambling!?

Anyway, it's all a matter of perspective. You've got to look past data entry forms in the traditional sense now. That is sooo 1990s! We've moved on! ;)

Well, well...should we expect a BusinessRules class that does more than validations? Help build adaptable systems?

That would be a major paradigm shift;)

ps: I did notice you changed the name of that class in 2.0

Paul put it much better than what I could have.

I really love it how all the things one looked in awe for example in various Star Trek are starting to become real or even mainstream and when starting to write an application I always think very hard how to eliminate steps that may seem necessary at the first sight.

Reading Rocky's blog I notice several false dichotomys.
While I agree with the sentiments, some of the articles example's are a tad off. Off shoring is more the fault of the developers here than the 'mean, greedy' corporate executives.
Rocky, assumes speed of execution is the determinant factor in user perspective of what makes good software. The fact that VB3 create very fast screens is irrelevant to the discussion.
Rocky acknowledges that the user is looking for improving or better software produced with the advancement in technologies. Speed of execution is a small and arguably insignificant part of what makes new software better than older software. As he points out, usually new software is SLOWER than old software from a raw execution point of view. After all if speed of execution was the major issue, we would all be writing in assembly language on a single computer.
I live in a company that has mission critical applications written in Ms Access 97 and are writing new mission critical applications in Oracle Forms. I am the only developer in CMMI Level 3 organization that writes in .NET for serious applications. I know those developers using the older technologies are writing badly designed, inflexible, highly coupled functionality and insist that is the only way to do it. Older technologies may have been faster or they may have been slower. It doesn't matter, its the patterns, practices and processes learned and used by the developers that make good software. We do a bad job of that and I agree with Rocky about the results.

One aspect of this issue that I haven't seen mentioned is cost to the user. This is just as important as ease-of-use and performance issues. Frequently, when we are faced with the prospect of 50% faster, but 10X more expensive to develop, the user will choose to take the slower, cheaper approach.

Does Flash make the user's job easier? Perhaps not, but if it makes the total cost of the operation cheaper, you do it! Do you spend $10,000 plus $1000 a year to automate a process that costs you two dollars a day to do manually?

Rocky discounts the argument that new technologies make it easier for the developer. Easier on the developer potentially means less cost for the user and faster response to change. These are things most users will want, too.

Well done! One of my favorite sayings is, "This is supposed to be getting easier! Not harder." Chris Stone hits the nail even harder! All I want as a developer is the tools to give my clients what they want without having to re-learn the same old tricks with different languages.

Thanks for a great post.

Thanks for this! And yet another Amen!!!

I do consulting too - and nothing makes me cringe more than going into a client and seeing yet another home grown app framework sitting on top of .NET - often times using 6 layers of abstraction and onject orientation to, essentially, push records into and out of a database the same way we have been doing for 20 years.

If the most complex business rule you can think of for an app is "make sure the date reads in the correct format" (or any other trivial validation) - perhaps you should stick with vanilla typed data sets.

If you really want to deliver value as an app developer, spend about 100% more time on the UI - make it a better user experience (and no, not more chrome - think Google).

Of course, it could be that Rocky is just having a bad month. CSLA 2.0 going well?

Funny, I was going to mention Oracle forms as an example of a tool that is geared directly at the business process application developer. The 9i version I used in a class deploys an n-tier application - the front-end uses a Java applet and you have a Java app server in the middle-tier.

Oracle also has an interesting product called OracleDB that lets you easily build databases and database driven websites online, kind of like the Access of web-based data-driven websites.

Fujitsu and Savion both have products that combine forms and common UI constructs with workflow and business rules engines, and will manage your data for you without you exactly understanding that you have a database.

Microsoft is also moving towards this with Sharepoint/InfoPath/BizTalk, although anyone who has actually tried to do it knows that this is not yet for Mort (at least the BizTalk implementation).

So the tools are getting there. But the IT folks are mostly not interested in these tools. We'd rather play with SmartParts and WebServices.

I think as developers we forget that there is 'good enough'. We get so excited about all the new toys that we want to use them in everything. In my little world, the customer is interested is getting the functionality as quickly and cheaply as possible. The technology is very much secondary.
A case in point, we had a developer put together a web form for one of our customers. This thing had a database, custom reports, layers of abstraction and after two months it still wan't done. I got the job of actually bringing this thing to production. A 30 minute conversation with the customer revealed that a simple form emailer would do the job.

As my Grandpa used to say "Every tool has its use."

When we can deliver innovation, we do. Think of the original Mac, the MP3 player, the DVD player. When we can't deliver innovation, we still have to sell. So we argue over standards as a way of differentiating ourselves from our competition.

Amen!

Man, thanks for making me feel better. I've been trying to run a java app on a mac for 45 minutes. Apparently java is the 'de-facto standard' and comes pre-installed on this mac which is meant to be the bees-knees of user satisfaction.

Well, they blow, and in my frustration I googled:
"java apps are always badly designed" and got your article. So thanks for helping me not throw this piece of...

This is 2006, hopefully we'll build robots to meet user needs real soon. Problem is, their decisions will be overridden by the vendor.

.s

Overall I agree with what you're saying, but I disagree with the offshoring comment at the end.

Offshore developers will be able to reap the same productivity benefits as Morts based in the Western world. The same cost delta will exist, and the same economic forces that drive offshoring today will drive offshoring with any productivity increases that we enjoy.

The Morts of the world need to worry about moving up the value chain to positions that cannot be offshored (such as contact with customers). Non-creative, commoditizable job functions can and will be offshored.

Cast your minds back... back to a time when 12MHz was the fastest thing you could get (1988). DOS applications were the order of the day. The Internet didn't exist (well, not in it's current form).

I was working for a PC shop that dabbled in software development.

We used a tool called CLARION. It was basically a big database, forms and report designer.

A customer could walk in in the morning and describe a simple application (like one that managed Video store rentals) [remember Videos - VHS, Beta, etc]. By the end of the day, maybe 2, I'd have the whole thing written!

I haven't achieved anywhere near that level of business results since. Value for money from programming, really! It was Mort programming, for sure.

It works by:
- designing the tables
- creating simply links between the tables (external keys)
- placing controls on forms (like "drop down a list of Widgets here")
- (now here's the key bit) Inserting little pieces of code where the underlying framework didn't cope
- (and for the master stroke) Generate all the code for the compiler using a template system (with a template that was modifiable!)
- better yet, go back and change the underlying table... and your entire application is updated!

So... fast forward to current day. So many more options, so much more complexity, but users still want the same business value. Maybe in 1-2 years we'll be at that same level as I was in 1988 - to commemorate 20 years in the IT industry.

But with all this in mind:
- I wouldn't go back from .NET or Windows programming - ever. It allows our company to delivery beautiful applications that function just the way the user wants (mouse, keyboard shortcuts, meaningful messages when they cock something up).
- Rocky's framework is providing the plumbing to come some way towards that 1988 nirvana.
- CodeSmith helps as well (in fact, this is what got me interested in CSLA about 9 months ago)
- but we've got a way to go

So... I live in hope. One day these technologies, frameworks, code generators and application designers will merge. Software development (as we know it) will be gone. Morts will use this new super-tool to solve business problems, and the great thing is the Einsteins will continue to improve the "behind the scenes" frameworks, code generators, etc.

One day, when MS release a new XYZ technology (that revolutionises how applications communicate... again), all the Morts will do is recompile their design and whammy - the app will be updated!

Maybe then, when this happens, I'll be confident we've caught up on the technology that was available in 1988.

I should have been checking in here more often. Rocky... you absolutely nailed it... except for the outsourcing which I will comment on at the end.

I would describe my 20+ years in IT as a 20-year Mort career… with occasional Elvis moments to facilitate my Mort needs (i.e. I can Elvis when I have to… and often enjoy those Elvis occurrences.). In simple terms, I see the following as the major criteria for Mort development:

1) Development cost and time
2) Support cost and time
3) User requirements (did you cover them)
4) Platform required/desired features and future growth needs

I tend to think of this in terms of platforms, and not languages (i.e. client server vs n-tier rather than VB vs C# vs Java). My Mort years have spanned (yeah I know… been around a while)

Mainframe (COBOL)
Mainframe (CICS)
Mainframe (Natural/Adabas – 3GL)
Mainframe (Ideal/Datacom – 3GL)
Client Server (Powerbuilder – 4GL)
N-tier (J2EE, .NET)

Rocky said: “Software development is too darn hard.”

I agree, but would say it in a different way. I think the following is how I would say it: “The process of defining business application standards, selecting technologies, and preparing the required widgets for assemblyline development has become TOO DARN HARD (I like to use the word insane, but let’s just stick with too hard). Quality business application developers can always eventually turn any platform and technology choices into a manageable set of standards and widgets and techniques that lead to maintable applications. It is beyond obvious, however, that the required standards, techniques, widget accumulation dance has gone of the charts by the time we hit n-tier. I earned a very healthy contract rate for over 5+ years doing Natural / Adabas development. I kid you not (for you guys who started your IT careeer in the middle of n-tier)… my only required training and reference material was a Natural reference manual, a Adabas reference manual, and a 3rd party white paper on Natural from Price Waterhouse. I really wouldn’t want to go back to the mouseless world, but sometime on a weekend when I’m buried in a geek-book I think back to how I spent my “Natural” weekends. I have to believe is was more memorable than computer books. We built system after system using Natural that served our users well… they actually performed their jobs efficiently without dropdown selection boxes or clickable mouses (go figure). Anyway, client-server hit, and the buzzword of the day was “mainframe cycle costs”. By getting off the mainframes, and moving to client servers… the companies could save all of that mainframe money. I actually loved it… my $40/hr Natural rate turned into a $75-$85 Powerbuilder rate. Yahooooo! As a contractor, anyone knows… the best technology choice for the user is the one that leads to my highest rate. :) I always wondered if they saved enough on their mainframes to almost double the software developer rates. They seemed happy enough, so I guess so. Was Powerbuilder (client server) harder than Natural Adabas… to get back to Rocky’s point. Yes. Instead of procedural template code (standards) we moved to code packaged in events… and as we know, there are plenty of them. :) We moved to a much improved UI, but with it came additional learning curve (datawindow was worth any additional learning curve and then some). It was certainly harder in respect to “coding standards/techniques)” because “out of the box” was a bit of blank page with many more options (procedural code … i.e. PFKEY processing doesn’t present too many options). In hindsight, the move to client server from Natural / Adabas was obviously worth the “added development complexity”… i.e. the net positives more than made up for the negatives of increased development costs, desktop deployment costs, etc. The companies got to move away from their mainframes and those intereting guys in the back rooms that ran them. :) So this was a case of added platform complexity being worth it. Now ask that question about moving from client server to n-tier (web or win). The buzzword of “mainframe cycle costs” have been replaced with “scalability” and “webify” and “connect-the-world”. I see that added cost of moving from client server to n-tier to be TOO HARD… no, I see it as INSANE. Like I said before, good developers will eventually carve out workable solutions from the black hole we call .NET or J2EE… but just ask yourselves how long this took for any project team you were on from the start (i.e. a team charge with making these types of technology choices). I was on one of those teams… we were talking about replacing a rather large Powerbuilder application (with very robust/complex UI) with a .NET solution. The user’s/companies main reasons were “scalability” and “part of the app needed to be on the web”. When pressed, they were not having any performance or scalability issuses currently… but they had read the hype and thought they might. L Too me, scalability is probably a red-herring for 90% of the typical business application needs. Unless you are cranking out an EBAY or Amazon, I just don’t see it. I’m sure I’m about to get feedback on this one. :) That said, the web need issue is the one that is driving this platform, IMO. Even when you say… my application only needs 10% webifying… it gets messy. If you are starting from scratch, and .NET / CSLA solution gets it time up to bat even for an application that only needs 10% on the web… who knows when that changes to 50%. And once you say “YES” to web needs, why not say “YES” to n-tier and scalable?

Surely the web is the only reason Mort’s are tolerating the black hole the vendors have created. I would be the first to say duct-taping a UI development platform around HTML and web servers isn’t pretty… but come on… Gates has a lot of money. No way you can justify the state of things in IT. For those of us who have been here 20+ years… we know better.

I think I had a point … and I think it was agreeing with Rocky on the “Too hard thing”. Now for the disagreeing….

Regarding outsourcing....

Rocky said:
"If our tools did what they were supposed to do, the Mort types would be so productive there’d be no value in offshoring."

You can't out-compete, out-produce, out-tool 1/10th the $pay. We live in a world where corporations are sovereign... the bigger, more global the corporation, the MORE sovereign. Trade policies and economic regulations are set and written by corporations, not democracies... and CERTAINLY not by Mort’s or Elvis’. I believe globalization is inevitable. I also believe it’s this world’s best chances at the long overdue leveling of global social justice (i.e. I’m a huge fan of globalization in the long run). That said, this US Mort predicts a short term devastation to the middleclass Mortdom in the US… particularly in our IT industry. I heard the other day that college kids are already figuring this out… enrollment in IT degrees is way down, civil engineering is way up. If college kids are wise, they will test every career choice with the question: “can this be outsourced at the sole discretion by CEOs?” The market has certainly not been efficient at bringing the Mort’s more user-friendly tools, but just watch how fast it reduces labor costs for US CEOs.

Sorry about the non-CSLA/IT rant… but Rocky started it with comments about “outsourcing”.

Mike and Andrew...

Maybe Rocky will climb down a few posts and comment again. This is indeed a great discussion! Wish we had more like these at .NET user groups, where the focus (at least in Chicago) always seems to be the latest neato code generator, or ORM mapping tool, that the Morts among us will never use - mostly because they pale in comparison to stuff we have already seen in our years pre-.NET.

The comment about scalability needs hit a nerve for me. Here is what happens. Most custom dev projects are approved by execs who, with good reason, are hoping for their companies to grow much more than they really are likely to grow (I have been at clients who insisted that they were going to grow at 50, 60, or 100% per year - ***industrial clients*** - whose stocks trade at a PE ratio of 2). Scalability is always a requirement because, to say "it doesn't need to be scalable" can too easily be translated to "I don't think our company would grow much". Which of course, is like going to church and screaming blasphemous obscenities. May or may not be true, but certainly will probably not be welcome.

In other words, nobody will every admit that an app doesn't need to be scalable.

Dear Mr. Lhotka

First, thank you for raising a very important and all too infrequently discussed topic within the IT community. I hope you will consider the addition of these comments to your blog to stimulate additional debate and continue this essential discussion. I would like to address some of the points you raise in your “rant”.

First, software development is NOT hard; at least not in the way you imply. If Mo, Larry, and Curly were to attempt to build the Empire State building they would never get past the first floor. Likewise, Mo et al, would find daunting the task of creating a simple “Hello World” application. The real problem is that clients who want to build the Empire State building (or a 7-11) actually look for Mo or Larry every day. Why? Because Mo has a business card that has “software developer” printed on it; no real training, to systemic rigor, not even a true apprenticeship. Just a business card and some experience writing code.

To extend the analogy, Mo has been able to learn the art of brick-making, maybe even brick-laying; but, Mo not’s a professional engineer – engineers deal with complex systems on many levels. No, Mo is way over his head, so of course he finds real development “too hard”.

Your use of the word “we” in the first, second, and third paragraph is illustrative. You see, Mo think’s he and his pals are the “building industry”; Mo and his pals do not see themselves as part of a larger industry. Mo et al are “we” to Mo. This is common myopic view of the programming world from the inside. Mo et al do not understand that they only have a limited subset of the skills to drive the industry; “we” is a much bigger group.

Mo considers himself an artist since he can fashion any number of lovely bricks out of mere clay. Mo also considers himself a genius because he can construct walls of great height and breadth. Very few cathedrals would have ever been built without the masons: Mo, Larry, and Curly. However, throughout the early centuries of their construction, Mo’s cathedrals routinely fell down and killed all the parishioners.

In 1506, Mo could blame collapsing systems on “acts of God”; but in 2006, Mo’s IT equivalent must look for other excuses. But the underlying cause is clear, then and now. Engineers must design and build complex systems; Mo and his “buds” just do not have the engineering discipline to understand the totally of the task. Symptomatically, Mo rants about the size of the bricks and other the idiosyncratic arguments about pre-built walls or the use of the ABC brick kiln or the XYZ model.

As in the 17th century, some Mo’s worked hard to understand and teach themselves the engineering disciplines necessary to build structures that didn’t fall down. A few were actually successful in making this transition. By and large, however, the technology matured only when a new breed of erudite, trained, and disciplined professionals emerged. And emerged in sufficient numbers; the study of engineering has been a recognized profession since in 800 B.C. But, the “cathedral bubble” had grown so quickly that Mo (the neighborhood kid that made mud pies) was the only skill set that a village could get.

For the last ten years or so, the world (like the forlorn parishioner of 1506) has grown tired of getting hit on the head by Mo, Larry, and Curly. You are correct, Mr. Lhotka when you say, the “users” don’t care about the bricks, or for that matter the underlying engineering principles. Your use of the name Elvis/Einstein gives away the game, however. Forgive me, but Elvis could not write music of any complexity and Einstein was always the first to admit he was a theoretician and could not be trusted to build anything.

If you had used names like Shannon, Edison, von Neumann, Wright, Ford, Goddard, Sikorsky, Lockheed, or Kelly Johnson, then you would have been on the right page. Believe me, Mr. Lhotka, I mean no disrespect, but you strike me as someone who has grown up with an interest in software, and probably has a C.S. degree from a modest community college. Am I correct?

Now is the time for the Engineers (capital E) to take over from the brick-makers. Complex computer systems still need “bricks”, but well engineered bricks with known properties and interface standards. In 1840, Enid Buckholtz declared that 11-story buildings where too hard to build. Guys “making bricks” have cobbled the software engineering business to this point, but no further – lest we declare (as Mr. Lhotka has implied) that buildings taller then 10 stories can never be erected.

Myths and Half-Truths:

While the underlying sentiment has some validity, Mr Lhotka's post/rant is an oversimplification.

We (the s/w community) build frameworks in the hope that we can leverage them, precisely in order to deliver end user value (btw, not all software serves 'business' needs; consider academic, scientific, military, etc).

The fact that some frameworks fail to achieve their goals does not invalidate the concept.

In fact, the whole history of software developemnt has been to build layers of tools and abstractions; otherwise we'd all still be programming in machine language.

As for 'users dont care about... ', the fact is that they would care very much if the features and applications they want couldn't be built or weren't reliable. And often what makes it possible to build anything at all, let alone anything useful and reliable, is by re-using existing work.

Not necessarily reusing as source code, or classes, or patterns, or libraries or componenets or frameworks, but often some combination of such.

What is Visual Studio, but a framework for building Windows apps?
I remember, when learning to program Windows in the early 90's, how much effort was involved. Then came VB (btw, VB3 might be fast, but it has definite scalibility limits). Today it is trivial to build your basic Windows app, because we have this set of resuable capabilities.

Ironically, however, the average VB developer still writes spaghetti code, and in moving to C# or VB.NET, I've seen a lot of improvement. And users *do* care about spaghetti code, although they dont realize it, because it manifests as buggy and unusable and hard to adapt to new needs, which translates to expense and aggravation.