how managers can help their developers write excellent code

8/8/2019 How Managers Can Help Their Developers Write Excellent Code

http://slidepdf.com/reader/full/how-managers-can-help-their-developers-write-excellent-code 1/13

WHITE PAPER

Written by

Steven Feuerstein

PL/SQL Evangelist

Quest Software, Inc.

How Managers

Can Help Their DevelopersWrite Excellent Code



White Paper - How Managers Can Help Their Developers Write Excellent Code 2

© 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: [email protected]

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

http://www.quest.com/

mailto:[email protected]



http://www.quest.com/




Contents

Abstract .......................................................................................................................................................................... 4Introduction .................................................................................................................................................................... 5Show Developers the Love ............................................................................................................................................ 6

Incentives ................................................................................................................................................................... 6Research Time ........................................................................................................................................................... 7

Provide Developers with the Right Tools ....................................................................................................................... 8Good Tools Are Out There ......................................................................................................................................... 8Choose a Champion ................................................................................................................................................... 8

Don't Let Developers Code in Isolation .......................................................................................................................... 9Conduct Monthly Code Review Sessions ................................................................................................................... 9Set Up a Buddy System ............................................................................................................................................. 9Automate Code Quality Validation ............................................................................................................................ 10

Conclusion ................................................................................................................................................................... 11About the Author .......................................................................................................................................................... 12About Quest Software, Inc. .......................................................................................................................................... 13




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:

making sure they feel valuable and valued,

giving them the tools they need to be effective,

ensuring they don’t write code in isolation.




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 timepressure 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 canfigure 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:

Standards and processes are defined and followed, but not burdensome

Regression tests are maintained and run for all critical program units

No one person holds irreplaceable information about the applications

Technological expertise is shared across the entire team

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

Make sure they feel valuable and valued.

Give them the tools they need to be effective.

Don't let them write code in isolation.

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




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:

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).

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:

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).

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.

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.

http://www.toadworld.com/sf

http://www.toadworld.com/sf




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.




Provide Developers with the RightTools

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:

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.

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.

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.




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 andrealistic 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.




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

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.

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.

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.

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.




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:

Feel valued on their teams and enthusiastic about their work

Have the tools necessary to productively move their projects forward

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




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 asPL/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 [email protected].

http://www.quest.com/code-tester-for-oracle



http://www.quest.com/code-tester-for-oracle



5 Polaris Way, Aliso Viejo, CA 92656 | PHONE 800.306.9329 | WEB www.quest.com | E-MAIL [email protected]

If you are located outside North America, you can nd your local oce information on our Web site.

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 [email protected]

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.

© 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.

how managers can help their developers write excellent code

Documents