EVALUATION
Not All Walls Are Good
It’s time to reassess long-cherished practices by Michael J. Rozlog
S
ome walls are necessary.
We use brick-and-mortar
walls to support buildings
and firewalls to protect our
computers from attack. But not
all walls are good. Consider the
Berlin Wall, a wall of segregation. It
divided a country and its citizens,
but has subsequently been brought
down by people working together
because upon re-evaluation the Wall
did more harm than good. These
thoughts led me to think about the
walls that developers, QA managers,
and database professionals have
erected over the years to segregate
themselves. Is it time to re-evaluate
our own walls?
Most organizations, from the
small mom-and-pops to the large
enterprises, have established all
kinds of walls. An example of a others, such as application devel- But that was then. Is the same
good wall is one that is intended opers and QA staff. Why did I (and fear-based paradigm still valid in
to stop or prevent unwarranted as far as I know, the rest of the IT today’s IT environment?
Mike Rozlog is senior director of access to mission-critical systems. industry) do this? Various studies over the years have
Java solutions for Embarcadero An example of a bad wall would be The answer is simple: the data- found that developers with correct
Technologies and focused on one that stifles communication or base is always a key fixture in any requirements and the right tools are
ensuring that the products understanding of the data being organization. Since the beginning, more productive and deliver better
created meet the expectations manipulated. Originally all walls companies understood that they solutions. This makes sense, and
of developers around the world. were put in place to save time and needed to have superior applica- it’s been proven to be true across
Much of his time is dedicated to rework, but over time it’s a good idea tions to collect information; the professions such as construction or
discussing and explaining the to review long-held practices and result was an explosion of invalu- automobile repair. Over the years,
technical and business aspects reassess what’s still effective and able data and information. And the one of the areas that has been lack-
of Embarcadero’s products and what isn’t. industry learned quickly how bad ing in development are tools that
services to analysts and other I’ve had a varied career; I have things could get if that data was cross boundaries to help developers
audiences worldwide. Mike been a lone developer, a member corrupted or lost. Based on this write better SQL and database-re-
was formerly with CodeGear, a of a team, a project manager, and fear we established artificial walls lated code. In many instances, the
developer tools group acquired I’ve run R&D for organizations. that would isolate access, establish initial database interaction created
by Embarcadero in 2008. Previ- It was always been a practice to access rights, and limit communica- by the developer is little more than a
ously, he spent more than eight keep the database in the database tions between various departments placeholder for the DBA or database
years working for Borland in a professional’s hands and away from in an organization. professional to review later. This ap-
number of positions, including
“
a primary role as chief technical
architect. A reputed author, Mike
has been published numerous
times. His latest collaboration is
Optimization needs to occur when things can be isolated,
“Mastering JBuilder” from John
Wiley & Sons, Inc.
so using profiling tools throughout the development lifecycle
is important for the developer”
michael.rozlog@codegear.com
28 January 2009 JDJ.SYS-CON.com

“ There’s a wall we’ve erected between developers and DBAs
that’s causing problems; tools are not consistent between
the two worlds”
proach is inherently flawed primarily QA process has certified the applica- forming code is essential in today’s
because it enables early mistakes to tion. Others have learned that making fast-paced marketplace. Plus, many
make it through the entire process to changes for speed and efficiency that organizations have put extra pressure
production. late in the process can be dangerous on developers and DBAs, combining
We have all entered mistyped data, and that it often takes another full QA roles and making them wear both
which has a cascading effect on the cycle to ensure that the optimization hats. But, there’s a wall we’ve erected
capture and storage of information. process didn’t break anything. (All that’s causing problems; the tools
Developers who do not understand developers have been bitten by the are not consistent between the two
the database structures will inad- “one-line” change that fixes a problem worlds.
vertently create new tables that are but causes 50 other issues.) But there are new tools on the
sometimes redundant, and don’t Others in the community believe market that help developers and
always write the most effective SQL that initial testing of the software DBAs visualize rather than read
code. Somewhere in the chain the should be optimized before reaching what they are building, and more
review process breaks, and mistakes QA. This can be effective, but also importantly, reverse-engineer what
that shouldn’t happen do. This leads means code needs be reworked since they’ve already built. Products that
to DBAs missing or breaking SLA(s), QA hasn’t certified it as correct. Then let complex concepts be modeled and
mistrust between developers and there’s a school that believes optimi- discussed from both an application
DBAs and the application not working zation should only happen when the developer, Q/A, DBA, and data center
as it should. application is in maintenance, since perspective have become critical to
So doesn’t it make sense to put that’s the only time the software is organizations. Existing tools will help
things in place that, at a minimum, usually considered correct. find nightmares in applications, but
help ensure the application developer Most likely an “all of these” ap- the new tools are adding suggestions,
doesn’t just put in some “holder” code, proach is warranted. Consider Wall best practices, and help in fixing code
but instead has a fairly good chance Street: if it didn’t build performance on the spot, even considering the
of creating a database manipulation and QA into every step its ability to context of who is making the change.
layer that if the review breaks down, process huge numbers of transac- Insights that may not be useful or
the code created will work as expected tions would be almost impossible, understood from a developer stand-
and that most errors or inefficiencies and disastrous code could make it point may be incredibly important
are caught and fixed upfront? into production. Optimization needs to a DBA and thus solve problems
to occur when things can be isolated, in less time. These new tools have
Current Practices: so using profiling tools throughout capabilities we only dreamed about
Barricades to Effectiveness the development lifecycle is impor- a few years ago, such as profiling the
Developers don’t want to write tant for the developer. For example, entire lifecycle so no one area is left
code that’s incorrect, not up to the how would a developer test the per- out of the information chain, as well
best standards, or performs poorly. formance of an ‘x’ algorithm versus as automatically generating docu-
So having the tools to help develop- a ‘y’ algorithm if he doesn’t have the mentation, portals, and Wiki support
ers write solid code is essential. There tools to profile it in the first place? to expose information to key players.
are next to no developers in the world It’s been an established best The walls that have been put up
who think debuggers are bad or be- practice that finding bugs early in over the years are at least getting
lieve they shouldn’t be used to isolate the development process is a good fitted with a few doors and windows;
problems in code. Some problems are thing. It saves time, and eliminates and in some cases they are even
easily found using a debugger rather rework, retest, and redeploy cycles. being taken down brick by brick, al-
than applying other bug-hunting It also reduces the possibility of bad lowing for clean and nimble develop-
techniques. The same is true when it code, embarrassing the company and ment. Will these changes eliminate all
comes to optimizing an application. delaying delivery. the problems facing developers and
A long-standing debate exists database professionals? Of course
about the best approach to optimize Standardized Tooling: not, but hopefully standardized tool-
for speed. Some in the developer Building Bridges, Not Walls ing will, at a minimum, increase the
community believe that optimization Giving developers advanced tools “vernacular” and reduce the bad code
should only happen after the initial to help write cleaner, better-per- making it to production.
JDJ.SYS-CON.com January 2009 29