|
11/20/01
The book Unified
Modeling Language: Systems Analysis and Development
Issues
is a collection of articles on UML modeling selected to have
relevance for real-world development issues. The book offers diverse
and sometimes profound views on the use of UML in software development.
I especially enjoyed the paper, "RUP:
A Process Model for Working with UML." Wolfgang
Hesse
focuses on the need for iterative, component-based deliverables
rather than design-up-front development phases. This paper alone makes
the entire book a worthy purchase.
Another paper that I found useful was "Data Modeling and UML" by Devang
Shah and Sandra Slaughter. It has a very nice treatment of how a class diagram
can map to an ER diagram. It is a good start on the process of reconciling objects
with relational entities.
Usability analysts should enjoy the paper Rational Unified Process and Unified
Modeling Language: A GOMS analysis. It challenges the reader to identify a GOMS
(Goals, Operators, Methods, and SelectionRules) for various UML diagrams. Practioners
who read this paper perhaps will begin thinking about the usability of their UML
diagrams as they perform their daily tasks.
|
|
10/8/01
The best software processes recognize the importance of fixing defects
iteratively and on different scales. Good software development processes include unit
testing, acceptance testing, and frequent releases. Unit testing
exposes defects on a fine-grained scale. Acceptance
testing roughly corresponds to automated tests of features and is a
medium-grain test. Frequent
releases implies a level of testing that should be done by in-house
testers and is on a large-grained scale.
At each of these levels, different kinds of defects can be found. At the unit testing level, then
defects are program bugs, poor management of dependencies, and other
detailed errors.
At the acceptance test level then defects might be missing
functionality, bugs that involve some interaction between fine-grained
components, or that the requested feature doesn’t work the way the
customer intended.
At the release level, defects may be a lack of documentation, poor
usability, load or performance-based bugs not addressed by acceptance
criteria, or other high-level issues.
The process of eliminating error at different scales is one of the
most mathematically efficient methods for solving partial differential
equations. Developers that iteratively fix errors at varying levels in their
software development process are performing a process analogous to multigrid on
the defects.
Just as different sorts of smoothing techniques are better at
different scales (eg. Direct methods for coarse-grained solution),
different sorts of testing techniques are appropriate for scales in the
testing process.
Developers cannot rely exclusively on UnitTesting,
AcceptanceTesting, or ReleaseTesting. You really have to apply all of those processes to
your software product, and you have to apply them iteratively, improving
the overall software quality with each iteration.
|
|
8/27/01
Sometimes I hear people say the you don’t do design in lightweight
methods (such as Extreme
Programming). This is
simply not true.
Lightweight methods are all based on the principle that the methodology
should serve the software project, not the other way around. If you need to UML design (and
you most certainly do), then by all means do it.
Design in XP is based on scope.
You alternate between scopes in an iterative manner and release
production level code at regular intervals.
To illustrate how I use scope in lightweight design I will borrow from
Alistair Cockburn’s
metaphore of a software project as a lake.
I like to jump right into the lake and
swim. Before creating any
new class, I create a unit test in a
sub-package called "com.x.y.junit". Then I start writing assertions about the code should
do.
As soon as I start wondering how my
class will fit in with the rest of the architecture, I write some class
and package diagrams in UML
up on the white board beside my desk. Usually I have that diagram as my roadmap of what I
need to write next. I can
also use it to discuss with people where I am in the project. I like to think of level of
design as flying over the water surveying the situation.
When
I come across something tricky with a complex set of states and
interations, I find sequence
diagrams really useful. Drawing
them has the feel of coding because you are swimming around with the
fish, but you have much less invested in it than coding and a good
sequence diagram can keep you on track while you add in a set of objects
for a complicated business process.
When
I don’t need the design diagrams anymore, I just erase. My attachments are to the
business value in my code, not the design that came before the code.
|
|
7/16/01
A few days ago, someone claimed to me that studying non-blocking IO
and socket-level communication was not really useful. Much of that stuff
was being done by EJB servers and it wasn't really worth the time. Furthermore,
Java threads are just fine and their difficulty is just because of a lack
of training.
Nonsense. When you need a scalable system for many clients,
non-blocking IO is the
simplest thing that could possibly work. On a superficial level,
non-blocking IO is not the simplest thing. It is certainly more
complicated to create a Selector, open a SocketChannel, and multiplex the
results than it is to just open up a ServerSocket. However, if you are
dealing with multiple connections, then you will need threads, and
threads add a level of brittleness and complexity that make
single-threaded, non-blocking IO simpler than threads.
Is the latest JDK
1.4 NIO Package the simplest thing that could possibly work? Is it
ready for prime-time applications? I don't know yet. I am investigating
it with a series of articles and test programs.
|
|
7/14/01
I just returned from a visit to the Owl Mountain Software main offices
in Gould, Colorado. I had a lot of fun writing about Non-blocking
IO and watching hummingbirds do battle. It is certainly amusing to
see such small animals be so aggressive. Rufous hummingbirds
are the meanest and they pick on the Broadtail hummingbirds.
The Broadtails have a beautiful trill.
The big excitement was that a bear broke into my car and left huge
claw-marks on the vinyl.
|
|
5/03/01
A friend revived Jamie Zawinski's famous
resignation letter and sent it to me. It reminded me
of Philip Greenspun's posting on
the bust-up of ArsDigita.
At first, I wanted to draw a parallel between the demises of
two open-source software projects, but then I realized that
that the link wasn't open source, but that they were both
victims of VentureCapital avarice. So many good software
people with big dreams were burned by the venture capitalists
from 1997-2000.
I worked for a company called
PartNET. It was and remains the biggest professional
influence of my life. We were bought out by a venture firm
called Medibuy and that was the beginning of
the end. Before Medibuy, PartNET was a profitable software
development company. In the beginning, Medibuy, merely sucked
all the
developers' time away from existing customers, but as they hired
more and more incompetent officers, they began draining
PartNET's talent as one-by-one, developers got fed up and
left. Finally, with all the money gone
and nearly all the developers gone, PartNET
is struggling to become the company it was before Medibuy got involved.
As I look back on the choices
that were made, Don Brown (the founder and CEO) asked me if
we should go with Medibuy or
Remedy and I said, "without a doubt,
choose Remedy." They were a decent software company that had a
real partnership to offer. However, ego and greed
together are a powerful motivator and $12 million in funny
money was worth more than $8 million in cash, because in a
couple of years, we were going to go public, bilk the day
traders, and we would all be millionaires. Yeah,
right.
Unfortunately, Don chose Medibuy. PartNET lost. Everyone left and now Don
is trying to build the company back as Medibuy spirals hopelessly into
DotComOblivion.
|
|
4/29/01
As threatened, I posted the Xiris J2EE to the open source site.
The current version is 0.1.1 and the target version is 1.0 which
will be a well-rounded set of J2EE tools based on using XSL
Templates to generate Java code. Unlike other automated EJB
tools, the Xiris Webkit doesn't disguise the wizardly workings.
Every deployment descriptor or template class is translated
from an XSL document.
I was a little ambivalent about releasing Xiris under the
GNU General
Public License, because it can be a real nuisance for
anyone trying to use my code to develop commercial software.
For the record, although the Xiris stuff itself is GPL, the
resulting code is yours. Yes, yours. Just don't sue me.
|
|
4/19/01
Check out my
Generating EntityBeans with XSL Templates
in the latest OCI Java News Brief. I plan to write a series of
articles on using XSL to build wizard tools for developing
J2EE applications. The
Xiris J2EE Webkit is really turning into a rich environment for
exploring various murky details within the J2EE spec.
If people bug me, then I will get off my butt and put the source
into SourceForge with the rest of the Xiris stuff.
|
|
4/12/01
Cultural relativism is the idea that
right and wrong are determined in large part by the
culture. Corporate Cultural Relativism is an
art that many developers miss entirely and this leads poor
communication.
Corporate Cultural Beliefs of right
and wrong in information technology are especially
ambiguous, because right and wrong in are technical details
that constantly
change.
Furthermore, in a corporation, the
Corporate Cultural Beliefs are tied to large sums of
money; therefore, not only are they ambiguous, they
are also deeply felt and deeply defended.
Thus you have the crux of a
miscommunication: Deeply held, ambiguous beliefs.
For instance, one company may be in
the business of staying on top of the latest technology
trends. It is important that they know what the X.Y
version number of the software does, what is coming out, and
so forth. Hence, they are always reading up on specs,
and know the cutting edge
well.
Another company is in the business of
Object Orientation and are in the business of staying on top
of the latest OOAD trends. It is important that they
focus on software quality and maintenance
issues.
If a technology need is satisfied by a
latest version X.Y of JSoftware, but that technology need has
serious maintainability issues, then you have a conflict of
values. One consultant sees their reputation
standing on the cutting edge, and sees this particuliar
software as the future. The other sees that the
software is not maintainable and misses the fact that it will
get refined through the releases, because their focus is not
on the latest and greatest refinement of JSoftware.
|
|
4/1/01
People look at me strangely when I say that software is 90% communication and 10%technical. I am devoting the month of April to exploring this idea. There are four basic types of communication: Assertive, passive, aggressive, andpassive-aggressive. In a development meeting the assertive communicator will say,"This is the way we should do it." The passive will say, "Looks fine to me." The agressive will say, "Sure, you could do it like that, if you wanted to do itthe stupid way." The passive-aggressive won't say anything, but will
get with another passive-aggressive afterward and talk about what an asanine idea that was. Software developers are especially prone to passive-aggressive communication. Maybe they do it because its fun, or maybe they don't have the courage to be wrong, ormaybe because it gives them a sense of power. But they do it, and in my experienceit is the number one cause of project failure.
|
|
3/25/01
A simplistic view of between software as Art and software as Work
might be separate whether we are doing it for ourselves or for others.
In the musical,
Sunday in the Park with George there is a verse, "Work
is what you do for others -- Liebchen -- Art is what you do for
yourself."
The "Circle of Life" chapter in
XP
Installed outlines
a fairly profound idea of the relationship between the customer and the
programmer on an XP project. The customer's job is to prioritize
business values within a software project and the programmer's job is
to assign costs to those values and build it. In a utilitarian universe
there is a healthy level of communication that leads to a software
product containing those features with the highest business value.
Where does that leave the developer in the not-so-utilitarian universe
of Software as Art? Is there a place for software that closer to
"
A Sunday Afternoon on the Island of La Grande Jatte" than
wedding
cakes? Not that wedding cakes are necessarily bad: They taste
good, are beautiful, are defined by customer, and make the developers
a lot of money.
What does the "Circle of Life" mean in terms of the software itself?
Is it just a dramatic overstatement to say that
the Circle of Life taken to its ruthless logical conclusion yields "Never
Add Functionality Early?" Or, does the "Circle of Life"
have safeguards to ensure the software is
beautiful and simple, rather than garish and kitschy?
Rather than define an abstract class
class and subclass a few obvious counterparts, we must
wait until the requirements motivate the abstract class? As a
developer, I have a hard task of defining: "What is the
simplest thing that could possibly work?"
When I do software, I want to enjoy working with it. I want to enjoy
looking at it. Polymorphism is to me one of the joys of software.
Patterns as well. Sometimes its a joy to discover than I can
implement a pattern and even if it may be unnecessary. Someday then
someone will look at my software and say, "Oh, very nice, its the Visitor Pattern."
However, maybe they will look at my software and say, "What a waste
of a very nice pattern, how are we going to
refactor this?"
With hard choices to make, a criteria for adding the functionality and
design is, "Can we open this software up to the world? Can we release
open-source, have everyone look at it, criticize it, bug it, and feel
good about the work we did?" To me, even if I won't open something
up, my ideal would be to work as though I will.
|
|
3/16/01
I posted the Xiris software to
Source Forge today. It struck me how nicely they have integrated
the standard project development tools (bug tracking, revision control,
feature requests, project management) into a web interface. It
would be very interesting to try a commercial project using
sourceforge as the development environment.
|
|
|
