| Code-Free Not writing code is a driving force behind reuse initiatives. In the
spirit of being code-free, this article has no code! Part two of this article will be
full of code. The importance of reuse can't be overstated, especially in light of the
degree to which we seem to go out of our way to avoid reuse. So, let's peal back
the kid gloves and talk about it. Living in the Shadow of Your Own ExtinctionAs an industry at large we're rivaled perhaps only by government for
institutionalized incompetence. Quality is low, defects are high, and
communication is a myth. On average, we achieve success 50% of the time yet we
expect 100% of our salaries. Our employers and our managers are fed up with
getting a 50% return on 100% of their investment and yet we have the audacity to
complain when they give our jobs to developers in other countries who are
willing to do the work for half the cost. We suck. It's unlikely that the whole software development industry
in America will shrivel up and fall off, but it's likely that the American
programmer gene pool will continue to be significantly thinned. The domestic programmer role will be whittled away from the bottom-up as the
offshore shops achieve greater levels of competency. This will continue for
years as each successive skill level of the work force is shifted offshore until
only the right slope of the software competency bell curve is left operating on
American shores. Personally, I have mixed feelings about the commoditization of programmer
skills and the eventual expatriation of American programming jobs. I want my
American brother and sister coders to have as many professional opportunities as
they can handle. However, if they can't step up quality, I'd just as soon see `em
sent back to the minors. Software development is a service that we provide to enable and empower the
business units that we support. I certainly don't want to see the end of the
custom application development industry in America, but there are limits to how
far we can expect our sponsors to bend. Once programming and programmers become
the obstructions to business progress, then it's time to start looking for
alternatives. It may turn out that offshore development is indeed the chosen alternative.
It may not end up being the right choice, but learning that lesson is going to
be costly beyond imagination for our industry. In the very least, offshore
outsourcing presents a cost structure that is more in line with the level of
quality currently delivered by the domestic programmer. Even as a coder I can't
deny that it's simply one hell of a compelling value proposition.
Saving Your Hide A couple of turning point experiences I've had in the past couple or years
have convinced me of a few kill skills that will make the difference between the
haves and the have-nots of the domestic software development job market. Here
are a few of the key predispositions that are presently missing en masse from
our current practices that I'm convinced are going to characterize the American
software development workforce on the backside of the onset gutting of our
industry: Unit Testing. In a recent conversation with Michael Kennedy, maker of
the HarnessIt unit testing framework for .NET, we talked about how mind boggling
it is that the majority of applications programmers do little-to-nothing to repeatably validate that their software will do what they assume it will do.
With the mainstreaming of simple yet incredibly powerful quality-focused
methodologies like Test Driven Development (TDD) as well as comprehensive and
reasonably priced tools like HarnessIt (or NUnit if you're willing to forgo a
few features), it's unconscionable that we still have so many defects and
unproven assumptions deployed into production. Frankly, I don't even trust developers anymore who don't use some sort of
test-code-test-code cycle in their software development practice. If you can't
prove that your code works, why in name of J. Jonah Jamison would anyone want to
trust their business to it? Once you embrace TDD you will wonder how you could have ever fulfilled your
software development responsibilities in any other way. TDD is one of those
things, like OO, that fundamentally rearranges the hard-wiring of your
programming mind. You'd have an easier time coaxing a butterfly to return to
caterpillar form than to convince me that I could go back to software
development sans the TDD approaches. Scenario-Based Analysis. Far too many .NET developers are still stuck
on data-centric analysis. They will often try to communicate their understanding
and intentions through the use of data models and entity-relationship diagrams.
The dangerous aspect of this approach is the implicit assumption that everyone
reviewing the data model will arrive at the same conclusions about a system's
behavior. After all, a data model does nothing to explicitly describe
behavior. Data-centric specification implies that a momentary understanding of behavior
was arrived at during the analysis (perhaps during an interview with a
stakeholder, or from a developer's experience in a business domain), and
summarily excluded from the specification once a data model had been derived.
Rather than capture the behavior in a user story, use case, or even a conceptual
class diagram, the knowledge is simply discarded. The enduring data-centric specification compulsion in .NET is a hold-over
from the VB 6 days when the lack of object orientation in the language (and the
developer culture) meant that behavior was frequently a second-class element of
software specification. Use case or user story analysis is simply a great way to examine, understand,
capture, and communicate the expected behavior of software. Scenarios lead to an
understanding of data AND behavior. A view to both of these is crucial to
object-oriented development. Even if you're doing conceptual or agile modeling,
expressing behavior is still requisite. Asset-Based Software Engineering (ASE). You might know ASE by its
street name, "Reuse". Far too few programmers engage in reuse. As Flashline's
C.E.O. Charles M. Stack puts it, "We must transform our view of software
development to a new model -- Asset-based Software Engineering -- where
appropriate engineering and asset management principles govern the creation and
management of software assets for long-term economic benefit." [Stack] The lack of reuse in our lives as programmers isn't simply
a technology or implementation issue. Systematic reuse requires management. Far
too few development managers have been able to pry their minds from the
habitual view that our software artifacts are only ever a liability, rather than
a portfolio of assets that are subject to the same portfolio management practices
as any other portfolio of assets. With a view to reuse and ASE pervasively
absent from the two organizational tiers closest to the implementation effort --
the programmers and their line managers -- the odds are stacked against reuse
efforts.
Overcoming Inertia Typically, we can reuse (unmodified) existing software for 20% the cost of
new development [Poulin]. However, programmers are likely to resist reusing anything that
doesn't come with evidence of its quality. The credibility of a product's developers is usually all the credibility we
need. However, if you're trying to prove the quality of a reusable artifact,
being able to demonstrate that you follow Test-Driven Development will go a long
way to establishing your credibility as a developer and the quality of your
artifact. As well, the presence of a means to describe an artifact's behavior is
crucial to its ability to be understood. If you have no idea what an artifact is
supposed to do, it's often altogether impractical to learn whether the
artifact's behavioral profile matches your requirements. Without software validation, there is little credibility. Without behavior
specification, we have systems whose intentions are ultimately questionable, and
we end up with artifacts whose meaning has no visibility except to those who
created it. Without either of these, we have approximately a snowball's chance
in hell of achieving reuse. Without achieving the economics of reuse, Programmerus Americus can look
forward to a nice comfy bath in the La Brea Tar Pits with the other extinct dinos. At some point in the history of Homo Sapiens, we shared the Earth with
the Neanderthal. We're all pretty clear on who won that land dispute. We simply cannot continue to justify the existence of the vast American code
production workforce and its ingrained disregard for economics while the
attractive face of offshore programming shops shine upon us from far-flung
places such as Poland, Hungary, India, The Philippines, Malaysia, The Russian
Federation, China, Ireland, Canada, and Israel. The offshore programmer species
is here today. It's not a myth. It's a clear and present threat. It remains to
be seen as to whether the domestic American programmer has the awareness and
will to evolve into a competitive member of the global software development
ecosystem. We can either get better at what we do, or be made redundant. And like
everything redundant in software, being factored out of the system is a nearly
unavoidable eventuality.
Arriving at Quality There's a large computer manufacturer and e-commerce giant in my area that
recently committed to .NET. They also standardized on C#. I spoke to one of
their folks at an architecture roundtable a few weeks ago about the formalization effort around C#. We
talked about the challenges of moving a staff of procedural VB 6 and VB Script
coders from linear, procedural thinking to abstract, object-oriented thinking. I
asked him if the standardization on C# was something that they see as an enabler
of their transition to .NET and OO. He said that they wanted their coders to be "shocked into knowing that they
were in an object-oriented language." He suggested that they want their coders
to have no vestigial connection in their coding efforts to linear VB in hopes
that they can free themselves of that mindset. He also said something about
wizard-based coding that I
have quoted often in the intervening weeks: "We had better quality when coding was harder." There was a time in recent history when we needed programmers and lots of
`em. We accelerated training programs. We transferred business analysts into
software development roles. We even called up people from the call center and
hung programmer hats on their heads. This is like calling up your local t-ball
team to play against the Yankees. We do such things and we still have the
audacity to wonder why our jobs are going offshore. Entry-level web coders were fetching upwards of $70k. That was supply and
demand at its best (or its worst depending on where you draw your ethical
lines). Back in the day, as the story goes, if you could spell "HTML" you could
be ushered into the fold and set to work building the user interfaces for man
kind's first ubiquitous, global e-business infrastructure. Building Web UIs meant using a hodge-podge of cobbled together tools that
demanded not so much hard-core coding experience but a high level of tolerance
for tedium. Middle tiers were built by "serious" coders with serious tools and
real experience that dated (if you were lucky) from before the boom. From the OO
developer's perspective, the "UI guy" was often something to be tolerated in
public, and shunned in private (as in, "That.s a job for a beginner, give it the
"the UI guy".). OO developers had better things to do with their minds than
muddle about in linear script. The Web UI builders were effectively quarantined and culturally isolated from
the OO caste, and accordingly developed a programming culture whose values are
often at odds with the values of OO culture.
Overcoming Legacy In "Asset-based Software Engineering ", Charles Stack writes, "it's ironic
that outside of its use in the software context the word 'legacy' has very
positive connotations. It is what a mother leaves to her daughter, a father to
his son, or a citizen leaves to his or her society. But in software, legacy has
come to mean 'old, incomprehensible, inflexible software written by people who
are no longer here.'" The legacy of classic ASP is much more daunting than the mess of server-side
includes, copy-and-past layout, spaghetti script, and business rules living
inside otherwise harmless HTML pages. Entropic, legacy code artifacts can be
mitigated. The linear thinking that characterizes the world view of the average
classic ASP developer is going to be a much more stubborn problem than any of
the legacy code. ASP .NET introduces opportunities for the holy grail of object-oriented
reuse: framework-level reuse. There have been a slew of articles on .NET portals
over the last year on custom page frameworks for Web forms. Each has done a
darned good job of explaining the how's of creating such a framework, but
there has been little talk of the why's of creating such a framework, or
better yet why you should just use one of the available frameworks. Earlier this evening I had a conversation with Roger Sessions, author of
"Software Fortresses: Modeling Enterprise Architectures". Roger is one of those
guys who can poke holes in most people's most vociferous software dogma. While
waxing unsympathetic about quality and low levels of reuse, Roger rightly
pointed out that we engage in reuse all the time without knowing it. He
suggested that relational databases are a ubiquitous yet often overlooked case
of reuse. Unconscious reuse is certainly better than no reuse at all, but it's still
unconscious. You can't achieve intentional systematic reuse by being unaware of
either leveraging a reusable artifact, or by being unaware that you're crafting
a reusable artifact. Quality and reusability are about personal responsibility.
Creating validated code that is a well-factored asset is an expression of your
sense of responsibility to your co-workers and to your company or client as a
whole.
Engaging in Reuse In part two of this article, I.m going to implement yet another framework for
content reuse in Web forms. Rather than reiterate everything you've already read
about how to do templating in ASP .NET, I'm going to do my best to use a common,
approachable example of reuse in object-oriented programming to talk about
different types of reuse, as well as why you'd want to engage in reuse. My ultimate hope is that you might begin to explore object-orientation beyond
the basics and make reuse a willful, conscious part of your programming practice
that fully engages your intent to provide more value to your employer or
customer.
About the Author Scott Bellware is consultant and mentor with developerLabs. Scott is the Director of Operations and co-founder of the Austin NET
User Group, Director of Technology and co-founder of the Austin Software
Architecture User Group, and the Chairman of the International .NET
Association.s (INETA) Speaker Committee. He is the Architect and Developer of
the Norpheme object relational persistence framework for .NET. He has given
talks for central-Texas groups on software quality, reuse, and object relational
mapping, and recently spoke at the DevTeach conference in Montreal Canada.
Bibliography Asset-based Software Engineering (How to gain the next level of software
development productivity), Charles M. Stack, Flashline, Inc. Metrics for Object-Oriented Reuse, Jeffrey S. Poulin, Lockheed Martin Federal
Systems The UML Profile for Framework Architectures, Marcus Fontoura, Woflgang Pree,
Bernard Rumpe Test-Driven Development By Example, Kent Beck Developing Software with UML, Object-Oriented Analysis and Design in
Practice, Bernd Oestereich Managing Enterprise Content: A Unified Content Strategy, Ann Rockley
|
