The Reuse Police
It’s not like I forgot about February. It
just came and went. Now March is all but
gone. I blame my teaching gig, but the truth
is that I am busy on lots of fronts. Not
surprisingly, the more time and energy I put into writing, the more work that comes my
way. I’d like to say No to it all and work
on my own stuff, but I am very good at spending money (Bill Gates take note)..
Anyway, that means that I have had lots of ideas (great ideas, really), but little time to
just sit still and ponder them. I like that
pondering and believe everyone should do some of it from time to time, but it’s hard to
get to pondering with something due every day. Better
put this in the mail before March has gone and I’m teaching again.
The Crime: Failure to Reuse
The Penalty: Extra Work and Lower Quality.
My friend and associate, Monty Jackson, the Cowboy Software Engineer used to say that
every project needed a Reuse Cop. This Reuse
Police Person (RPP)
I liked the idea when I first heard it. I
still do. I don’t even care if I don’t
get to be the cop. I really hate to do the
same thing over and over again, and I think I’d be appreciative of someone pointing that
out. (I know those of you who have worked
with me may be expressing some doubt at that statement, but I can take criticism now. Really.)
On the one-person projects I typically prefer, I get to be my own policeman. This is not the best situation because I am all
too ready to make allowances for me, but I want to be able to maintain these projects in
my spare time.
That means highly readable, well-documented code, and getting rid of as much of that as I
can. Reuse helps.
If I can eliminate a few hundred lines of code by practicing reuse, that’s a few hundred
lines that I’ll never have to read, never have to fix.
That alone is enough to justify the extra effort that is required to make a
component reusable.
I’ve worked on a couple of projects lately that could have used a reuse cop.
You just have to design your software so that you are able to fix a problem by fixing it
in one place. Tracking down multiple copies
of a problem and fixing each of those is INSANE. People
that refuse to practice intense reuse aren’t lazy; they’re crazy.
The odd thing is that the Internet is really putting reuse to work on a grand scale, with
major sites running a bevy of powerful applications hosted and maintained elsewhere. Component architecture is everywhere, with
components easy to build and a wide variety of commercial components that are powerful,
reliable, and easy to use. That will all save
oodles of work, but it is no justification for leaving your code littered with sloppy
duplication. The sooner you maximize reuse,
the simpler and cheaper your maintenance chores will become.
One of the better XML teaching resources that is out there.
http://www.xml101.com/
By Steve Mulder of Web Monkey
http://hotwired.lycos.com/webmonkey/stylesheets/tutorials/tutorial1.html?twieg20000105
Makers of all kinds of interesting utilities including a VB to VB Script converter. I also like their VB to Java tutor. You type something in VB, the tutor translates it
into Java right before your eyes..
http://www.tvobjects.com/
http://www.Cramsession.com
Lots of good information focused on certification exams.
http://www.siteexperts.com/
Lots of information, useful newsletter.
http://dynamicdrive.com/
Excellent Web Programming Resources, newsletter, strong on JavaScript.
It’s a little thin right now, but it is from Lycos, and you know how much
http://angelfire.lycos.com/doc/scriptlib/
Want to know which browsers support which style sheet attributes? This is a
http://webreview.com/wr/pub/guides/style/mastergrid.html
Featuring the sexiest geek alive contest.
http://www.geekandguru.com/
http://sunset.usc.edu/WinWin/winwin.html
I think this tool requires some work to master, but it has excellent
A search engine, or more accurately, indexing service focused on technical
http://www.techcrawler.com/
1. Be careful. If you read this stuff, people will think you’re
the kind of person who takes advice over the Internet.
We know now that an expert is anyone who can type.
So why’s everybody looking at me?
2. The worst tip of the week was advice
that you should remove your white space from your HTML code to make your pages load
faster. That’s like telling people to cut
off one of their legs because the weight of the leg is slowing them down. I don’t think the white space on a typical HTML
page would slow down a teletype machine.
3. Cramsession reports
that there are now five million Apache Internet servers, swamping IIS, the second place
holder at two million. You wouldn’t know
that here in the Pacific Northwest.
4. Sure, I’ve written my share of
fascistic software, but that doesn’t mean that I like using it. My number one peeve at the moment is Visual
Interdev. I go through my code and clean it up, save it, then as soon as I update
the server, it just trashes all of the work that I have done. This makes “cruise missile” and “Redmond”
come up in the same sentence a lot. I’d
really like a more personal interaction with the person who dictated that
5. Which reformatting do I hate the most,
you ask? True, I would vote for drawing and
quartering the programmer who changes the capitalization of my tags, but that is not the
worst. The worst is when VI takes my carefully aligned and formatted
attributes, and puts them all back on one line running them off the right side of the
screen.
6. Allaire HomeSite has six hundred ways
to yank your chain too, but it
7. I do a lot more projects where they
want me to use Visual Interdev, but HomeSite is getting to be the tool I use when I get
the choice. VI is such a leech, sinking
tentacles into my application at every turn. I
just know that Microsoft is biding its time before it devours my flesh.
8. My least favorite thing about HomeSite
is that it does not recognize
9. HomeSite also doesn’t recognize some
key words like ‘With’ as keywords. It’s not a big deal, but it does make my
with blocks harder to find. ‘To’ is
another keyword that slips through the cracks. The
in-editor syntax checking is much more reliable in VI.
10. One of the hardest things for me to get
used to in an Internet
11. Ego-less programming - I understand why
it’s a good idea. I also understand why
ego-less sex is a good idea, but I haven’t mastered that either.
12. No code should EVER go off the right side
of the screen. I try to follow that rule, but
I am eagerly looking forward to my first six-foot wide monitor.
13. I’d be money ahead sometimes just paying
someone to follow me around and slap me each time I’m guilty of hypocrisy. I’m working on it, but I still have to plead
nolo contendere at least twice a day. My most
common hypocrisy is not asking for help when I get stuck.
I hate to ask for help, because I know I’m usually missing something really
obvious.
14. Without encapsulation, you need discipline
to adhere to design decisions and constraints. Since
encapsulation is weak at best in the scripting languages that dominate today’s world, a
project needs an enforcer to run around periodically making war on design violations. Otherwise, even the outline of a design can
disappear in a short time.
15. The most common design violation I see is
putting database access code in the GUI layer. It
happens ALL of the time on small projects and a dangerously high percentage of the time on
medium to large size projects.
Designers make the decision to build a three-tier architecture, but then
16. Why does a programmer violate an
architecture that the programmer designed and signed up for? Because he or she can. We’re all lazy and short-sighted, and we think
that we will fix it later.
17. I’ve seen Active Server Pages late than
run to the thousands of lines
18. People talk about three-tiered architecture
(GUI, Business Rules, and Data Storage). Look
at most projects, however, and the data storage level is usually the only level whose
construction is not dependent on the implementation details of the other levels. Often the business rules level
is heavily dependent on implementation details of both the GUI and the data storage level.
19. I just finished a project that did a very
good job of keeping the database stuff behind an impenetrable wall. That made getting the data a simple matter of
asking for it, and poof it was there like magic. The
downside to this if you are the guy called in to help out, you have little left to do but
dink with code that pushes tables around. Not
that this isn’t an art form, but nine hours a day of this will turn your brain into
sausage.
20. Configuration
management on one project I worked on recently was done by yelling out “Hey, are you changing my file?” Surprisingly enough, it worked most of the time. The group was still small enough so that everyone
was within earshot, and most people were amazingly tolerant and understanding. (I’ve worked in much smaller groups where this
would be a recipe for murder.(
21. I continue to indulge in ranting about
untyped languages - make that
22. It’s the same old story, the Implicit
route always looks easier, but the Explicit path is the one you want to take if you want
someone else to be able to follow. Actually,
the Explicit path is the only one for most of us to take if we want to retrace our own
steps.
23. People expect their software engineering
tools and techniques to be
24. I’ve given serious thought lately to not
renewing my Microsoft Developer Network Universal Subscription. The price has risen to nearly $2500, and I don’t
depend on as many Microsoft products as I once did. It
was a different story when it $1000, and I used the whole suite of development tools as
well as the Office products.
25. Even at $2500, it’s a good deal even if
you only use a small fraction of the products, but since I am ready to abandon Source Safe
and Visual Interdev in favor of development tools that are fundamentally sound. Well, maybe that’s asking too much. I still am pretty much addicted to Office Tools,
and I still like VB.
One consistency I have managed to maintain is my teaching and writing is that requirements
are the foundation for testing, but sometimes it takes me a long time to figure out the
really easy way to do something. Now I think
I’ve got it.
Before I get into that, however, let’s make an agreement to keep the word
‘requirements’ between us. There is
something about it that just scares the hell out of the typical business that is trying to
contract a little programming help. In many
cases, you will find that you are better off if you simply say: “Help me just figure out what you want me to
do.” I don’t know what it is about the
word in the business world, but saying “requirements” has about the same effect as
saying “if it’s okay with my lawyer:.
Enough ado. Consider the following approach
to gathering requirements:
Begin by asking the customer: “How will you know if I built the right thing?” Write the customer’s first words down. You’ve designed the basic test. Furthermore, you, courtesy of the customer, have
stated the first requirement in an unambiguous manner.
You are already ahead of most of your competitors.
You still have to dig, like with any technique, but you can go a long way
What do you mean by that?
How do you know?
If these are your only two questions, you might get tiresome enough to the client so that
you never get the chance to capture all of the requirements, but that is another problem. These two simple questions will give a good start to getting your
high-level requirements AND your high level test plans.
Yeah, I know it’s not pretty, but the point is to capture ALL of the requirements, and
to state them in such a way that the product or solution can be objectively tested against
those requirements. Good requirements allow
no room for disagreement over whether or not the requirement has been met. A good requirement explicitly implies (how’s
that for an oxymoron) a test that can be performed by an objective third party.
* *
* * * * * *
Alan Brice Corwin
7349 16th Avenue NE
Seattle, WA 98115
206-525-9093
mailto:abcorwin@processbuilder.com
http://www.processbuilder.com/