Sun, 29 Oct 2006

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.

permanent link

Thu, 22 Jun 2006

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.

permanent link

Thu, 16 Feb 2006

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

permanent link

Fri, 10 Feb 2006

Personality Styles in Adopting Agile

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.

permanent link