How Managers

Can Help Their Developers

Write Excellent Code
Written by
Steven Feuerstein
PL/SQL Evangelist
Quest Software, Inc.

WHITE PAPER
© 2010 Quest Software, Inc.
ALL RIGHTS RESERVED.

This document contains proprietary information protected by copyright. No part of this document may be reproduced
or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any
purpose without the written permission of Quest Software, Inc. (“Quest”).

The information in this document is provided in connection with Quest products. No license, express or implied, by
estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of
Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE
LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND
DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY
DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING,
WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF
INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with
respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to
specifications and product descriptions at any time without notice. Quest does not make any commitment to update
the information contained in this document.

If you have any questions regarding your potential use of this material, contact:

Quest Software World Headquarters

LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
email: legal@quest.com

Refer to our Web site for regional and international office information.

Trademarks
Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure,
Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight,
ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop Authority, DirectoryAnalyzer,
DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile,
InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats,
Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!,
PowerGUI, Quest Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, Security
Lifecycle Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab,
Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator, vControl,
vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA, VizionCore, Vizioncore vAutomation Suite,
Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore vReplicator, WebDefender, Webthority,
Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of America
and other countries. Other trademarks and registered trademarks used in this guide are property of their respective
owners.

Updated—May 2010

White Paper - How Managers Can Help Their Developers Write Excellent Code 2
Contents
Abstract .......................................................................................................................................................................... 4

Introduction .................................................................................................................................................................... 5

Show Developers the Love ............................................................................................................................................ 6

Incentives ................................................................................................................................................................... 6

Research Time ........................................................................................................................................................... 7

Provide Developers with the Right Tools ....................................................................................................................... 8

Good Tools Are Out There ......................................................................................................................................... 8

Choose a Champion ................................................................................................................................................... 8

Don't Let Developers Code in Isolation .......................................................................................................................... 9

Conduct Monthly Code Review Sessions ................................................................................................................... 9

Set Up a Buddy System ............................................................................................................................................. 9

Automate Code Quality Validation ............................................................................................................................ 10

Conclusion ................................................................................................................................................................... 11

About the Author .......................................................................................................................................................... 12

About Quest Software, Inc. .......................................................................................................................................... 13

White Paper - How Managers Can Help Their Developers Write Excellent Code 3
Abstract
Writing really excellent software—software that is efficient, maintainable, and bug-free—is extremely challenging. It is
also, however, critically important to your organization. This white paper explains how development managers can
help their teams create better software by:

x making sure they feel valuable and valued,

x giving them the tools they need to be effective,

x ensuring they don’t write code in isolation.

White Paper - How Managers Can Help Their Developers Write Excellent Code 4
Introduction
It is generally hard to write software, and notoriously difficult to write really good software (efficient, maintainable, and
bug-free). It is an act of almost purely mental effort, and requires extremely high levels of concentration, long-term
focus, abstraction, and complex manipulation of those abstractions. When developers are under a lot of time
pressure and many different tasks compete for their attention, the result is almost guaranteed to be mediocre
software. It will contain multiple shortcuts, patches, copied code and mystery code. And it will be tested in a cursory
fashion. Of course, this software will also be handed to you with lots of crossed fingers behinds straightened backs –
and there will be no end to the trouble it will cause you in the future.

No one wants that. But how can we change this dynamic? Upper management folks require delivery of new
applications that will allow them to increase their profit margins, whether it's by replacing people with automation or
simply making employees more productive. And naturally, these folks expect all current systems to work properly.

Development managers are key to the solution. They need to understand the challenges of coding and provide an
environment for their developers that encourages and supports the writing of excellent code.

The starting point for developing a strategy to change things is to define where you'd like things to be. Then you can
figure out a path for getting there (or even just taking a couple of steps in the right direction). All healthy, productive
development teams share the following characteristics:

x Standards and processes are defined and followed, but not burdensome

x Regression tests are maintained and run for all critical program units

x No one person holds irreplaceable information about the applications

x Technological expertise is shared across the entire team

Based on these goals, what you can do for your development team?

x Make sure they feel valuable and valued.

x Give them the tools they need to be effective.

x Don't let them write code in isolation.

This white paper explains each of these key strategies in detail.

White Paper - How Managers Can Help Their Developers Write Excellent Code 5
Show Developers the Love
High-quality software is not the sort of thing that can be produced under compulsion or coercion. You need
cooperation, enthusiasm, creativity and real dedication to the product being built.

In my experience, it doesn't take a whole lot of effort or expense to make developers feel appreciated, and to obtain a
higher level of commitment from them as a consequence.

Beyond all the soft skills that any good manager should apply to all team members, I suggest that you consider
establishing the following two concrete programs for your team:

x Incentives — What's the best way to motivate a developer: carrot (incentive) or stick (punishment)? We all
know the answer, and not just for developers: no one is motivated to change for the better by a threat of
punishment (though we may still change because we have no choice).
x Research time — Provide your developers with time to expand their knowledge of key technologies.

Incentives
Managers should identify ways to objectively measure progress in important areas, and then give out rewards to
those who are high achievers in those areas. Rewards should include status-building recognition, as well as goodies
like gift certificates to restaurants, Amazon.com, etc.

Here are some ideas for possible metrics:

x Reusable code — We don't want developers to reinvent the wheel, but sometimes it's hard to find and
reuse code. Perhaps prizes will help. I suggest you give a reward for (a) the person who writes the most
reusable code (usually a senior developer), and (b) the person who uses the most reusable code. That way,
even a junior developer has a chance to win and is very much incented to learn from and use the work of
others. To get the metrics for awarding the prizes, you can, for example, run searches through the code
base to find all external program calls (not in the same package).
x Follow standards — Most development teams have a set of coding standards defined (if yours does not,
visit the PL/SQL Standards page of PL/SQL Obsession at www.toadworld.com/sf). But how many
organizations actually check whether anyone has followed the standards? You should use automated
procedures to validate conformance with standards, using a tool such as Toad's CodeXpert or Oracle11g's
PL/Scope, or peer code review, and then award prizes to the developers who are the best at following your
standards.
x Unit tests (especially automated ones) — I would award a really substantial prize to the developer who
does the most automated testing of code by building and putting in place regression tests. This type of
testing will have the biggest impact on the quality and success of your applications, so get people motivated
to do it! See section below (“Provide Developers with the Right Tools”) for a review of available automated
testing tools.

White Paper - How Managers Can Help Their Developers Write Excellent Code 6
Research Time
I continue to be shocked at how many developers still do not seem to know about and use many important features
added to PL/SQL in Oracle8i. Yes, Oracle8i. This includes things like: invoker rights, autonomous transactions,
FORALL, and BULK COLLECT. And then of course, there are the many new features of 9i and 10g, such as string-
indexed collections, MULTISET operators, DBMS_UTILITY.FORMAT_ERROR_BACKTRACE, and more.

But with some reflection, it's easy to understand why so many developers remain ignorant about such features and
consequently under-utilize the language: they don't have the time (or feel like they have the freedom) to explore
PL/SQL. Managers usually ask just two questions of their developers: "When you will be done?" and "Why is your
code so buggy?" Neither of those questions is conducive to expanding one's knowledge of a programming language.

I strongly urge managers and team leads to ask developers to each come up with a research plan that involves
spending four hours every two weeks exploring technologies that could be helpful to the project. That’s just 5% of
each developer’s time.

Insist that the developers avoid working directly on application code, but also that they put together a proposal for
precisely what they want to study and why. They will feel great about the opportunity, and both the team and
application will benefit in short order.

White Paper - How Managers Can Help Their Developers Write Excellent Code 7
Provide Developers with the Right
Tools
Budgets are tight these days, so it can be difficult to approve the purchase of new tools. I suggest, however, that the
benefits of ensuring that your developers have the right tools will quickly make up for the licensing costs.

One could certainly argue that PL/SQL developers don't need any fancy products to get their jobs done—they can
just use SQL*Plus and Notepad. And it is true, in a way. Developers will get the job done one way or another, no
matter what is in their toolboxes.

If, however, developers are given only minimal resources, the consequences are likely to include:

x Reduced productivity — It will take longer to get the job done. Since timetables aren't that flexible, your
developers will accomplish and deliver less, and they will work longer hours, bringing them ever closer to burnout.
x Unhappy developers — When a company doesn't invest in quality tools, a very unfortunate message is
transmitted to developers: saving money is more important than doing a good job or providing a high-quality
work environment.
x Low-quality software — Unmotivated and offended developers working harder than necessary to get the
job done is a recipe for buggy code and applications that will get your end users very upset.

Good Tools Are Out There

Consider the challenge of regression testing. If you cannot automate the process by which you verify that all previous
functionality still works, you will never break out of the vicious cycle of, "I don’t have time to do it right, because fixing
bugs from the last release is using up too much of my time."

The wonderful news is that back-end PL/SQL program units can be tested thoroughly and automatically. That's not
something you can say about most GUI applications.

Still, it's not easy to fully test database programming code: analyzing impact on tables and establishing useful test
databases are very time-consuming tasks. But there are a growing number of choices for automating some elements
of the test process, ranging from open source frameworks like utPLSQL, to free products, like SQL Developer from
Oracle, and to a commercial product like Quest Code Tester for Oracle.

As the lead designer and back-end developer for Quest Code Tester for Oracle and the original creator of utPLSQL
(essentially "JUnit for PL/SQL"), I have no doubt that using Quest Code Tester will yield dramatic improvements in
the quality of your code and result in a medium- to long-term reduction in the cost of maintaining your applications.

Choose a Champion
It will, however, take your support and your insistence to get a structured testing tool like Quest Code Tester up and
running smoothly and fully in a development team.

The best way to ensure successful use of a new tool like Code Tester is to choose a champion for that tool, and provide
that person with some kind of compensation or recognition for taking on the task. This person should become expert in
the technology, be enthusiastic about what it can do for the team, and be ready, willing and able to mentor others.

Without a strong proponent for a new tool, you won't be able to build the momentum to ensure a solid, consistent,
team-wide implementation. With a champion in place, all team members know whom to go to when they get stuck.
And if the champion’s role is well-defined and publicized, there will be no reluctance to approach this person for help.

White Paper - How Managers Can Help Their Developers Write Excellent Code 8
Don't Let Developers Code in Isolation
Software development is best performed as a collaborative effort. When we write code in isolation, it is much harder
to identify faulty assumptions, wrong turns in logic, violations of coding standards, and so on. In general, each of us is
too deeply involved in our problems—and way too optimistic about our ability to solve them—to be objective and
realistic about what is needed to overcome the challenges we face.

You might be saying to yourself: "Glad to hear it! I have a team of 10 developers, so no one's writing code alone." But
you may be deceiving yourself. I have found from conversations with many developers that even when they are part
of a team, they write code in isolation, for all intents and purposes. These developers say that they write programs
with minimal interaction with others on their team. Very rarely does anyone else ever look at their code (no code
review in place). They also say they are responsible for testing their own code, and since everyone is so busy, they
are reluctant to ask others on the team for help (especially the junior developers—precisely the people who need the
extra pair of eyes).

Here are some ideas for breaking down isolation on your team and fostering a much higher level of truly team-driven
development.

Conduct Monthly Code Review Sessions

It isn't feasible for every line of code to be examined by another human being. Yet peer code review (members of the
team looking at code and critiquing it) is vitally important, not only for code improvements, but also to build a stronger
and more coherent team.

I suggest that once a month, a different member of the team presents some of his or her own code for feedback. It might
be a piece of code with known bugs or problems: "My algorithm is too complicated. Do you see a way to simplify it?" Or
it might be a program that houses a critical piece of business logic that therefore has to be 100% correct.

The ground rules should be clear: constructive criticism only; no personal attacks; no question is too dumb.

You should start this process with the most senior members of the team showing some of their own problematic code.
It's very important for the junior members to see that even the "gurus" of the team make mistakes and ask for help.

Set Up a Buddy System

Monthly code reviews form the foundation of a team coding culture. You will need a way, however, for team members
to ask for help and share ideas with greater frequency. I suggest that you consider setting up a buddy system: pair up
senior and junior members of your team.

Make it clear that buddies should feel free to ask each other for help, such as review some difficult code, talk through
strategic and tactical coding challenges, and so on. Rotate buddies every six months to increase knowledge-sharing
and deepen relationships among team members.

It is possible that a team member will abuse this privilege and become a nuisance, but this dynamic is unlikely to
surface. If it does, then there’s probably a deeper problem, either with that developer or the team as a whole.

White Paper - How Managers Can Help Their Developers Write Excellent Code 9
Automate Code Quality Validation
Manual processes offer many advantages, but it is impossible to rely on team members to review and find possible
weaknesses across the hundreds of thousands of lines of code for which you are responsible.

You should, therefore, complement your peer code review process with automated code analysis. This can be
accomplished through a variety of means, including

x IDE-based analysis — Several editors in the Oracle world offer tools to automatically scan code against a
set of pre-defined best practices. Toad and SQL Navigator include CodeXpert, which is certainly the most
extensive and helpful of these tools.
x Home-grown queries against data dictionary views — The Oracle data dictionary offers a large number
of data dictionary views (including ALL_SOURCE, ALL_ARGUMENTS, ALL_DEPENDENCIES, and
ALL_PROCEDURES) from which you can perform "code quality mining" on your application software.
x Oracle's compile-time warnings framework — Starting with Oracle10g, you can enable warnings in your
session. Then as developers compile their code, Oracle will provide feedback on code quality.
x Oracle11g PL/Scope — This is the newest and best built-in (supplied by Oracle) code analysis feature of
PL/SQL. PL/Scope gathers information about all identifiers (named elements) in your compiled code. You
can use it to check for compliance with naming conventions and obtain detailed information about how sub-
programs and variables are used and manipulated in your code.

White Paper - How Managers Can Help Their Developers Write Excellent Code 10
Conclusion
Application code is written by developers, but managers play a critical role in creating an environment in which those
developers can succeed.

Many of the biggest challenges developers face have to do not with the technology, but with the human processes
that support the actual construction of code – or, in effect, the culture of the team.

The best development managers ensure that developers:

x Feel valued on their teams and enthusiastic about their work

x Have the tools necessary to productively move their projects forward

x Feel encouraged to admit ignorance, ask questions, and challenge others constructively

White Paper - How Managers Can Help Their Developers Write Excellent Code 11
About the Author
Steven Feuerstein is one of the world’s leading experts on the Oracle PL/SQL language, having written 10 books on
PL/SQL, including Oracle PL/SQL Programming and Oracle PL/SQL Best Practices (all published by O’Reilly Media).
Steven has been developing software since 1980. He spent five years with Oracle (1987–1992), and now serves as
PL/SQL evangelist for Quest Software. In both 2002 and 2006, Oracle Magazine named Steven the PL/SQL
Developer of the Year.

Steven believes that code testing is one of the most critical challenges facing PL/SQL developers and has been
leading the development of Quest Code Tester for Oracle to meet that challenge (for more information, visit
http://www.quest.com/code-tester-for-oracle). He can be reached at steven.feuerstein@quest.com.

White Paper - How Managers Can Help Their Developers Write Excellent Code 12
WHITE PAPER

About Quest Software, Inc.

Now more than ever, organizations need to work smart and improve efficiency. Quest Software
creates and supports smart systems management products—helping our customers solve
everyday IT challenges faster and easier. Visit www.quest.com for more information.

Contacting Quest Software

PHONE 800.306.9329 (United States and Canada)
If you are located outside North America, you can find your
local office information on our Web site.

E-MAIL sales@quest.com

MAIL Quest Software, Inc.

World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
USA

WEB SITE www.quest.com

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who
have purchased a commercial version and have a valid maintenance contract.

Quest Support provides around-the-clock coverage with SupportLink, our Web self-service.
Visit SupportLink at https://support.quest.com.

SupportLink gives users of Quest Software products the ability to:

• Search Quest’s online Knowledgebase

• Download the latest releases, documentation, and patches for Quest products

• Log support cases

• Manage existing support cases

View the Global Support Guide for a detailed explanation of support programs, online services,
contact information, and policies and procedures.

5 Polaris Way, Aliso Viejo, CA 92656 | PHONE 800.306.9329 | WEB www.quest.com | E-MAIL sales@quest.com
If you are located outside North America, you can find your local office information on our Web site.

© 2010 Quest Software, Inc.

ALL RIGHTS RESERVED

Quest Software is registered trademark of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners.
WPD-HowManagersCanHelpDevelopers-US-AG-20100511