News from National -- Current
5/31/2002 9:01:06 AM
World Application Expert: Rod
Interview by S. Ibaraki, I.S.P.
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
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
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
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
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
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+
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"
- 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
- Perform updates,
insertions, and deletions in the proper order to satisfy relational
- 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
- 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
- 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:
- VB .NET-style property
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
"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
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
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
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
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
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
- 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
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
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
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
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
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
"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
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
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
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
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
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.