These are not opposites

(Originally posted 2003.Jul.07 Mon; links may have expired.)

Is "passive" the opposite of "aggressive"? In software development, is "disciplined" the opposite of "agile"? I don't think so.

A passive person may be inactive, but still denies or resists others and context, just like an aggressive person. (Virginia Satir "self, other, context" concepts.) A healthier alternative to passive is "accepting" -- not active, but not in denial. A healthier alternative to aggressive is "assertive" - actively protecting one's self, but not denying the rights of others nor denying the reality of the context.

Dr. Barry Boehm (with Richard Turner) has a book coming out titled Balancing Agility and Discipline: A Guide for the Perplexed. The title does not reassure me that Boehm really understands agile development (in spite of the fact that he invented the "Spiral Development" model - an incremental/iterative process). We know that XP is the one of most disciplined of the agile methods, and that no process will work well with undisciplined people. The blurb from the back cover sounds better than what the title suggests:

Agile and disciplined: These apparently opposite attributes are, in fact, complementary values in software development. Plan-driven developers must also be agile; nimble developers must also be disciplined. The key to success is finding the right balance between the two, which will vary from project to project according to the circumstances and risks involved.

Fine, but then it goes back to saying these are opposites:

Developers, pulled toward opposite ends by impassioned arguments, ultimately must learn how to give each value its due.... The authors describe a day in the life of developers who live on one side or the other. They expose the bureaucracy and stagnation that mark discipline without agility, and they liken agility without discipline to unbridled and fruitless enthusiasm.

Alistair Cockburn, on the XP Mailing list, says this about "agile":

"Agile" is a value-set, a prioritization of whatever you think it means over
other things.

Therefore, it is not so meaningful to ask, "Can agile be used in this
situation?" Rather, the question is, "How agile can we be in this situation --- How can we be agile in this situation?" ... and then you get various interesting answers.

Picking up the theme of the value sets from my previous append, one might
look at a missile guidance system and say, "time to market not crucial.
people-centric not crucial. cost not crucial. correctness is crucial." In that situation, one could look to blend correctness-prioritized development with agile-prioritized development to get an appropriate mixture of the two.

Cockburn also wrote:

Consider "agile" development as a particular specie of development, e.g., a
Bengal tiger. Then asking "what is the opposite of agile development?" is like
asking "What is the opposite of a Bengal tiger?" Is it an elephant, a mosquito, or perhaps a non-Bengal tiger, or a Bengalese non-tiger?

Brad Appleton came up with a nice definition of agile (notice the first letter of each point):

• Adaptive - plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements (as opposed to predictive methods that attempt to develop comprehensive and detailed plans/designs/requirements "up front").
• Goal-driven - focus on producing end-results (working functionality) in order of highest business value/priority (as opposed to being task-driven, document-driven, process-driven, or risk-driven).
• Iterative - not just iterative, but *highly* iterative, with very short development cycles, very frequent releases, and exremely frequent+regular feedback.
• Lean - simple design, streamlined processes, elimination of redundant information, and "barely sufficient" documentation and methodology.
• Emergent behavior - quality systems (requirements, architecture, and design) all "emerge" from highly collaborative, self-organizing teams following an initially minimal set of simple, generative rules, and working in very close interaction with stakeholders.

Dinosaur Brains versus Survival Rules

(Originally posted 2003.May.14 Wed; links may have expired.)

Way back in 1989, there was a book I read called Dinosaur Brains by Bernstein and Rozen. I thought it was a good read at that time. Their thesis is that irrational behavior, including territoriality, fear, flight, and aggression, are remnants of our reptilian ancestry, and the book gives advice on appeasing and working around these behaviors. By the way, the book is still in print, in paperback.

The problem with this idea is that reptile behaviors are hard-wired... they can't be changed. A better idea is "survival rules" that we learn as children (or later) and apply in sometimes inappropriate situations. When we identify our survival rules, we can modify them.

Wayne Strider's book Powerful Project Leadership talks about survival rules, as does Jerry Weinberg in Becoming a Technical Leader: An Organic Problem-Solving Approach and More Secrets of Consulting: The Consultant's Tool Kit.

An example I read about on a mailing list recently was pair programming. Someone (I think it was Robert Martin, but it could have been Joshua Kerievsky, or someone else), described a programmer that had some difficulty adapting to pair programming.

To make her comfortable with it, she would study the task/problem for some time by herself before pairing. The writer observed that she wasn't comfortable with being asked questions that she didn't know the answer to. Eventually, she got comfortable with pair programming, and no longer needed to study before pairing. It seems to me that her survival rule was something like "I can't show anyone that I don't know the answers" and she successfully modified the rule.

Tesugen.com on Documentation

(Originally posted 2003.Jul.04 Fri; links may have expired.)

Peter Lindberg wrote:

The assumption that lies behind the question You have documented this, haven't you? is that code is inherently unreadable and that there must be a manual to explain it. Many projects indeed are like that. Many projects have grand vapor architectures that exists only in the minds of those who have devised them, and can't be found anywhere in the code. Any document in such a case only reflects the vapor architecture, and is of little help to understanding the code. Let's hope there are still survivors to answer your questions.

and

My goal donor asked me, You have documented this, haven't you? to which I replied, No, except for the 570 or so automated test cases Malte and I have written during the course of the project. Each test case captures a micro-scenario in the life of the system, by setting up the objects involved, telling them to do something together, and verifying the outcome. And the fact that they are executable means that a programmer new to a team, besides having an explanation of the code to read, written in code itself, can execute that codee to see if the system still works. So it's better than documentation.

Extreme Planning

(Originally posted 2003.May.06 Tue; links may have expired.)

Extreme Programming has planning at several levels.

Release Planning, where the entire project is divided into small user-centered features (stories), written onto index cards, estimated by the developers, and prioritized by the story-writer. The story-writer tentatively assigns the stories to iterations (tentative, because the amount of work that can be done per iteration is only a guess when they do their first release plan), with an end-user release planned in three months or so, when enough features will have been implemented to make a release worth-while.

Iteration Planning, where a set of stories is selected by the story-writer (just enough to fit into one iteration as measured by the previous iteration). The developers flesh out the stories with the story-writer and (in some teams) break down the stories into tasks, writing the tasks onto index cards. Many teams put the cards and tasks are put on the wall.

When two developers get together to pair program, they may break down the task (or story) that they are working on into list of tests to do, and a design in UML or whatever notation they think best. This may be written on index cards or a white board. Then they implement one test at a time in test-driven-development.

I asked on the IXP mailing list if people had used the Extreme Programming's Planning techniques (sometimes called the Planning Game) for organizing home chores or other non-work things. Yes they have.

Jiva DeVoe planned a cross-country move on index cards, including estimates, posting them on the wall, etc.

Joshua Kerievsky tells us that Francesco Cirillo, who does XP training in Italy, uses XP-style planning to organize and execute a weekly dinner, with student volunteers doing most or all of the cooking.

Amy Schwab planned a wedding using her techniques of "project community" and "adaptive project methodology". She wasn't familiar with XP planning, but she also used "cards on the wall" (post-it notes instead of index cards). She let go of traditional project "control-oriented" planning, and let family and friends be in charge of "their own quality of experience."

Diana Larsen tells us that http://www.shesintouch.com/ does home chore planning similar to XP's planning, including using index cards, estimates, and measured velocity (and training workshops) [and this predates XP by 20 years].

Fitting In and Standing Out

(Originally posted 2003.Jul.03 Thu; links may have expired.)

A quote from Seth Godin's Purple Cow:

If you're remarkable, it's likely that some people won't like you. [...] Criticism comes to those who stand out.

Where did you learn to fail? If you're like most Americans, you learned in first grade. That's when you started figuring out that the safe thing to do was to fit in. The safe thing to do was to color inside the lines, don't ask too many questions in class [....]

A quote from Eliyahu M. Goldratt's Theory of Constraints:

We assume that the openness of these functions [marketing, distribution, etc.] will be enhanced by the positive results achieved in the other functions [production and material...]

What we found out was this is certainly not the case.

[...] The emotional resistance, which already exists, prevents almost any meaningful dialog. The only way to open the Throughput channel in these case was through personnel changes. 

The lesson today is loud and clear. Before any function can go on an ego trip, demonstrating and waving results (and by that digging its own grave) -- before any function can start individual improvements, all functions should decide together on a common way.

Extreme Programming is one of those "Purple Cows" that Seth Godin talks about -- it is "remarkable". Its value comes from not fitting in with what the majority of programmers do. It does more testing and more design, and requires more discipline. The documented bug-rate reductions of projects that converted to XP and their improved time-to-market are actually not believed by many, if not most managers, even when the project is within their own company.

"Selling" XP also has to recognize the manager's fears of not fitting in. Heed Weinberg's Laws of Consulting: "In spite of what your client may tell you, there is always a problem. No matter how it looks at first, it is always a people problem.... Never promise more than a ten percent improvement. (If it were possible to achieve more than a ten percent improvement, there must have been a problem, but there isn't a problem, so...)"

I'm looking to the "project community" practices of IXP to help keep an organization from rejecting XP. Retrospectives and Readiness Assessments that include more than just the programmers. Management Tests. The IXP value of Learning.

Test Driven site, Blogger Security, Corporate Cultures

(Originally posted 2003.May.19 Mon; links may have expired.)

Dave Astels points out another TDD resource: http://www.testdriven.com/.

James Robertson points out a security issue with the blogger API: "This is why my posting API uses encryption, and why I don't support the blogger api on this blog - that pathetic excuse for an API passes usernames and passwords in the clear." My blogger friends need to make sure they change their passwords frequently.

Interesting article by Art Kleiner about multiple corporate cultures here: http://www.well.com/user/art/s%2Bb32001.html. He describes three cultures that live within single companies:

• The first, the operational culture, is the culture of day-to-day line managers - the people who get products and services out, procure supplies, process bills, and make delivery trucks run on time. Operations people appreciate teams; they understand, as nobody else does, how to get a bunch of disparate individuals to pull together.

• If you want to find facility with deals, leverage, and capital flow, you have to look to the second corporate culture, the executive culture. Members of this culture typically include the CEO, the board, the business-unit leaders, and the finance-oriented staff.... their jobs and passions lie in shepherding the cash flow that keeps the organization alive.

• The third corporate culture, the engineering culture, is personified by engineers and technical specialists, particularly in information technology and process engineering. They are stimulated by puzzles and problems, and by the design challenge of creating an ideal world of elegant machines that operate in harmony.

He also describes briefly how corporate cultures at the CEO level have changed over time. The most successful companies were "monopolist" until anti-trust laws were passed; "manufacturing" after that—that is vertically integrated "operations" cultures; "marketing-oriented" after the Great Depression and up to the "golden age of advertising in the 1960's"; and "finance-oriented" oriented after inflation hit in the 1970's.

Now that we are living in what seems to be deflationary times, what CEO-level culture will become successful?

Socratic Questions and Experiential Learning

(Originally posted 2003.Jun.30 Mon; links may have expired.)

One way of teaching, developed 2500 years ago by Socrates, is to ask questions and let the student work out the answers. In Theory Of Constraints by Eliyahu M. Goldratt, the author credits Socratic questions for the success of his previous book The Goal. In The Goal, a consultant helps the main character with advice in the form of questions. The reader follows the main character as he tries to come up answers to the questions; and, Goldratt says, the readers come up with the answers themselves a page or two before the main character does. (I know I did.)

Inventing their own answers motivated the readers to see if the main character came up with the same answers, and in many cases this excitement further motivated readers to apply the lesson of The Goal to their own factories.

Goldratt also talks about the stages of "science" - classification, correlation, and effect-cause-effect. In classification, we could observe that students learn things in various ways. In correlation, we could observe that some students learning via Socratic questions were more excited about their learning than others. In effect-cause-effect, we could theorize why this happens, and use the theory to make predictions which could be invalidated (or validated) by experiment.

Goldratt goes on to say that an experiment may not completely invalidate a theory, but may constrain it. For example, Newton's laws of motion are valid for speeds we see on Earth, but are constrained by other effects when the speeds are near the speed of light.

We can have a theory that Socratic questions can be effective, because someone inventing their own answers feels ownership and the excitement of invention. In some cases they've done a lot of work, and finding the answer is a big reward. However, we can also observe that Socratic questions often fail in practice... the students get irritated by that smug teacher who obviously knows the answers, but isn't giving them out. The resentment can be very strong. The questions can have responses like "Why are you asking us?" followed by arguments about motivations and agendas.

Another style of teaching that also lets the students find their own answers is called "experiential learning." In a typical case, the teacher (or, as some preferred to be called, the facilitator), sets up a "simulation" where the students can try something out in a safe environment, followed by discussion. There's no initial question, just "try this out". In the discussion afterwards, the questions could be "What do you think about X after doing this exercise" or "What were you feeling?" These are non-threatening questions, and students don't feel that the teacher already knows the answer.

In the Agile Development Conference I just attended, some of the workshops used experiential learning. In XP Coaching workshop, facilitated by Ron Jeffries and William Wake, the exercise involved some people coaching other people doing origami (from an origami instruction manual). Some other workshops also involved simulation/practice and discussion.

Ron tells us that XP Immersions that he participates in are doing more experiential learning and less lecture. Instead of lecturing about pair programming, they have the students pair program, probably followed by discussion and reflection on what happened when they pair programmed. The whole point of many training courses is to just get the students to do reflection and discussion - and this is the point of Retrospectives... enabling learning in the organization and team.

Think about learning some skill or getting answers to some of your harder problems, not necessarily a problem with technology; in your own experience, when someone told you the answer to a problem or question, did you value it as much as when you came up with the answer yourself, or practiced the skill by yourself?

Practices, Links, and Books

(Originally posted 2003.May.20 Tue; links may have expired.)

Esther Derby reminds us that learning comes from practice and feedback, not just training courses, and links to one of her articles at StickyMinds.

Aside: StickyMinds is the on-line forum associated with Software Testing and Quality Engineering (STQE) magazine, which published my article on adopting XP last year (July/August 2002, order the back-issue!).

Extreme Programming defines "12" practices, though different ways of counting takes it up to 13 or more. Don Wells lists way more than that at http://www.extremeprogramming.org/rules.html. You should know that "they are just rules" meaning that you won't lose your license to program if you break a rule accidentally or with good reason, though failing to follow all of the practices often makes more work for yourself and your team.

Practicing is becoming a popular topic. Ron Jeffries wrote of "etudes" and Dave Thomas is writing about "katas". Other web-logs have discussed this topic, with analogies to music practices, authors writing drafts of papers or books, and so on.

William C. Wake has posted test-first "challenges" on the XP mailing list in the past, for people to practice on, and now has a book called The Refactoring Workbook due in July. Preview chapters are on-line: http://www.xp123.com/rwb/.

On other topics, Mike Cohn is writing a book on User Stories (Requirements/Features in XP lingo) and set up a web-site on this topic at http://www.userstories.com/. I haven't read the chapters that have been made available yet, but I plan to soon.

And David Anderson recommends a book on the agile management mailing list:

What Management Is by Joan Magretta. He's enthusiastic: "This book was nominated by no less an authority than The Economist as one of the 10 best books of 2002. That's what prompted me to read it. In summary - it is worth every cent! It's management summed up in a nutshell."

Conflict Haiku and other Writings

(Originally posted 2003.Jun.18 Wed; links may have expired.)

Some good papers by Rick Brenner of Chaco Canyon consulting... the Point Lookout email newsletter.

Conflict Haiku: "When tempers flare, or tension fills the air, many of us contribute to the stew, often without realizing that we do. Here are some haiku that describe some of the many stances we choose that can lead groups into tangles, or let those tangles persist once they form."

When Naming Hurts: "One of our great strengths as Humans is our ability to name things. Naming empowers us by helping us think about and communicate complex ideas. But naming has a dark side, too. We use naming to oversimplify, to denigrate, to disempower, and even to dehumanize. When we abuse this tool, we hurt our companies, our colleagues and ourselves."

Let Me Finish, Please "We use meetings to exchange information and to explore complex issues. In open discussion, we tend to interrupt each other. Interruptions can be disruptive, distracting, funny, essential, and frustratingly common. What can we do to limit interruptions without depriving ourselves of their benefits?"

Full list of past issues: http://www.ChacoCanyon.com/pointlookout/topicalarchive.shtml

Unit Testing In Java, Duplicate Code in Java GUIs

(Originally posted 2003.May.28 Wed; links may have expired.)

Johannes Link announces that the book Unit Testing In Java by Link and Frohlich, is now available for purchase, even though Amazon says it isn't yet. Link says the book teaches Test Driven Development in Java, covering GUIs, web-applications, databases, multi-threaded applications and other advanced topics. A sample chapter is available here: [PDF, 28 pages] http://www.bhusa.com/bookscat/samples/1558608680/1558608680.pdf?mscssid=W2B78S2RV83D8K9W260JPX1W0DUJ9DC7.

The sample chapter on test-first Swing GUI programming isn't that different than other writings on Java GUI test-first. Near the end of the chapter they discuss JFCUnit, and briefly mention AWT Robot, neither of which they recommend for typical test-first unit testing. I will order the book and read it.

One nit I'd like to pick: the authors make the JFrame subclass an ActionListener, listening to the "Delete" button and the "Add" button. This is very common in Java books, but that doesn't make it right. Making the JFrame an ActionListener on multiple widgets means we have some tightly coupled pieces of code (reformatted - I like the braces to line up):

public class CatalogEditor extends JFrame
    implements ActionListener, ListSelectionListener 
{
...
    private void addAddButton() 
    {
        addButton = new JButton("Add");
        addButton.addActionListener(this);
        getContentPane().add(addButton);
    }
... etc. (similar code to add "Delete" button)...

    public void actionPerformed( ActionEvent e ) 
    { // blech... nasty.
        if ( e.getSource() == deleteButton ) 
        {
            deleteButtonClicked();
        } 
        else if ( e.getSource() == addButton )
        {
            addButtonClicked();
        }
    }
...

This is nasty because it couples the JFrame too tightly with the buttons it is listening to. If you add another button, you also have to change the actionPerformed method. You would rather not have to change multiple pieces of code when you add "just one more thing". There is a better way (using anonymous subclassing) - don't declare the JFrame to be an ActionListener; instead, pass anonymous implementations of ActionListener to the buttons like so:

public class CatalogEditor extends JFrame
{
...
    private void addAddButton() 
    {
        addButton = new JButton("Add");
        addButton.addActionListener( new ActionListener() 
            {
                public void actionPerformed( ActionEvent e ) 
                {
                    addButtonClicked();
                }
            } 
        );
        getContentPane().add(addButton);
    }
... etc. (similar code to add "Delete" button)...
    // now there is no need for an actionPerformed method that uses 
    // cascading if statements.

I also want to point out the code duplication we have: creating the "Add" button is almost the same code as creating the "Delete" button (not shown). That kind of duplication seems to be common in Java GUI programming, but it is really unforgivable when you have lots of dialogs and buttons. What can we do about it?

First, we could have a DialogCreator class that reads the button names from a string list, creates them, and adds them to the ContentPane of the JFrame subclass (which it could also instantiate). It could also read the layout name and other information needed to lay out the GUI. In order to get the "Add" button's listener to call the method "addButtonClicked" in the JFrame subclass, we need to use the Java reflection API. Here's the pseudo-code:

class ListenerCaller implements ActionListener
{
    public ListenerCaller( Object objectToCall, String methodNameToCall )
    ....

    public void actionPerformed( ActionEvent e )
    {
        ... reflection to call methodNameToCall on objectToCall...
    }
}

Notice that the ListenerCaller class doesn't care what kind of class it is calling. You could connect your GUI buttons to your model classes directly this way. Apple's Cocoa does something similar - the Cocoa widget classes (menus, buttons, etc.) take an object (called "target") and a method selector (easily created from a string) and call whatever object and method that you specify. You would normally do this specification in the Interface Builder.

class DialogCreator
{
    ...
    public void CreateDialog( textfile or string list )
    {
        String jfClassName = read JFrame subclass name from textfile;
        JFrame jfObj = ... reflection to create object given jfClassname;

        String layoutName = read layout name from textfile;
        // also read number of arguments, etc... this can get complicated.
        Layout lay = ... reflection to create object given layoutName, 
             number of arguments, argument types, etc.;

        jfObj.getContentPane().setLayout( lay );

        while not end of buttons
        {
            String buttonName = read button name from textfile;
            String methodToCall = read method to call name from textfile;

            JButton aButton = new JButton( buttonName );
            aButton.addActionListener( new ListenerCaller( jfObj, methodToCall ) );
            jfObj.getContentPane().add( aButton );
        }
    }
}

A single DialogCreator class like this removes button-creation code from all your Swing GUI code. Given that GUIs have a nested hierarchical structure, you probably want your text file to reflect that structure as well, using XML, and creating all kinds of widgets, not just buttons. It turns out that someone has already done all this work (and more) and called it XMLTalk.

I haven't used XMLTalk myself, because I haven't needed to do very much Java GUI programming, and I'm not sure about its license agreement. I haven't downloaded the source, but I have looked at the white papers and other documentation. It is worth studying to see how ValueModel adapters and other helper classes can be used to decouple your GUI code from the model code, and to decouple some of your model classes from each other. I should point out that XMLTalk is based on concepts first(?) implemented in VisualWorks Smalltalk. You should check out their product as well.

---

UPDATE

---

(Originally posted 2003.Jun.02 Mon; links may have expired.)

Previously, I used my review of the sample chapter of the book Unit Testing In Java by Link and Frohlich to launch my diatribe against the typical Java-book method of creating widgets in windows/dialogs. Johannes Link send me this comment:

Subject: Unit Testing in Java



Hi Keith,



Compliments on being so quick in reviewing the sample chapter of "Unit

Testing in Java". That's really impressing. 


One thing I'd like to comment on: You're perfectly right when saying that

implementing ActionListener in the window class itself usually leads to loads

of duplicated code. The code in the book, however, is in a temporary state. As

long as there are only two buttons the code is easier to read (IMO) than

when using anonymous inner classes.  Refactoring to a different solution would

certainly take place during one of the next enhancements. The point is: Having

the tests in place allows you to perform this refactoring on stable

ground... 



BTW, your blog really is worth reading.



best wishes,

Johannes Link

When to do refactoring is certainly worth further exploration. Martin Fowler has the "three strikes" rule to remind him to refactor away duplication when a third instance is seen. Extreme Programming recommends "once and only once" to refactor after the second instance is seen. But when your current task is test-driving a dialog or widget-filled window, at what point do you refactor to a dialog-creator class - after the second button, or after the second dialog, or never?

La Internacia Lingvo

(Originally posted 2003.Jun.08 Sun; links may have expired.)

When I was in high school, in the 1980's, I discovered a book on Esperanto at a library and studied it. I bought a few books, and even acquired (I don't recall how) a record album of folk songs recorded in Esperanto. It was interesting, but I never had anyone to speak it with. For academic credits in high school and college, I took Latin, another language I didn't use for speaking purposes. In case you haven't heard of it, Esperanto was one of the first "artificial languages," a language created to be culture-neutral, to enable international communication. It has very simple rules of grammar, and a vocabulary adopted from root words of many European languages. Esperanto is reported to be ten times easier to learn than a typical European language.

Created over a hundred years ago, Esperanto was not just a language, but a movement for international understanding and peace. It was denounced by Hitler and banned in Nazi Germany. The USSR in 1938 shot or deported Esperanto speakers. Pre-WWII Japan mistreated and sometimes executed Esperantists. In the USA during the McCarthy era, Esperanto was associated with Communism (and perhaps some American Communists were using it as a 'secret language'.)

Perhaps at its height of popularity, between one and ten million people spoke Esperanto world-wide. In recent years, it has been reported that Klingon and Elvish are two artificial languages with more speakers than Esperanto, though I think more people are actually fluent in Esperanto than Klingon.

Why am I talking about Esperanto? Partly because I just read an article about it in the San Francisco Chronicle, which reports that about 25 people in the Bay Area get together to speak it monthly. It quotes ELNA vice president of public relations Charlie Galvin as saying "For me, I like Esperanto because it's like a secret club. I like the fact that few people know it. It makes it special." That is so depressing, in light of the intent of Esperanto's creator.

Esperanto will always be a little-known language because there is no economic reason to learn it - and that's just fine with the Esperantists. The Esperanto-enabled travel service is free and non-commercial. In this day of international organizations (both commercial and non-commercial), Esperantists are no longer making the case that that a simple-syntax, easy-to-learn language could help people communicate with each other on a level playing field, with value gained in commercial as well as non-commercial arenas.

Another reason I'm talking about Esperanto is that it reminds me of Smalltalk. Like Esperanto, Smalltalk has a simple syntax that is pretty easy to learn. Esperanto was invented by an idealist wanting international communication. Smalltalk was invented by idealists who thought it could be a computer language easy enough for children. Like Esperanto, few people today have an economic reason to use Smalltalk. No big companies are hyping Smalltalk the way Sun hypes Java, or Microsoft hypes C#. Even IBM, which sells a Smalltalk environment, is putting more energy into Java than Smalltalk.

The rules of grammar for Esperanto can be written down in few pages, including all the exceptions. The rules of Smalltalk's grammar are also simple. This PDF explains Smalltalk syntax in relatively few pages: http://www.speakeasy.org/~podenski/stug/reading-smalltalk.pdf.

Smalltalk syntax is unusual today, though I find it easier to read than Perl or Ruby. Objective-C is a language that adds object-oriented constructs to the C language using a syntax similar to Smalltalk. One of my coworkers complained "why isn't Objective C using Java or C++ syntax?" Because it predates C++. When Objective C was invented, Smalltalk was the leading OO language. Now Smalltalk is one of the language reported as dead or near-dead by Wired magazine.

Objective-C is regaining mind-share these days because it is the recommended language for implementing GUI applications on MacOS X using the Cocoa class library. There is an economic reason for people to adopt that language -- it is the easiest way to put a really nice GUI on non-gui unix-compatible code on MacOS X. At least five books on Cocoa programming have been published in the last year on Cocoa, and every one teaches the OO parts of Objective C in the opening chapters.

Unlike some Smalltalk implementations, Objective C on MacOS X plays well with others. Linking C libraries and Objective code together is trivial. Even though the Cocoa class library is implemented in Objective C, you can write Cocoa-using applications in Java, Python, AppleScript, Ruby, and a Smalltalk-like scripting language called FScript. (C++ is too "static" to easily interoperate with classes written in dynamic languages, but Apple's version of 'gcc' allows mixing C++ and Objective C code if one is careful to cope with the differences in object allocation and deallocation.)

I would use Smalltalk it if had native GUIs on MacOS X and Windows. If it interoperated with Cocoa on MacOS X. If it easily interoperated with C libraries. If it could be used to implement shared libraries (TWAIN plugins) and other non-application code on the two platforms I need to support, and not have to be written in "dialect dependent" forms on each platform. If it didn't freak out my coworkers. If it wasn't a "secret language."

Refactoring is Not Rewriting

(Originally posted 2003.May.26 Mon; links may have expired.)

I'm concerned that people are getting sloppy about their usage of the word "refactoring." I had a short dialog with someone asking about refactoring, bug-fixing, and testing, where the questioner revealed that he had not read Martin Fowler's book "Refactoring: Improving the Design of Code." If he had read the book, then he would have known that refactoring is improving the design without changing behavior, and could have avoided problems from combining bug-fixing with design improvements.

If you're writing or fixing code, particularly in an object oriented language, you must buy and read Refactoring: Improving the Design of Existing Code by Martin Fowler.

That book and Design Patterns by Gamma, et. al. are essential reading no matter what methodology you might be using.

In test-driven design, refactoring is the design step: test, code, refactor, repeat.

Martin Fowler has a blog/wiki (a bliki) here: http://martinfowler.com/bliki/, which I'm adding to my blog-roll. (I'm delighted to see I'm already on Fowler's blog-roll.) I'd love to make my site into a bliki, but unfortunately, my site is static (updated only when I'm adding a new entry) - there's no cgi. My time is full with working, reading, and blogging, so I probably won't get around to writing my own bliki software (though it would be a good exercise.)

That questioner I mentioned was asking about refactoring, bug-fixing, and testing legacy code. I forgot to point him to Michael Feathers, currently working on a book titled Working Effectively with Legacy Code, and the mailing list discussing the book, http://groups.yahoo.com/group/welc/, but I'll do that after finishing this blog entry.

Here's my advice on this topic.

First, keep refactoring and rewriting (bug-fixing) separate. These two activities may be done only five minutes apart, but you're wearing a different "hat" during each activity. Refactoring is improving the design of the code, while preserving its behavior. Bug-fixing is changing the behavior.

Since unit-testing legacy code is almost always difficult, try writing some automated acceptance tests before doing other changes. The acceptance tests will hopefully not need to be changed much during refactoring and bug-fixing activities.

When confronted by legacy code, my first step would be to review the sources, fixing up formatting problems - indentation and spacing. Badly-designed code is often badly formatted. This gets me familiar with the code without changing its behavior. This helps me understand the code. Doing this might seem too boring to do with a pair programmer, but the alternative would be to do code reviews, which are even more boring. If automatically reverse-engineering class diagrams and other UML diagrams is possible, I would do that.

If I have a bug to fix, I recommend writing an acceptance test or unit test that shows the bug's effect. Then track down where the bug is - what defects in the code cause the bug. I know from experience that it is really hard to get into the habit of writing the test before doing the debugging; I do think this test-first habit is a valuable one.

When you've found the code-defect, it can help a lot to do a little refactoring to make fixing the bug easier. Run the few tests that you now have and do manual testing to make sure that the refactoring hasn't changed any behaviors or broken anything. Then fix the bug, and run the tests to confirm that the bug is fixed. Then maybe do a little more refactoring in that area of the code and re-confirm that no behavior has changed from that refactoring.

At the beginning of this bug-fix/refactoring process, you will have to move very slowly - manual testing will take a lot of time. Trying to do too much at once will only slow you down when you find you've broken something and need to back-track. Don't forget to use source-code-control - check in frequently.

Resist the urge to refactor working code until at least the worst known bugs have been fixed.

For more on refactoring, check out http://www.refactoring.com/.