Crater Moon Landings

Is Coding Style Important?

Over at Artima, Frank Sommers writes How Important is Coding Style, and How Do You Enforce It?

I've come to believe that having a coding style is important, but enforcement is not. If programmers on my team can't adhere a style without having to have their wrists slapped by some tool or enforcement police, it's likely there are more serious issues lurking that will bite the team far worse than misplaced curly braces or indentation errors.

There is one kind of problem in the realm of keeping up a good, consistent coding style that I see regularly. In the case were the team uses and idea or other automated code reformatting that generates confusing and useless diffs in the version control system have a fairly simple, non-technical, solution.

It works like this: When you are preparing to edit a source file to make some semantically important changes and the automated code-reformatter also wants to move things around, do the change in two steps. Step one: let the reformatter do its cleanup, make everything pretty, but make NO other changes. Check in the file with a comment like "Reformat changes only" to indicate that the code hasn't really changed*. NOW make your real changes as needed, run your unit tests, etc, and check in with the actual change message.

Result: The diffs between what you changed and the original source are clear and isolated, yet there is a record in the changelog of the reformatting, which can be compared to the prior version (if needed) to see what the formatter did.

The extra effort is minimal for programmers who are serious about enforcing a coding style, while the benefits of being able to differentiate real changes from reformatting (and potentially help in identifying programmers who are checking in code that doesn't meet the style guidelines) are manifold.

* Note that sometimes reformatting code, even though there are supposedly no changes, will in fact result in changed behavior, especially in languages like Python where whitespace is meaningful, but even in languages where whitespace is mostly ignored. Another reason it's good to have a clear record in the source control of only formatting change check-ins.

Functions on the Heap

Robert C. Martin says in Modelling the real world, "OO was "discovered" when two guys who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived. Voila: objects!". In other words, functions on the heap. This is the legacy Kristen Nygaard and Ole-Johan Dahl left to the world of computer science and software development, now called Object Orientation. (There was another development related to C.A.R. Hoare's thoughts on records and associated operators, but that leads off in another direction.)

What does it mean for a function to be on the heap? Typically blocks are lexically scoped, and considered functions when they are named and can be called from other parts of the program. Well, ordinarily, in a block-structured language, when you enter a function a stack frame is created, and the parameters are either copied to or referenced from within that frame. Variables local to that block are uninitialized, and so must be assigned a value to be used. When that block, the function, exits, the stack frame is deleted and all the local variables become undefined once again, and the parameters revert back to the values they had before the block was entered. (By-reference parameters can appear to change if the value of the thing referenced was changed, but that's an additional complication we won't go into).

The next time that block is entered (the function is called) all that stack frame creation and initialization must be repeated. What Nygaard and Dahl did was to move that function onto the heap, where it continues to exist after it is created and called. In the next call to the function, the local variables are still at whatever value they were when the last execution of the block finished. What results is variables that retain their values as long as the program executes, but are visible only within the lexical scope where they are defined. That ends up being a very powerful and useful way to structure and organize programs. Once the block is capable of existing beyond a single invocation, it becomes useful to be able to name the blocks and refer to them from multiple places.

In the original Design Patterns book by the "Gang of Four", (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides), one of the principles is "encapsulate the thing that varies". By using the technique of functions on the heap, this "thing that varies" becomes not only the "variables" within a block, but the operations which are associated with the block as well.

Perhaps the most simplifying insight to be gained from looking at objects this way is that it says nothing about types, certainly not in the strictly defined way that is seen in languages like Java. Abstract data types and hierarchies of abstractions get a lot of attention in current programming practices. It's well worth the time to explore the implications of objects as long-lasting named functions on the heap.

Why Refactoring Isn't Popular

In The Refactoring Factor Esther Schindler wonders about the reasons behind a study that shows only 22% of developers consider refactoring important. Before writing the article She asked some questions on the agile-testing list and her article includes some of the points in the responses.

I want to focus a bit on her primary conclusion, that programmers can't get resources or buy-in to do refactoring.

Because the programmer's managers won't allow it

Somewhere I think I have the email directive that a project manager sent out at one job I was on that said, to paraphrase, that anything beyond the specific changes requested was a "refactoring effort" and therefore out of scope.

Now there is a simple explanation and a not-so-simple one for this. The simple one is the spread of what Martin Fowler wrote about in Refactoring Malapropism. I must confess I probably contributed to it in the above mentioned situation, and I'm still paying penance for it.

Now the complex explanation. Project management can be seen as the task of maximizing the completed features in the available time within the budget of money and people. In too many situations, the estimates of time required are abbreviated. This happens stereotypically by management, as Phillip Su writes in Broken Windows Theory , but it also happens because many programmers lack sophistication estimating. The programmers typically consider the time only to write the code and get it to compile and running, leaving out the other tasks that get the code from "done" to "shippable". One reason I've come to favor agile development styles is that they reduce the time and disconnect between those two states. Anyway, the result is that the schedules are wrong, the projects get behind, and the solution adopted by teams is typically to cut everything else except the promised features. Short term gain, for long term loss, because the technical debt builds up.

Now management has a hard time seeing the effects of technical debt. They see that as a project goes along and a product grows, adding new features and fixing existing code that doesn't work as desired takes more time and becomes increasingly more likely to introduce new problems. But by the time these manifest as the level of most projects, the technical debt has built up to dangerous levels. The typical example I give is what if a 5-star restaurant were to hire a lot of chefs and not enough dishwashers, and decreed that the chefs must ONLY cook, never clean up. Initially they'd be able to feed a lot of people, but as the dirty utensils and pots and pans build up, the chefs increasingly have to hunt for clean ones and a place to work. Gunk builds up on the grill. After a certain point, if we followed the typical IT shop solution, the restaurant would throw out all the dirty stuff, replaces the appliances that can't be salvaged, and if necessary hire new chefs.

Of course great restaurants don't work like that. They and their chefs are cleaning as they go, so that pan or knife that was used for the happy hour buffet prep gets returned to use for the dinner entree and then dessert.

Refactoring is cleaning the kitchen while you cook. It's not sexy, it doesn't make the souffle fluffier or the piecrust flakier, but it's a given that if it's not done, there won't be any souffle or pie at all.

Junit 4 Official Release?

This morning I got email from sourceforge about a new release of Junit. I went and looked at the release notes and found that it's labeled Junit 4. Joseph Ottinger posts on the Server Side forums

Personality Styles in Adopting Agile

A brief except from the work I submitted to the Experience Reports track for Agile 2006 with Jason P. Stevens

Over the course of two years of a development project, we introduced team members to various agile practices. We observed which were adopted and which were rejected by team members and looked at how individual personality factors correlated with the kinds of responses to the practices.

By "agile practices" we mean the Principles behind the Agile Manifesto.

People in our project ended up lumped into one of the following four areas:

Adopted: Picked up the practice and used it with reasonable correctness.
Adopted but Distorted: Picked up on the term and the form but missed the intent and did something not agile.
Actively Rejected: Did not adopt the practice and argued against its use.
Passively Rejected.: Kept doing things differently form agile practices but never sought to justify or debate.

The project observed the reactions of individual team members to agile practices and related those reaction to personality types such as the categories suggested by the Myers-Briggs Type Index. For people who are introducing agile practices we think we might have some things to look for and ways to adapt to the varying responses usually seen among individuals in a team new to agile.

Test-Defective

True story: In a system that had recently been through a forced "big bang" rollout and had only been live for a couple of weeks, one of the daily financial processes failed one day due to some sort of rounding error. It later happened that one of the developers mentioned that he saw this error in test but hoped it was related to bad test data.

If wishes were fishes...

On Check Constraints and Whole Value

When a business object has setters for attributes that are interdependent, one way of ensuring that those attributes maintain the required relationship is to use check constraints on the setters. But there is a better way, using Whole Value.

An example first. Suppose the attributes are startDate and endDate, where the rule is that startDate must always be before or the same as endDate. A naive implementation, the kind that usually comes to mind for developers used to breaking things up into itty-bitty pices for primitives and database columns, is to have the two separate properties on the larger object. The setters for each attribute each check the new values against the constraint on the other value, to ensure the business object's state is always sane.

A better way to handle this is to code the properties in a way that eliminates the possibility of the business object ever being in an inconsistent state. An immutable Value Object can be the solution.

A Duration object can encapsulate the startDate and endDate into a single object with no setters, only a constructor that takes two arguments, for the start and end dates, and does the check in the constructor, throwing an exception if the required relationship is violated by the supplied values. The business object that formerly had both attributes instead has the single attribute with stters and getters for an immutable Duration.

Why Code Reviews Aren't Popular

Code reviews are almost universally recognized as the most effective way to improve the product. Why are they done so rarely? Short answer: the participants don't get sufficient immediate, concrete payback proportional to the cost and effort involved. Sure, the system, the team benefits, but the individuals involved calculate the equation as a net negative.

Harnessing the value of code reviews will take developing new practices that balance the cost to the developer with greater individual benefits.

Fit For Developing Software Released

The new book on Fit, titled, appropriately enough, Fit for Developing Software: Framework for Integrated Tests and written by Rick Mugridge with Ward Cunningham, has been released. It's available at Amazon, ISBN 0321269349

My software-developer's appreciation for Fit comes from three areas of importance to me:

Fit tests express business logic, as guided, or even written, by the business experts. They lay out the functionality as seen by the customers.
The test fixture code itself belongs to the developers. By that I mean, they are not QC, integration or system tests. Developer ownership is a big win because in the process of writing fixture to pass the tests, developers come to understand the system better.
Fit tests are larger in scope in than unit tests. While unit tests are critical in software development, they are not sufficient to ensure that the business functionality is implemented in ways that satisfy the users of the system.

This book has been called "two books in one", and I definitely agree. The first two parts are for customers and other non-programming team members. The latter parts are aimed at developers and have the technical topics. Ward said that as he and Rick were working on the book it started to get confusing, switching back and forth between the business-facing discussions and the technical discussions. Ward felt it best to cover the basics first, so they agreed to separate the book to speak to the two audiences one at a time. The resulting organization allows the book plenty of breathing room to address the needs of both audiences.

The "Questions & Answers" sections scattered throughout the book contain some of the most valuable gems. Here are a couple of examples related to ActionFixture:

From Chapter 10, p 73, "Some action rows have a keyword in the last cell. Is that optional?"
From Chapter 22, p 193, "Why does the actor have to be a subclass of fit.Fixture?

You'll have to buy the book to see the answers, though!

For my part, I am hoping to bring my own Objective-C implementation up to compliance with the 1.1 specification before the start of Agile 2005, where the community of Fit implementors is planning to congregate for a FIT Unification Summit on the last day of the conference.

Compensation Fallacy

If the going rate for the average developer with skill in the technology is N, it doesn't follow that offering 2/3N will get you a developer 2/3rds as good as average. Experience and anecdotal evidence suggests to me that you're not going to hire anyone who has any ability in the technology at a rate below some floor. If that floor is 3/4N, paying 2/3N will get you no skill at all.

From a practical standpoint, as a project manager you can't expect to complete on time with a product of lesser quality with a team of underpaid developers. You can simply expect the project to fail. If you happen to be the one well-compensated developer on a team of cheap programmers? You're not going to do just a larger share of the work, you're going to do all the work. If you're unlucky, you'll get to re-do the work of the other team members as well.