Extreme Programming With Vb Classic

Given that you can do RefactoringInVbClassic, is it practical/desirable/appropriate/beneficial/... to practice ExtremeProgramming in VbClassic?

(Technical comments on how to do RefactoringInVisualBasic moved to that page. And suggestions on how to do VbClassicImplementationInheritance moved to that page.)

This is a vitally serious subject for the future of programming. The Professionals meets Mission Impossible ?

Class Modules and Properties in VB5 and beyond (for all the Office 97 tools and standalone VB5 and 6) give you encapsulation, multiple instantiation of objects with proper object identity and a useful object browser. It's true that there is no class inheritance (implementation inheritance).

Now VB sure ain't uniform like Smalltalk - but the great news is that it's less strongly typed than Java - I trust that really encourages many of the people around here. ;-)

RefactorMercilessly most definitely can and must be done in VB. But we find the lack of uniformity and internal simplicity in VB makes it far more difficult for many of us to conceive the most simple thing for DoTheSimplestThingThatCouldPossiblyWork. This is a vital cognitive issue to have a grasp of, not just for future language and tool designers but for current XP coaches.

Familiarity with any language and environment does I believe matter a lot for DoTheSimplestThingThatCouldPossiblyWork to lead to dramatic C3 type results. What does the panel think on that ?

Familiarity with VBA and VB is a much longer and tougher road to travel. Yet the rapid feedback factor with VBA in Excel, say, can still be used to great advantage once the team knows its way around.

-- RichardDrake

Can you maintain a relatively flat cost to make changes over time in VbClassic? If so, the XP's DeferredDesignStrategy? will work. Can someone who has lived with a VB app in production tell us if this seems plausible?

I think there is no difference here between Visual Basic and any other language. If you refactor your code to make any action occur in as few places (classes, functions, or even macros) as possible, it is not a big deal to change functionality and therefore the design. I have really loved my own unit tests in this respect. I can copy whole pieces of functionality (mostly classes, but single functions and subs as well) to a new application and immediately see if it works. This way, programming becomes more "assembling pieces together" instead of "building everything from scratch". In fact, you library of functions and classes grows along with your needs. -- WillemBogaerts

Imagine for a moment that XP became the standard way of writing business software, and that, therefore, Microsoft wanted VB to become the standard tool for XP. What would Microsoft have to change about VB, if anything?

It would be fairly easy to develop a refactoring browser for VB, altho it might be considerably weaker than the Smalltalk one. Also something like the KentBeck testing framework, altho the one that Rational sells might do the trick. One difficulty might be following the OnceAndOnlyOnce rule without implementation inheritance [VbDotNet has this]. Interfaces-only can give a decent object model, but seems to lead to a lot of cutting-and-pasting.

For those interested the VbUnit TestingFramework is available. -BradTaylor

Detailed feedback should be available on a VBA5 development in around 3-4 months from around these parts. Would be very interested in others' views.

I believe that it should not take very long for XP to become a key influence on the standard way of writing business software. Big M might not be so slow to respond to this, given the trends outlined in books like CodeComplete, and VB is indeed their development flagship, at least while a clean-room Java and JVM is still blocked by the courts. But it's certainly possible to be wrong on the timing of perfectly rational trends. -- RichardDrake

Although I don't have much experience with Visual Basic, everything I know about it says that it will be better suited for ExtremeProgramming than C++. Even the culture is better suited for it, because VB tends to be used in places where there is little upfront design, where requirements change all the time, and where documentation is not perceived as important. The problem with VB programmers is that they never refactor and they do not write unit tests. And they don't program in pairs, play the planning game, etc. But I bet the hardest part is getting them to refactor.

Anyway, you don't need a tool to refactor. I've done heavy refactoring in C++, and was refactoring Smalltalk programs for half-a-dozen years before having a refactoring browser. The main requirement for refactoring is a nose (to detect CodeSmells) and a mind. A specialized browser is very useful, but not essential. --RalphJohnson

When using VBA in an environment like Excel, ExtremeProgramming with Visual Basic is very practical. Worksheets used as primitive interfaces allow the coder to focus on core logic at the outset. UserForms? can be built later, or forms can be imbedded in the worksheets themselves. Using the macro record button can generate marginal but correctly functioning code that can go through an immediate first pass refactoring before being pressed into use. Useful sets of refactored code can be exported as modules and brought back into other projects. Procedural code modules (procedure sets) can be refactored into classes. Implementation inheritance can be worked around by limited refactoring of single class modules in a class hierarchy.

Working with accountants tied to an external reporting driven closing cycle almost demands ExtremeProgramming techniques. First version can speed up the closing cycle, while later version either speed it up even more or improve the efficiency or maintainability of the code. When the programmer decides to RefactorMercilessly, non-programmers can maintain portions of the code where magic numbers (spreadsheet coordinate references) are involved. -- ScottHamilton

more: http://www.programmersheaven.com/zone22/articles/article289.htm

VbeXtremeTeam in 2004

This is a group of people making a good stab at ExtremeProgramming in VbClassic and VisualBasicForApplications, using VbLiteUnit as a UnitTesting tool.

Question about "When to clone a method" moved to CloneMethod.

One thing VbClassic did pretty well was to support changing code while it's running and then continue running. This is something the SmalltalkLanguage environment supplied, and it's quite helpful in TestDrivenDevelopment.

This feature got kind of a bad reputation in VbClassic because if you use it very heavily in a single run (typically lasting several hours), VisualBasic would sometimes crash, causing you to lose ALL the source code changes you had made during the session. That is, yes you could change the code and continue, but you could not save any of these changes to disk until VB successfully terminated the process. And when VB crashed, well of course all the VB windows holding your changed source code were lost. This led to TurretsSyndrome?-like experiences on many a (non-TDD) VbClassic project! ;-> -- JeffGrigg

CategoryVbClassic

EditText of this page (last edited January 31, 2009) or FindPage with title or text search