Eitan Suez's Blog

Programming Archives

MVC without leaks implies generic VC

How many times have we heard or preached (or both) the important lesson of not having our business logic "leak" into the client tier. Each time we hear it, we nod our heads and say "how true," and get serious for a moment.

The idea of logic leaks applies to other aspects of development, not just the client tier. For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me. Say for example that we define a business object, maybe a Customer. Furthermore, let's say we define a number of fields on this object: name, date of birth, etc.. The minute we put down in our text editor the lines:

<caption>Name:</caption>
<input type="text" name="name" />

..is the minute we've crossed the line; we have violated the DRY principle. We have just leaked business logic into our view. From now on, if we rename the field, we must do it in two places: in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields. Model changes are going to occur. They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger. Yet business change is inevitable. People talk about the high cost of building software. It's no wonder the cost is high if we have to manually make each change twice. Not only is it more work but also error-prone. The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:

If we're going to have a model-view-controller system without business logic leaking into the view, then we must construct generic views and controllers.

What does that mean? Take for example, the CRUD scaffold generators in Rails. The code duplication is still there but at least the duplication is automated. Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:

GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

"Grazie Signore" Moments..

One movie that made a strong impression on me was the classic "Amadeus." Salieri, one of the main characters and a contemporary of Mozart, is often depicted (like most of us mere mortals are) as someone who can compose music but is nowhere near as quick or talented as Mozart.

There's a specific scene where Salieri is composing music, one small step at a time (one note at a time!) and derives great satisfaction from the task. He then pauses to thank the lord (in his native [Italian] tongue) for having given him his musical talents and the opportunity to practice music composition: "Grazie Signore."

I can't tell you how many times I find myself in such a situation. Every day we code. The going [for me] can be slow but things do move forward and progress. Every so often I pause and admire a new feature I've added to a system I'm working on and get a terrific feeling of satisfaction, just like Salieri did in Amadeus.

Dave Thomas (the Pragmatic Programmer) is right: many trades have much in common: composing music and writing software for example. Dave often talks about 'the art in programming' and I agree with him wholeheartedly: there's art in programming and there's also a certain dose of engineering in art.

on languages and apis

i've recently been thinking about two related topics:
- on programming languages vs programming apis
- on the relationship between human languages and programming languages

the sources of these thoughts have been coming from two separate corners:

1. discussions we sometimes have at nfjs symposia on the ever-popular question "which language should i program in" or "which language is best;"

2. my incidental knowledge of french, hebrew, and english and their bearing on my thoughts about software designs

everyone has an opinion on the first issue of 'which language is best.' my personal opinion is that different languages suit different people. that is, my answer is that there is no such thing as one language fits all people (or purposes, or both). i believe our liking of a programming language is somewhat related to our character and our intellectual capabilities. most _really_ smart people i know love languages like LISP, and in general languages that are extremely terse. my explanation (to myself) for this is that the terseness is not a problem for really smart people. once your learn a language it becomes natural, second nature. then what really matters is how terse it is. so a language like perl is very terse and you have really smart people who absolutely love perl and some not so smart people (like me) like it less.

but what does smart mean anyway? my wife tells me i'm smart and that makes me happy. but i know that i'm not the kind of person who will solve a difficult problem in real-time. i also know that in real-time conversations i'm a bore. where i do ok is when i take my own time to think about something. i'll resurface and by then i will have thought about the problem, brooded over it, understood it a little better, and so my proposed solution is usually a little better than what others propose. at least that seems to be my own subjective analysis of myself. so in the last paragraph, by "smart" i mean people who can think quickly in real-time. in that respect i'm somewhat of a disapointment. :-)

i'm not a programming language expert and i believe that i know fewer programming languages compared to many other software developers. i've coded a little in c (way too long ago). i know javascript and perl and java. i did some php years ago. i probably know a couple of other languages and forgot that i did (i forget things a lot and i'm sure it's not going to get better with age :-) ). i also read dave thomas' excellent book on ruby though i have little practice with it. and very recently i read through a book on objective c.

i'm not so interested in the question "which language is best" anyway. that was just a trigger that led me to thinking about programming languages vs programming apis.

the reason i don't like the discussion of "which programming language is best" is because to me they look all the same. i mean, the differences between languages are cosmetic and insignificant. i believe all the action is elsewhere: in the api. when i look at javascript vs perl or vs java i see different syntax for a for-loop, for iteration, using one kind of brace as opposed to another. but they all basically have the same set of constructs: conditions, looping, perhaps threading, scope, closures, etc.. some are terse. some require less typing. and that's good. some are more strongly typed. and many have oo concepts built-in, which is good. some day maybe aop will also be a concept that's built-in to the language. but then if this turns out to be useful or popular then probably most languages will follow suit and adopt these notions. and that's exactly why we have c++ and objective c today.

to me, one language can be replaced with another. the essence is elsewhere: in the api. here's an example: pdflib (see http://www.pdflib.org/). pdf lib is a library for working with pdf documents. here are a few facts about pdflib:

1. The PDFlib core is written in the ANSI C language.

2. PDFlib supports language bindings for all common programming environments:
http://pdflib.org/products/pdflib/languages.html

that is, pdflib clients can be written in:
c, php, java, .NET (.WHAT?), Perl, Python, Cobol, and more!

the striking thing is that the way you interface to the api in perl compared to java is essentially the same. pdflib is indifferent to the language used by its clients.

i think the same is true for other types of apis. take interfacing to a database as an example. all languages have a jdbc-like api for interfacing to a db. you submit sql queries and get back resultsets and you can iterate over the resultset and extract field values, etc.. if you do this in perl or in java the code is pretty much the same (albeit the perl version is more terse or obfuscated depending on how you look at it). so what defines the way the program is going to be written is the database api and not as much the language.

so my point is this: the api is a language. it's a domain-specific language. how you design an api has direct impact on whether it feels natural (e.g. jdom) or not (e.g. w3c dom). and to some extent, that seems to be independent of [a] the programming "language" you use to write the api or [b] the programming language you use to write the client.

so it turns out that we're developing languages every day in our programming work but we may not really be conscious of this fact (maybe we should call ourselves computer linguists instead of computer programmers).

let me turn now to the other thoughts in my head: the thoughts about languages. i'm most fluent today in english. this is no surprise since i've been living in the usa for the last 20+ years. but i'm in a somewhat unique position. i look at code i've written a number of years ago and think to myself: "did i write this code? it's terrible! it shouldn't be designed this way." i take this as a sign that i've become a better software designer (or maybe just more pompous) in the last few years. finding the right design is much more natural to me today than it was, say, 5-6 years ago. the principal design tools i believe one needs are: [1] refactoring + [2] design catalogs. my current understanding of software design is shedding light into the design of human languages. i look at english. english is _the_ international common language. it's spoken almost everywhere. i believe english's design is not so ideal, not so great. other languages have better designs. i believe that java is like english is, but for programming languages. i don't see a rush for english speakers to find another language to express themselves in because of "inadequacies of expression" that exist in the english language (inadequacies that may not exist in other languages). i look at hebrew specifically. what really strikes me about hebrew is that it looks like a language that was designed, not one that emerged; almost a "cleanroom" design. but the same goes for evolution: this world looks like it was designed (in the hitchhiker's guide you actually get to meet the designer) although it really evolved. so maybe the fact that hebrew looks like a better-designed language is that it's older than english and has had more time to evolve (this reasoning is flawed though because hebrew was a dead language for 2,000 years and was revived only in the last century; the elements of the hebrew language i describe below were present in the language as far back as 1200 BC during the exodus).

if i could describe to you the design of the hebrew language. it's beautiful. there is a notion of a "root" which most of the time is composed of three consonents. i don't even know how to describe it. you can say that almost the entire vocabulary of the hebrew language is a set of roots. then from that root are various derivatives. there is a consistent way to "transform" a root for conjugation, to create a verb form, noun form, to imply possession, and much more. like everything else, an illustration is more revealing than a description. take for example the root "YLD" which means "child" or is the concept that is related to the word "child." yes, a Y is a consonent in the hebrew alphabet. that's because a consonent in hebrew is defined as "that thing that goes in between two vowels." take for example the word "maya" -- the "y" goes in between two vowels. by the way, since the latin alphabet is a derivative of the hebrew alphabet (or maybe they have a common ancestor), the Y ("yud") corresponds to the letter "J" in latin, which i believe in german is pronounced "Y" but in english for some reason has morphed into the current "Jay" sound. so jonathan for example was never called jonathan, but yonatan. but i digress. so there is this model in hebrew that all writing is basically an alternating pattern of consonents and vowels. as in "pomade" - 3x(consonent followed by vowel). to handle the exceptional case of two consonents back to back, there is the notion of a null vowel: it's called the "shva." and there is a null consonent too: that's the letter "aleph" (which somehow morphed into the letter "a" in latin). it turns out that hebrew doesn't even have vowels: it's all consonents. i mean they're there but they've become implicit in the language. there are no letters for vowels. people have discovered they can read and write faster if they just omitted the vowels altogether. but again i digress. ok, so back to YLD. "yeled" means boy. "yalda" means girl. any word that is somewhat related to the concept of childhood is derived from that root. take birthday: that's two words: birth and day. the "birth" in birthday is "holedet." ok, the y has disappeared but take my word for it: the 'l' and 'd' come from the root of yld. "toldot" means "the telling of the generations of" or "recounting the genealogy of" which occurs frequently in the bible (as in "these are the generations of jacob (israel)." "toldot" again derives from yld. "yaldut" means childhood. "lehivaled" means "to be born." "yelid" means "native." so in english we have ten words that have no phonetic relationship to one another: boy, girl, birth, genealogy, child, etc.. (only a relationship in meaning). in hebrew they're all related both in meaning and phonetically. i realize that latin and greek have that concept as well. "gene" in genealogy is essentially a root. and there are many words in english that derive from the "gene" root such as "generation", "genes", "gender", etc.. that's why people recommend learning latin and greek: because so many words in the english language derive from lating and greek roots.

now that i think of it, i think hebrew could use a javadoc tool that will tell you all words that derive from a specified root. kind of like an "descendants" cross-reference in the java almanac (or ashkelon). maybe there's already one out there, who knows.

what's even more important is that the rules for derivation of words from their root does not change from one root to another. so if you learn the rules once, you now can generate almost the entire hebrew language from its set of roots. it's like the root being a machine and the user interface for that machine being the set of rules you apply to generate sentences. you learn how to operate one machine, and now you know them all. that reminds me of naked objects: naked objects does that for user interfaces: it generates a _standard_ ui for any set of types you desire. if you know how to work with one type of object, you've just learned the user interface for all of them. (that's why i believe that hebrew is an easy language to learn: it's less redundant: it's well refactored.) that's powerful stuff. the type can be parameterized. just like in hebrew the root can be parameterized. that's what the java reflection api gives us: programming model constructs are elevated to types, which can, among other things, be used as parameters. the type can be treated in a standard way. that's also the reason for the command pattern: elevating a method to a type.

so back to java. java is a fairly new language. i think we're slowly witnessing the evolution of a programming language. i think java has been evolving remarkably well. we wanted assertions, we got them. we wanted complementary apis that were not in j2se, we got them from apache and sourceforge and all kinds of places. we wanted a simpler way of doing iteration: we got it in java 5. we wanted parameterized types / generics: we got them. we also got annotations. we'll see which will survive and which will not. they might remain in the dna.. i mean in j2se. but they might not be used as much (e.g.: the preferences api). we are also experimenting with other languages that are byte-code compatible with java, groovy being an example.

i know there are a few things in j2se that haven't exactly evolved very much. the issue of ownership can also sometimes get in the way of evolution. maybe evolution deals with that by being slow. people die and then no one is left to fight for ownership .. of ideas, at least.

well, if you made it this far the only thing i can say is: thanks!

Thoughts on Gosling's "Sharpen the Axe: the Dark Side"

I am very grateful to James Gosling for posting his blog entry of January 4, 2005: "Sharpen the Axe: the Dark Side." (http://weblogs.java.net/jag/)

The reason is that I believe this very topic to be of utmost importance to software developers (and their employers!). The second reason is that I don't believe this issue is discussed openly enough. So, first of all, thank you Dr. Gosling for the post.

Software development is a relatively young industry. We're still trying to figure out the right recipe for a successful software project.

I believe that many developers go through a nerve-racking decision making process at the start of every new project. The success of the project hangs in the balance.

An evaluation process goes on in developers' minds: how much work is this project going to require? What resources (people, budget, time) are at my disposal?

We all know time is a very precious resource on software projects. We've also learned that adding more developers (beyond n) to a project does not necessarily imply increases in productivity.

My guess is that more often than not the situation is one where the amount of effort is far greater than the available resources to complete it. That is, to use the analogy of sharpening the Axe:

When a developer is asked to cut down an entire forest by himself, how much good will sharpening the Axe do?

Sure, there's a tradeoff: if we spend the time to sharpen the axe, we are taking time away from cutting down trees. And the promise is that we will make up the time by cutting much faster with a sharp axe.

However, in this case, neither solution will work! There's no way we'll cut down the entire forest; and the project will fail. All the developers know it. Management and the marketing department is in the dark. They have no clue.

What we need to do is invent a chainsaw, and quickly! So in this extreme (yet possibly prevalent!) case, it doesn't matter what decision we make. Or does it?

I believe it does. Here are my reasons: the problems are not going to go away. The need for the chainsaw will always be there. So we might as well start working on it.

The problem is that there is no reason on earth why the company you work for (maybe an insurance company, a hospital, or an accounting firm) should stray so far from its core business to support the development of a supposed revolution in software. In these environments, developers are faced with shorter-term pressures.

What about companies that are in the business of building software? What about IBM, Microsoft, Borland, BEA, Sun? You've got me there; I have no clue. I've never worked for large software companies. I can only offer hypotheses: maybe developers at such companies are not directly exposed to customer needs, the way IT departments or consulting firms are? So this problem may not be in their radar. Surely it's in IBM's radar?

a. they're a huge company with lots of resources
b. they not only develop software but they have a huge consulting services arm

Conspiracy theorists might hypothesize that if they did come up with a solution, then from a business perspective the solution would no longer necessitate the huge charges of software consulting services. The problems would go away and so would entire software consulting industries. One must admit there is some truth to this rationale.

So who's working on a chainsaw these days? And how does open-source play into this? I want to hear your opinions.

Code Rot: Mental Exercise to Better Understand Code Rot

My brain has been slowly digesting the concept of code rot, triggered by skimming random articles or blogs that have recently mentioned the term. Code Rot. It's a good word. We've all experienced it. But it's another thing to understand it. What is code rot??

The process of evolving and improving upon code is a dynamic one. Some say it has a life of its own. But its thread is fragile indeed. So many software projects end up being abandoned, scrapped, killed. It happens slowly and sometimes it takes a while to realize what's happening. Even though a good term, the code itself doesn't really rot. Do you recall the sales pitch for moving from the old "analog" world into the new "digital" world? The claim was that in a digital world, the signal never fades. Its amplitude is encoded into bits and thus its value can be restored with precision. So the code doesn't really rot. It's the same old bits.

It occurred to me that software is similar in ways to the little i recall from my study of viruses in 10th grade biology class. The real issue here is that the tango of writing code is danced with two partners: the programmer being one of them, and the code being the other. Our minds are frail, and they tend to forget. Just as telecommunications signals fade and need to be amplified at certain intervals, so does our memory.

As we write code, we say that the code starts to take on a life of its own. What do we mean by that? The code we write may satisfy our original requirements. But that does not mean that it's so tight that it can only satisfy those requirements. There's always a little extra room, certain combinations of paths that will produce a bug or unintended behavior. Furthermore, the knowledge of the system begins to split between the code and the programmer. There's what's written down in the code. And then, there's what the programmer discovered while writing the code, or while refactoring the code, and that he (or she) didn't write down. Certain protocols perhaps, certain frailties in the code, something to revisit at a later time, after the deadline has passed. This is the substance of code rot. This knowledge is somewhat essential. It's kept in short term memory. It needs to be refreshed. If it's not, then treading through the code becomes more difficult. A new programmer has to deduce and learn this unwritten knowledge on his own. So documentation helps fight code rot. Take the time to write documentation. Some things are easily inferred from the code. Others are not. Put that information in the code itself so when the code changes, this information gets revised accordingly.

I just got an email from a friend saying:

I'd also like to thank you for leaving a help file on your projects, namely the code at . I've run across legacy code from another dev, and I'm having trouble finding where to start.

The code is like the DNA of a virus. It sleeps, and waits a human being to come and discover and reactivate it. A fluent understanding of the code requires one to constantly review it, work it, refactor it, practice it. It's not just an exercise in learning, but just as much an exercise in refreshing our memory cells and re-acquainting ourselves with software that oftentimes we ourselves had written, but have forgotten. If not tended regularly, a certain fear starts to set in that prevents us from getting more intimate with the code.

One of the reasons I'm a big Java proponent is that the fight against code rot is already a difficult and constant one. Furthermore, one of the activities necessary to fight code rot is (as i've already stated) the constant review and improvement of existing code. The diligent practice known as refactoring. Even if you end up changing the code and then changing it back to its original state, the exercise would not have been in vain: you are now re-acquainted with it. Other languages [shall we say] lend themselves more easily to obfuscation abuse. If code is difficult to read, then this precious task of re-learning one's (or someone else's) code becomes much more difficult. The weight you're carrying now going up that hill has doubled.

One of the ideas that my brain has subliminally decided to share with me, is that Code Rot is very much related to the concept of what people call "writing maintainable code." I believe "writing maintainable code" mostly means "writing code that makes the fight against code rot easier."

Let's expand on the virus analogy. A virus is not categorized as a life form. Most of the time it's not actually alive. I guess it's dormant: a bunch of code just laying there doing nothing [my learning of biology started and ended in 10th grade so please go easy on me here]. Some event triggers it into activation (maybe it bumps into a cell), at which time its "life" resumes and its code suddenly starts executing again, hijacking some poor cell nucleus and running the cell's machinery against the virus's DNA instead of the cell's. The other side of the analogy (hacking) may go something like this: we discover some piece of code (maybe we join an open source project, or maybe we pick up an abandoned open source project on sourceforge) and start familiarizing ourselves with it. The code-programmer duo starts becoming alive again and the software starts to evolve again, to improve. This is the opposite of code rot. Project success is analogous to the virus winning and overtaking its host. First a few copies are downloaded, news of the code grows, more downloads follow. Before you know it, this code is replicating itself all over the world. The main difference here is that our software virus is a good one. Hibernate is such an example. Eclipse is another. JBoss is yet a third. Code rot is on the other side of that curve. When the project velocity goes down, when bugs are not being addressed at the rate that your customers approve of. It's a hard fight.

What can we take away from this mental exercise? One is that the ingredients of a successful software project are code and programmers. That people and computers exist today in some sort of symbiotic relationship. That "Code is like Tang: Just add programmers and bang! You've got a success story?" (is that what the .com boom was all about??) :-)

Ok, let's get a little more serious: awareness of the notion of code rot is important. Code is dead without good programmers to wield it. Programmers that care enough about the code to tend to it daily. Management should not underestimate the cost of human resource turnover in the software industry. One of my previous jobs was at such a place, where little importance was lent to the knowledge original programmers had in the systems they developed. XP is a good recipe to fight code rot. Test driven development: Amen! Pair programming: Amen! Refactoring: and let us all say.. Amen!

This work is licensed under a Creative Commons License.