Careers: Interviews
World Application Expert: Rod Stephens
This week, Stephen Ibaraki, I.S.P.,
has an exclusive interview with Rod Stephens. Rod is
one of the world’s foremost experts in application
development in languages such as Visual Basic, and a
highly respected author of more then 10 programming
books and hundreds of articles.
****
Q: Rod, you are considered by many as the foremost
expert in application development. It’s a real
privilege to have you with us. Thank you for
agreeing to this interview and sharing your
experiences, wisdom, and vast skills with our
audience.
A: I'm glad to be here. I hope I can give people at
least a few useful bits of information.
Q: Can you describe your days as a mathematician and
at MIT?
A: I had originally planned to focus on logic at
MIT. I took a selection of mathematics courses
including several algorithms classes that were
cross-listed in the computer science and mathematics
departments. After a while, I decided they were a
lot more fun than logic so I switched my focus to
algorithms and computability. Some of the
algorithmic topics I studied included general
algorithms, parallel computation, systolic
algorithms, operations research, cryptography, robot
control algorithms, and graphical simulations.
As a teaching and research assistant, I taught a few
different levels of calculus and a couple of
computer classes. The first real commercial system I
worked on was a transshipment project for Gillette
done with Professor George Kocur who's still at MIT.
That project used operations research algorithms to
determine the most efficient methods for shipping
different amounts of product to different locations.
By my current standards, it was a very small project
but it still taught me a few key lessons. In
particular, it taught me the importance of dividing
a project into clearly separated and manageable
pieces. I worked on the user interface while George
and another graduate student worked on the
algorithmic piece. The separation was clean enough
that we were all able to do our work without
interfering with each other. It was so easy at the
time that I didn't even realize how important it
was. Since then I've worked on a couple projects
with less clearly differentiated tasks and they
really drove the point home.
Q: What sparked your interest in programming?
A: My father was a programmer back in the early days
when there were no computer scientists, just
engineers. I'd always been interested watching him
work. I remember trying my hand at simple games
(without much success) as a teenager.
As an undergraduate, I considered double majoring in
mathematics and computer science but didn't make up
my mind soon enough. I did take a few classes in
algorithms, graphics, and cryptography, though, and
that kept my interest relatively fresh until the
advanced algorithms classes at MIT really got me
going.
I've always had a feel for what a program is doing
and I found it very satisfying when things actually
worked the way they were supposed to. I find complex
algorithms and graphics programming particularly
gratifying. It never ceases to amaze me when you
dump a pile of constraints into a scheduling
algorithm and get back a perfect work assignment, or
when you shove a bunch of numbers into a ray-tracing
application and a realistic three-dimensional
picture pops out.
Q: How did you get into writing articles and books?
A: Early on, I wrote a couple of magazine articles
and some corporate publications more or less just
for fun. Later I was working as an independent
consultant (which I've done most of my career) and I
was between projects so I sent a letter to the major
computer publishers proposing a book titled "Visual
Basic Workouts." The idea was to show how to perform
some common tasks using Visual Basic 3. For example,
building scrolled windows and certain kinds of
classes, neither of which were included in VB 3.
These ideas actually predicted the popular
"patterns" literature, though in less clearly
defined terms. They also showed how to do a lot of
things that are better accomplished by the ActiveX
controls Microsoft later introduced.
Anyway, none of the publishers wanted "Visual Basic
Workouts" but two of them liked my background in
algorithms and asked if I would be interested in
projects they had in mind. The resume is really one
of the most important parts of an idea submission to
a book publisher and they liked mine. The publisher
wants to know whether you have the background to
write something interesting and whether you have the
skills to write a 100,000+ word book.
The John Wiley & Sons project was an algorithms book
and "Visual Basic Algorithms" was the result. Wiley
asked Karen Watterson to review my final book
proposal and she liked it so much she asked me to
write an algorithm column for her publication
"Visual Basic Developer." All this lead to a dozen
books and more than 180 articles.
Q: I have been reviewing your book on Visual
Basic.NET and Database Programming and I highly
recommend it. What are your most recent books and
articles and can you provide five useful tips from
each?
A: My most recent books are "Visual Basic .NET
Database Programming" and "Visual Basic .NET and
XML." These cover fairly specific topics so any tips
taken from them will only be useful under certain
circumstances. Unlike, for example, my book "Bug
Proofing Visual Basic," which provides tips that are
useful on a much wider range of Visual Basic
projects.
Some tips taken from "Visual Basic .NET Database
Programming" include:
- Use MSDE (Microsoft Data Engine) to give
yourself a cheap and easy upgrade path to SQL
Server if you need better performance.
- Use MSDE/SQL Server "roles" and individual
privileges to control data access. Grant only
the privileges users actually need.
- Normalize database design to increase
flexibility. Then selectively denormalize it to
improve performance.
- Perform updates, insertions, and deletions
in the proper order to satisfy relational
database constraints.
- ADO .NET database connection strings are
complex. Instead of composing them yourself, use
the Data Link Properties dialog to configure a
data connection object and then look at the
connect string it uses.
XML (eXtensible markup language) is a mostly
text-based language for storing data. It's
really not a big deal by itself but the things
you can do with it are. Some tips taken from
"Visual Basic .NET and XML" include:
- Use the DOM (Document Object Model) to
manipulate the structure of an XML document. Use
forward-only readers and writers (XmlTextReader,
XmlTextWriter, and SAX - Simple API for XML)
when you need better performance and don't need
to work with the document's structure.
- Use XML to store and recover complex objects
in standard textual and binary formats. This is
called "serializing" and "deserializing" the
object.
- Package standard functionality in classes so
you can use them in DLLs and in the latest thing
in network interoperability: Web Services.
- Use XSL (eXtensible Stylesheet Language) to
provide different views of the same XML data on
the Web.
- Use XML inside an ASP .NET page to build a
"data island" that displays information that
changes infrequently.
Two of my most recent articles are "A ComplexNumber
Class" for Visual Basic Developer, and "Map
Coloring" for Dr. Dobb's Journal. Depending on how
soon this interview posts, those articles will
probably not yet have been printed.
While these also cover focused topics, they provide
a few interesting lessons that are more widely
applicable. "A ComplexNumber Class" shows how to
build a class that manipulates complex numbers. This
class demonstrates several useful techniques if
you're new to VB .NET including:
- Overloaded constructors
- VB .NET-style property procedures
- "Operator functions" (in C++ you can
overload operators such as + but in VB .NET you
need to use a function named something like
Plus)
- Overriding base class methods
"Map Coloring" is even more tightly focused. It
describes several different algorithms for coloring
maps so no two adjacent regions share the same
color. If a map is two-colorable (you can color the
regions with only two colors), it's easy to find a
two-coloring. Deciding whether a map is
three-colorable is NP-complete so there are no known
fast algorithms. In 1976, Appel and Haken proved
that all maps can be four-colored in polynomial
time. Unfortunately the algorithm that follows from
their proof is extremely complex involving literally
hundreds of special cases and I don't know of anyone
who has actually implemented it. On the other hand,
there is a very fast five-coloring algorithm.
If you just need to display pretty maps, five colors
is probably good enough and it will be much faster.
The moral is the theoretically "best" algorithm
isn't always the best solution.
Q: Describe future book titles and articles can we
expect from you?
A: All of the book publishers are moving to VB .NET
these days. I might be persuaded to write .NET
versions of some of my other books. "Visual Basic
Algorithms" would be worth redoing to cover some of
the new sorting and other algorithms integrated into
.NET. I would also like to expand it to cover more
business algorithms (network applications, work
assignment, scheduling, resource allocation) or even
make that a separate book if I can convince my
editor and myself that there would be enough
readers. If there's something you or your readers
think would be particularly interesting, drop me an
email.
"Visual Basic Graphics Programming" would also be
fun to rewrite. Support for Direct3D has improved a
lot since I wrote the previous edition of that book.
There's still room for improvement in Direct3D but
the basic drawing pipeline is sound.
While book publishers are all into .NET these days,
lots of developers are still using VB 6 and the
magazines are a bit more responsive to them. My
Visual Basic Developer columns will still cover VB 6
techniques at least some of the time.
Q: Can you describe some of the projects that you
have worked on and what tips you can pass on?
A: I've worked on some amazing projects. In one
project, a billing center was ignoring a printout of
overdue accounts because it took up a stack of paper
three feet tall every other day and the accounts
were listed in random order. Some customers owed a
few dollars and others owed thousands. We wrote a
simple application to capture the printout and sort
the accounts by balance due. Only the first two
pages contained customers with large enough balances
to take action.
The lesson here is that small things can sometimes
make huge differences. The billing center people
didn't know we could capture the printout and sort
it. After we had studied their operations for a
while, we found something easy to do that made a
huge difference in their ability to do their jobs.
In another application for the same billing center,
we wrote a more complex "screen scraping"
application to automatically review accounts and
disconnect service for those that were seriously
overdue. One morning the mainframe developers
changed the location of a field on the screen. The
new location was obvious to a human but our program
couldn't find it and incorrectly disconnected about
400 customers before we realized what was happening.
Working quickly with the billing center staff, we
wrote a program to put the customers back in service
and had it all fixed in a couple of hours. Only two
customers noticed they were out of service before we
had things fixed.
This project highlights the importance of different
groups working on related projects keeping in touch
with each other. If the mainframe people had told us
about the change, it would have been no big deal.
Some of the other projects I've worked on include a
fuel tax application for the State of Minnesota,
training software for professional football players,
and switch programming for telephone switches.
One of the strangest things that ever happened to me
on a project occurred on a dispatch system that
assigned several hundred repair people to a few
thousand jobs each day. Twice during the pilot tests
the system assigned a repairman to work a job at his
ex-wife's house. Fortunately the repairmen in
question recognized the addresses and called in for
different jobs. If we had thought of this during
development, we would have thought the odds of such
a thing happening were too close to zero to worry
about. And here it had happened twice!
There are two lessons here. First the users will
eventually find every conceivable way the software
can mess up. Second, it's good to leave a human in
the loop to correct the "impossible" mistake that
will eventually occur.
Q: Your VB helper web site at www.vb-helper.com,
receives more than a million hits per month. Can you
describe the evolution of this web site, its
purpose, and what you foresee in the future for this
key resource for developers worldwide?
A: The site started as a place for me to provide
support for my books: post descriptions, updates,
corrections, discussion, and samples. I immediately
started adding example programs, tips, and tricks
and now it contains more than a thousand examples.
Originally the site only contained example titles
and you had to download a Zip file to see the code.
Newer examples show you key code and a more detailed
description of how the examples work on a Web page.
You can still download the example source files if
you like.
Eventually I would like to convert all of the older
examples into the newer format. The site will also
contain more and more VB .NET code, though I know a
lot of developers will be using VB 6 for quite a
while.
I'd also like to do more with games, Direct3D, Palm
OS and Windows CE, and all sorts of other topics but
realistically anything too elaborate will take a
while. I am looking hard at Palm OS development
lately so I might actually get something together on
that topic.
Q: How would you contrast or compare the Java world
versus .NET? What’s the future of these environments
in the near and long term?
A: Each has its advantages and disadvantages. Java
has the nice concept of the "sandbox" where your
application is only allowed to do certain things.
For example, it cannot use Outlook to install
viruses. On the other hand, it's relatively slow and
not a very natural language unless you're a C++
programmer (but I'm biased towards Visual Basic
these days).
Microsoft is pushing Web Services hard as its
solution for Web connectivity. Web Services are a
lot easier than some of Microsoft's previous
attempts, but the steps to install them are still a
bit arcane.
In the long run, I think the cultural differences
will play a bigger role than the technical pros and
cons. Java programmers love Java (some partly
because Java is not Microsoft) and will probably
never give it up. Microsoft has a huge amount of
muscle in the development community so I would be
shocked if .NET disappeared any time soon. I suspect
we're going to have them both around for quite a
while.
I personally hope future versions of .NET place a
little less emphasis on the Web. All of the big
projects I have worked on have been mostly centered
on the desktop (sometimes with Web components as
extras). This version of VB .NET makes a lot of Web
programming easier at the expense of desktop
development. While it's clear that there's plenty of
room for new Web applications, neglecting the
desktop would be a mistake.
Q: What are the five top traps or pitfalls that
developers should be wary of and avoid?
A: A tough question. My "Bug Proofing" book spends
more than 400 pages on this topic so it's hard to
pick just five. If I had to make a short list,
however, I would focus on higher-level issues. Most
developers know they should comment their code
(although many don't), explicitly declare variables,
and avoid unnecessary complication. However, many
don't place enough emphasis on the processes
controlling the development effort itself. A mistake
in a subroutine can mess up that subroutine and cost
you some time debugging. A mistake in the
fundamental design can lead to a completely
worthless product.
So a list which may not be the TOP five but which
certainly contains five important issues is:
- Don't rush into programming. Build a solid
design before you start writing code. Developers
naturally tend to push towards coding because
it's more fun than design but a few hours of
preparation can save you hundreds of hours of
debugging.
- Avoid monolithic, closely integrated
designs. Compartmentalize the design. Breaking
the application into clearly separated pieces
allows developers to work on the pieces in
parallel, independently, and without interfering
with each other.
- Don't skimp on debugging, testing, and
documentation. Developers tend to allow
insufficient time for these tasks because,
again, writing code is more fun. Then when the
schedule slips, they often take more time away
from these tasks. If you don't debug your code,
it won't work. Guaranteed. If you don't test it,
how do you know if it works? If you don't
document it, how can anyone use it whether it
works of not?
- Don't think you can "make up time" later.
You cannot. It's amazing how often developers
see that every task has run long by 20 percent
so far but they still think they can make it up
somehow later. If you are not tracking to the
schedule, make some changes to the way you are
doing the work (add people, redesign,
recompartmentalize, reduce features, do
something!) or you will either continue slipping
or you will need to take shortcuts (probably in
debugging, testing, and documentation).
- Don't optimize your code until you know it's
necessary. This is probably the tip that's
hardest for developers to swallow. First make
the program run correctly and simply. Then make
it run faster if necessary. Many parts of the
application will probably be fast enough from
the start and you can save the time and
complication you might have added otherwise if
you had optimized them prematurely. Save your
efforts for the small fraction of the code that
really needs work.
Q: Can you share your 10 leading career tips for
those thinking of getting into the computing field?
A: A good place to start is your skill set.
Obviously you are more valuable to an employer if
you have lots of relevant skills. In your free time,
expand or update those skills. Build a Web site and
experiment with ASP, ASP.NET, Java, and Web
Services. Download the free demo for a language or
development environment and experiment with it until
you have at least some proficiency. Build some games
or other applications you can use yourself just for
fun. That will give you some goals to help keep you
focused on learning the new technology. Don't list
these secondary skills as your primary talents
unless you have a very thorough understanding of
them, but you can at least say you have some
experience with them.
With recent trends towards networked computing, many
applications integrate more than one major
programming discipline. For example, an order
processing system might include desktop, database,
Web, and PDA components. Gain some familiarity with
as many different pieces of the puzzle as you can.
If I'm hiring someone who will primarily do desktop
development, it still helps to know that they
understand the challenges of database design and Web
forms.
Breaking into a new field is always tough. Everyone
wants someone with experience. One technique for
getting experience is to join a temporary agency.
That can give you some basic experience with a
variety of different industries and programming
disciplines. Many developers meet their future
permanent employers through temporary work.
Join your local programming user's groups. They
provide a good setting for networking with other
developers. They often sponsor talks and hands-on
lab sessions where you can learn new skills. Many
groups also keep lists of people looking for jobs
and jobs looking for people.
Don't neglect the mechanics of the job search. Buy
several books on job hunting and read them. Write a
good resume and have someone else look it over.
You'd be amazed at how many barely literate resumes
are submitted to businesses every day. Resubmit your
resume periodically, particularly to big
corporations that get tons of resumes each month.
Practice your interview skills and dress
appropriately when you go to the interview. Follow
up after the interview with a note or phone call.
Probably the single most important tip for any job
seeker is to hang in there. Keep submitting your
resume to different companies, network with other
developers, make new contacts and persist until you
find the job that's right for you.
Look for the right group of people to work with.
I've found that the right group of people is more
important than finding a cool project. A really good
team of developers can make ANY project fun and
interesting. A bad development team can make your
life so miserable you'll be phoning recruiters
within a month.
1. Expand your skill set
2. Update your skill set
3. Get experience through temporary contracts or
agencies
4. Read job hunting books
5. Write a good resume
6. Practice interviews
7. Dress for the interview
8. Follow up
9. Hang in there
10. Look for the right people, not the right project
Q: You have a reputation for being plugged into the
stream of computing consciousness. What are the
hottest topics that all IT professionals must know
to be successful in the short term and long term?
A: Sometimes I'm not all that certain that I'm
plugged in. Often I see something that technically
is no big deal but that takes the programming
community by storm. On the other hand, something
that is technically wonderful is completely ignored.
For example, XML is little more than a slightly
baroque method for storing data in text files. It
was pushed hard by several large companies (notably
Microsoft in the .NET environment) right when
developers were trying to find ways to cope with a
proliferation of platforms (mainframe, desktop, Web,
PDA, pager). The fit was right so it looks like XML
will become a very important part of distributed
computing.
Similarly Java is really not a revolutionary
concept. The idea is to write code that can run on
many different platforms. That's basically what a
compiler does and we've had those for decades.
However, Java was pushed by big corporations
(notably Sun) right when developers were trying to
generate content on all these new devices. The
breakthrough is not in the technology, but in
getting all these different operating system vendors
to agree to support the same language.
In general, these sweeping trends seem to follow the
corporate and developer culture more than technical
achievement.
In the short term, these needs are filled by
XML/XSL, and by Java or Web Services. Whether these
are the best solutions in the long run, only time
will tell. You should at least have some familiarity
with them, however, so you understand the issues and
you can take advantage of whatever features they
offer.
Another topic worth monitoring is XP (eXtreme
Programming). This is yet another attempt to capture
the Holy Grail of software management: the ability
to produce reliable software quickly. I've had a lot
of luck in the projects I've been on using the
techniques described in the recent books. With
topics like this, however, you need to be careful to
separate the experimenters from the experiment. Many
of the groups working on these sorts of projects
contain highly experienced developers. It's not
always clear whether the same techniques will work
with just anyone.
To predict trends in the longer term, look for an
unsatisfied need (distributing content on multiple
platforms, executing on multiple platforms). Then
look for a relatively incremental improvement in
technology that fills that need. You usually don't
need to look for a huge revolution.
Producing quality code quickly has always been a
need. Perhaps XP can satisfy it. Perhaps something
else can. Source code control systems and project
management software should be able to help but
they've been around for a long time without solving
all of our problems so that's probably not the
solution.
One issue that may eventually slap the development
community in the face is software complexity. When I
started programming professionally, I worked at a
lab where 300 scientists shared a computer that ran
about 1 million instructions per second. Now my
personal desktop system runs hundreds of times
faster but it's barely powerful enough to boot the
operating system in a reasonable amount of time. The
reason for this poor performance is that today's
software is much more complex than it used to be.
The operating system in particular is hugely
complicated and uses a tremendous amount of
resources. Huge increases in hardware performance
are being eaten by huge increases in software
complexity.
Hardware speed has been increasing steadily for
years but it is starting to reach limits imposed by
the physics of these devices. Unless users suddenly
decide they have enough performance (which seems
unlikely), something must change.
One way chip manufacturers increased hardware speed
was to move to reduced instruction sets. Supporting
fewer CPU commands allows RISC chipsets better
optimization and pipelining. We can streamline
software in a similar manner. When I moved from C++
to Visual Basic, I was amazed at how much more
productive I was. One reason was that Visual Basic
is far simpler. It hides most of the ugly details of
Windows programming from the developer. Yes, it's
harder to do some things like dig into the Windows
event loop, but it was easy to learn to live without
those features. At some point you may be willing to
trade powerful language constructs for speed.
With VB .NET, Microsoft has added a new layer of
complication to Visual Basic programming. Now you
can build inheritance hierarchies. Using them, you
can build new ways to confuse yourself (the only
project I've worked on that I consider a true
failure died largely because of an over-complicated
object hierarchy).
It may be too late to remove features from VB .NET,
but I would love to see some reduction in the
complexity of operating systems. I don't need half
of the latest features and could sure use an
increase in performance. Lately I've been
programming for Palm OS and I find the limited
capabilities and memory restrictions on PDAs to be
strangely refreshing.
Saying an operating system has fewer features than
the last version is probably not smart marketing,
but I'd bet a lot of users would jump at the chance
to get a lean, mean, fast booting machine.
Massively distributed processing also shows great
promise in the medium-term. A couple groups have
already used idle CPU cycles on desktops to analyze
SETI data, identify promising vaccines for anthrax,
and find large prime numbers. I wouldn't be
surprised if companies with large computing needs
start discovering the huge reserves of untapped
power they already have.
Other technologies that are definitely cool but
probably won't be useful in the near future include
optical computing and quantum computing. They have
the potential to provide new increases in processing
speed, but probably not for quite a while.
Q: What would be your recommended top ten references
for the serious developer?
A: Even developers who don't manage software
projects should have an understanding of the
development process so you should read a few books
on the subject. Books like "Code Complete" and
"Debugging the Development Process" explain
strategies for controlling development rather than
letting development control you. My books "Bug
Proofing Visual Basic" and "Prototyping with Visual
Basic" explain how to do this in the context of
Visual Basic. All of these books take slightly
different approaches and each author has more to add
so, it's worth reading several.
"Writing Solid Code" talks about techniques you can
use to make code more robust at a slightly lower
level than some of these other books. Its examples
are written in C but the concepts apply to other
languages as well.
I've always found that studying complex algorithms
helps you learn new programming techniques that you
can apply in many different situations. They show
how to use linked lists, binary searching, hashing,
and lots of other useful methods for getting your
work done. They give you new tools and expand your
ability to devise your own tools. It's not
coincidence that algorithms are often the second
core sequence (after the intro courses) in
university computer science programs.
Algorithms have been around for a relatively long
time so there are lots of good books available. I
own a dozen or two including some that are rather
specialized (operations research, artificial
intelligence, cryptography), and my book "Visual
Basic Algorithms." Donald Knuth's "The Art of
Computer Programming" series is considered by many
to be essential reading. Thomas Corman's
"Introduction to Algorithms" and Robert Sedgewick's
"Algorithms in C++" are also quite good. If you do a
lot of numerical programming, you need a copy of one
of the "numerical recipes" books: "Numerical Recipes
in Fortran," "Numerical Recipes in C," and so forth.
More recently several design patterns and
anti-patterns books have become popular. "Design
Patterns" by Erich Gamma is pretty good. Some of the
others (particularly the anti-patterns books) spend
more text on formal definitions than on code so some
of them contain only a few useful topics.
Many programmers have no idea how to build usable
software interfaces so I strongly recommend a course
in user interface design. Finding great books on
this topic is hard, however, and most have very
different things to add to the discussion. "Art of
Human-Computer Interface Design" is a good
collection of essays on the subject. Alan Cooper's
book "About Face" adds an interesting view on many
topics.
My favorite design book is "The Design of Everyday
Things" by Donald Norman. It talks about the design
decisions that shape our everyday lives. Things like
why telephones are shaped the way they are and how
doors can help you decide whether to push or pull.
It doesn't talk about programming at all, but it
helps you see things from the user's point of view
and provides a nice break from hardcore computer
books.
Finally, I would toss in a copy of "How to Write for
the World of Work." This book gives the goal of
clear communication its rightful place at the top of
the list for work-related writing. It explains how
to avoid the techno-babble, jargon-filled, memoese
that fills the programming industry.
Q: You have so many accomplishments. What do you do
to relax?
A: We have two young children so who has time to
relax? Seriously, I do a lot of things including
volleyball, reading, and writing. The kids give us
lots of new recreational pursuits such as going to
playgrounds, swimming, and changing diapers.
Q: If you were doing this interview, what two
questions would you ask of someone in your position
and what would be your answers?
A: One question I'm occasionally asked is, "How do I
become an expert programmer. In particular, how can
anyone learn enough about so many different
languages and technologies."
The pithy answer is "one day at a time." You don't
need to learn it all at once. If you spend a half
hour or so each day reading, looking through
examples on the Web, and studying questions in
discussion groups (answering them when you can),
you'll discover that you know an awful lot before
you know it.
A second question that is very popular right now is,
"What is the future of Visual Basic?" Microsoft
clearly wants developers to move to VB .NET or
possibly C#. Book publishers and tool providers have
jumped on the bandwagon but the development
community is far from convinced even at this late
date. In one poll of more than 500 developers, 37%
said they were not planning to move to .NET and 21%
more were undecided.
I know several developers who still use VB 5 because
they feel it is more stable than VB 6. I even know a
few who use VB 3 because they have legacy systems
running in 16-bit Windows. As someone recently
pointed out to me, he has learned practically all of
what he knows about VB 6 from the Web, examples
posted online, and books. A little thing like
Microsoft stopping support for VB 6 isn't going to
force him to give it up right away.
Personally, I see VB .NET as another new tool that I
need to learn about. I'm using VB .NET and writing
books about it, but I still use VB 6 a lot and
certainly won't ignore my readers and Website
visitors who continue to use older versions of
Visual Basic.
Q: It’s a blank slate, what added comments would you
like to give to enterprise corporations and
organizations?
A: For development organizations I'd like to
reiterate that you can control software development.
Books like "Debugging the Development Process,"
"Writing Solid Code," "Prototyping with Visual
Basic," and "Bug Proofing Visual Basic" tell you
how. You just need to read them, adapt their
techniques for your use, and stick by them. That's
not always easy. When the schedule slips and
deadlines loom, it's tempting to throw the plan away
and "make up for lost time." Unfortunately just
saying you'll work faster won't make it happen. Your
project will be incomplete, buggy, late, or some
combination of all three. If you make a realistic
plan and stick to it, you can produce high-quality
software on your schedule and not the whims of fate.
For developers I'd like to say, "Keep learning." The
programming field has probably experienced the most
prolonged period of intense change seen in any field
in history and it's not likely to stop changing any
time soon. There will always be new problems, new
ways to think about old problems, and new hardware
to exploit. It may not be necessary (or even
possible) to keep up with every single development
on a day-to-day basis, but you do need to constantly
improve and expand your skills if you don't want to
be left behind. Occasionally ask yourself, "What
have I learned lately?"
Q: Rod, thank you for sharing your valuable insights
with us today and we look forward to reading your
books, and articles.
A: It was certainly interesting for me. Putting
ideas like these into words always helps me think
about them more clearly so I learn a lot, too.
Perhaps that's one reason I enjoy being an author. |
|
|