Norman Richards

Code generation isn't evil

One man's trash is another man's treasure. This weekend I've been working on an article on code generation for The ServerSide. (hopefully I'll get it wrapped up tonight) The goal of the article is to make the case that code generation isn't evil. To the contrary it's a very legitimate, and often overlooked, development technique.

I'll save the arguments for the article, but I do want to leave one point out their for the code generation doubters. Don't think that because the examples of code generation you see are often band aids around inflexible or poorly designed systems that code generation is necessarily a sign of a poorly designed system.

Embracing good formatting

I've already chimed in on the relgious issue of braces, but these comments motivated me to describe my brace philosophy.

You should always write code that is the clearest to parse visually. I think newline braces make the code less readable when the preceding line is a single line statement. For example:

if (test)  {
   doSomething();
}

is more readable than:

if (test)
{
    doSomething();
}

The opening brace doesn't doesn't do anything but imbalance the structure of the code and distract the visual flow of the code.

On the other hand, consider a method declaration:

public void doSomething()
    throws SomeKindOfException
{
    // ...
}

The newline brace here DOES add value, marking the beginning of code section as separate from the complex declaration before it. Although I see it done, I don't see any way you could argue that either of the following is clearer:

public void doSomething()
    throws SomeKindOfException {
    //...
}

public void doSomething() throws SomeKindOfException {
    //...
}

The former is ugly. It's imbalanced and distracting no matter how you indent the the throws. The latter is too cluttered. There's too much information on the line, making it more difficult than it needs to be to parse.

I realize matters of style are a subjective matter, but I couldn't resist putting my personal preferences out there.

Averting the coming brace war

I too am worried about the coming brace war. Given that the new-liners can't accept the obvious flaws in their brace style, the only alternative to all out war is to alter the languages to eliminate braces or disallow the heretical usages.

Tcl was an interesting player in the move to eliminate incorrect bracing. Tcl was line oriented, so braces had to be placed on the same line to cause the Tcl interpreter to parse correctly.

    proc test {} {
        for {set i 0} {$i<10} {incr i} {
            puts $i
        }
    }

This was nice in that enforced the one true brace positioning, but those of the the new-line cult were obviously disenfranchised. Python introduced another brace solution, eliminatings braces. In python, whitespace dictates nesting.

    def test():
        for i in range(0,10):
            print i

Eliminating braces is a fair compromise, but the unpleasantness of making whitespace this significant really makes the entire language nothing more than a curious programming diversion.

The final brace killing solution is to use non-symbolic tokens to indicate the end of blocks. This is the solution taken by ruby.

    def test() 
        for i in 0..9
            puts i
        end
    end

Although the keywords are a bit bulkier than a simple braces, they aren't excessively cumbersome. A key to the simplicity here is the single end marker as opposed to older scripting "solutions" like fi, od and esac. Since there is no additional block open marker, it's very difficult for even the most persisitent new-line cult member to place incorrectly.

Of the three solutions, ruby seems to be the best and most readable solution. Hopefully we will reach a more ruby-like future some day and avoid the bloody brace war. Ruby: our last, best hope for peace.

SQL is horrible

Jack Herrington writes: "I'm still appalled at how engineers with five years of experience are telling me that SQL is horrible and should be hidden or ideally replaced."

I've got 10 years of experience programming, and I'll say it. SQL is horrible. Actually, it's SQL as much as it is relational databases. Relational database do have their strong points, and if you need a solid transactional datastore you don't have that many options. But, I think relational databases really should be modernized a bit. It's really quite sad that we accept such horribly backwards technology in modern systems.

I think it stems from the fact that I started out my career developing LDAP servers. (X.500 at first, and later LDAP) No, LDAP is NOT a replacement for relational databases. But being introduced to LDAP before having any serious work experience with relational databases opened my eyes to just how bad the state of relational databases is. So, what's wrong?

No standard query language. I do wish the "S" in SQL stood for "standard", but it doesn't. There are SQL standards, but you can't just take queries against an Oracle database and expect them to work on MSSQL. There is a certain base level of standardization, but when you write SQL you have to be aware of what type of server you are querying. That's bad.

No standard network protocol. In LDAP, any LDAP client can hit any LDAP server. Compatability at the protocol level. What a concept! Think about it. Why should we need database drivers? We shouldn't. After all these years, we still don't have a standard protocol for talking to databases and getting results back. Of course you need the standard query language to make use of a standard network protocol.

No standard way to create or query schema. In an LDAP server, there is a standard representation of the schema and standard ways to query, add or remove schema. While table creation and update has some base level of consistency between servers, it's a far cry from being standardized.

The conclusion: after all these years of usage, relational databases have completely failed to provide a reasonable level of standardization or interoperability. What is worse is that most programmers I meet have never worked with better technologies and don't seem to realize how bad off the situation is. They complain about maintaining SQL queries for each server and bang their head making sure they have the right drivers and configuration files in place to work with their databases. Yet, despite all of this, they don't think to yell and scream and demand something better.

Despite all of this, relational databases do work. There's really no accepted, viable replacement, so there's really no incentive for relational vendors to unite and provide a modern, transparent, interoperable database solution. Unless database users demand it, we've got many more years of bloated, legacy, proprietary relational to look forward to. Uggghhh...

Friends don't let friends write singletons

The question of singleton or static class reminds me that it's time for another rant against the evil that is the singleton anti-pattern. I don't have a problem with the points made, instead I want to again ask why one would ever use a singleton.

Well, because you want to make sure only one instance of an object exists in the system, silly. But why? Why should anyone ever care to enforce a rule that only one instance can exist in the system?

I've yet to see a compelling example of a non-system level case where a singleton was actually required. Normally the real need is simply for cached instance that is easily locatable. The application doesn't actually REQUIRE that only one instance be created. Instead, it simply only wants one instance and using the singleton pattern provides an easy way to do the cached lookup. Most of the time, it doesn't matter (performance and memory issues aside) if multiple instances of the object existed. It's just that the static getInstance() is so easy. And hey, look it's a "Design Pattern", so it must be right.

Of course, the singleton is nightmare to to test. The truth is that most singleton objects depend on context information. (and you have my pity if you have to interact with a singleton configuration context) That context information might be set in stone for a single run of the application. But in testing, you want to have multiple contexts. Good luck trying to get your singletons to do what you want. But, my goal isn't to identify the singleton pain points. (besides, you've probably already felt them yourself)

Instead, I'd like to offer some advice for working without singletons. First, keep in mind what your goals are. If you need a cached instance, then simply provide a cached instance. Don't restrict the usage of your class in ways that aren't absolutely necessary.

Decouple object creation policies from your class. If you have a need to provide for controlled instantion of a class, don't put the logic on the class in a static method. Put that logic in some other place, (think factory or builder) allowing your application to choose/extend/override the creation policy as needed. Let the object worry about providing it's functionality and let some other object worry about managing instances of objects. Mixing the two causes pain.

Avoid hardcoded lookup strategies in your code. Instead of seeing singletons in your design, see managed components. When you see managed components, think about inversion of control. I've tried to avoid jumping on the IoC bandwagon, but the solution is extremely elegant. Instead of having your components do hardcoded getInstance() lookups, let a manager object tell you what the object is. You can still have one shared instance for all your components if you want. But you can do it without the restrictions that the singleton brings.

Avoiding singletons isn't always easy. Singleton's are great replacements for global variables and they keep you from having to create and manage a context for your application. It's easy to choose present conveniece at the expense of future pain, especially when you are following a well known design pattern. After all, if it's in GoF, it must always be a good thing, right? Just think through your goals. There may be times when a singleton really is he best choice, but in my experience it's usually the wrong solution.

Use cases are not requirements

Rick Lutowski gave the technotizer at this months AustinJUG and talked a bit about the "Freedom" Service-Oriented Methodology. I'll talk about Freedom at some other point, because, frankly, I'm not exactly sure I understand it. Nonetheless, Rick said one thing that caught my attention. Use cases are not requirements.

Rick compared designing an application to designing the dashboard of a car. Use cases are to the application design what a drivers ed manual is dashboard design. They both explain how the user will use a system but you can't design software around use cases any more than you can design a dashboard around a drivers ed manual.

That was a powerful analogy to me. Use cases can help you understand a system and can help you understand what the requirements for the system are, but they aren't in any way, shape or form a substitute for real requirements. We only got the 20 minute version of the talk, so I can't really do justice to what Rick thinks real requirements should be. Nonetheless, I do think that the methodology that he is promoting is worth looking into.

eXtremely disappointed in scrum

I thought scrum was supposed an agile process, but after being a week in the scrum, I want out. I really am trying to keep an open mind, but I seem to be spending much more time than I used to worrying about process. We have daily meetings in the morning where we all have to estimate our hour and tasks and basically give a status update. This takes 15-30 minutes of time that I could be using to actually do my work.

What is worse is that to have anything interesting to say that early in the morning, I need to get in half an hour before that, look over the sprint backlog at my tasks and try to spend a lot of time thinking about how much time I have left on the task. I estimate that scrum costs me 45 minutes to an hour of development time a day that I could be using to actually do something productive.

I find myself being so burdened by the process rather depressing and I am having a hard time being motivated to write good code. Scrum definitely isn't having a positive effect here. But, what would make it better?

Kill the daily meetings. Daily meetings are a burden. Ideally, a good process should have 0 scheduled meetings and 0 process related meetings. Occassional on the spot meetings to discuss a particular issue or brainstorm solutions to a problem are cool. I could live with a weekly team meeting if we really had to, but daily scheduled meetings are too heavy.

Don't estimate in terms of hours. I mentioned before that I was skeptical about the need to break tasks down to N hour chunks. Even my initial skepticism turned out to be too mild. I've been watching everyone's time estimates. I've discovered that not only is it nearly impossible for me to accurately estimate time, nobody else can either.

Extreme programmers say that estimates become more accurate with time. Perhaps that's true when you are using more abstract time measures. If I can handle 5 "units" of work in a week, everything sort of works out. Maybe one task took longer because I was tired and another was faster because it was a sunny day and I was happy. I don't really get bogged down in the details. I estimate wrong it doesn't feel "wrong".

But 4 hours is 4 hours. If I saw 4 hours and it takes 8 hours, I was "wrong". If I only shave 2 hours off a task in an 8 hour day, I was "wrong". You can say it doesn't matter. It's just an estimate. It's supposed to change. Maybe so, but I was still wrong, and I don't like to be wrong. Being wrong makes me unhappy, and when I am unhappy I don't code well.

I've only been doing this for a week. I'm sure it will get better. But, I'm honestly not optimistic about it.

First impressions of scrum

I mentioned a few days ago that we've adopted scrum as our development process. Until this week I didn't really know much about it. (and I still don't) Scrum shares a lot with other agile methodologies like extreme programming. There is a focus on quick 30 day iterations (called sprints) which are bigger in focus than XP iterations but not really by much. The goal is to always deliver a working product with features lists (the backlog) based on customer input.

Scrum doesn't dictate controversial practices like pair programming. Instead, the particular practices seem to be up to the group (the scrum team) to work out in the context of their own organization. So, you could employ XP techniques inside of scrum, if you want.

I think it's an interesting approach. I'm not looking forward to the daily 15 minute status meetings. But I'm pretty sure we won't keep with that practice long. Engineering is very small and communicates well. The goal of the meetings is to find out what has been done and what is in people's way. But we communicate well that this meeting won't really add any value.

It looks like scrum has task estimates tracked in terms of hours. I'm skeptical of this. I liked the XP practice of measuring tasks in terms of some abstract unit. For me a 4 hour task might take 2 hours one day and 6 hours the next, depending on how I feel on any given day. I'd prefer just call it "1 unit" and know that my speed on a unit is variable but that it all averages out. If we have to talk in terms of clock time, I'm afraid that it will be difficult for me to really get good estimates out. In other words, I believe that the time it takes me to do a task is highly variable and only meaningful in aggregate terms. I'll try and keep my mind open though.

We went over the initial product backlog and will start our first sprint soon. I'm sure it will be an interesting journey.

Scrumdiddlyumptious

We are starting a new round of development at work tomorrow and it looks like we are going agile. (hopefully that's not like going postal) My only real exposure to this style of development is through the Addison-Wesley eXtreme series.

But, the lucky methodology isn't extreme programming, it's scrum. Besides having seen the scrum book at a local bookstore, I really don't have any idea what to expect. I was tempted to go read the book this weekend or at least do some investigation on the web, but I think I'll just try and hit it fresh with no preconceived notions of what the process is/isn't. (or should/shouldn't be)

Hopefully the change will be a positive one. The mere fact that we are making it tells me that the company is serious about trying to improve engineering and make things work better. I *think* that's a good sign...

topcoder kata

I've been watching Dave's code kata's with a good bit of interest. I taught myself programming (20 years ago on a commodore vic 20) by thinking up small little programming challenges and trying to solve them. Of course, it took a while before I could really do interesting. In middle school, I finally mastered the breakout kata (bouncing a ball around the screen and knocking out blocks) and the calculating pi kata. (using '4 - 4/3 + 4/5 - 4/7 + ...') Part of the fun of the last one was computing the fractions to arbitrary precision and then watching the program churn, gradually getting more and more digits in place.

In middle school and high school I competed in programming contests. We had 4 or 5 contests during the school year (the most important being the TCEA area and state contests, which appear to still be going strong. I'd sit in the computer lab working through each problem again and again until writing them was second nature to me.

Nobody seemed to understand why doing these same programs over and over again amused me, but I guess it's the same reason that my son can watch the same Yu-Gi-Oh episode over and over and not get bored. If I knew I was just training myself with code kata's, I probably wouldn't have enjoyed it nearly as much.

For the last year or two, my training of choice has been topcoder. If you have never tried topcoder, you should check it out. They host regular programming contests where you face off against other coders to solve programming problems. The results of the competition factor into your rating and also qualify you for contests with big cash prizes. (they used to offer prizes for even the smaller competitions, but sadly that stopped some time ago)

I've been so busy that I haven't competed for quite some time, but I'm still quite proud of my topcoder rating. If you are curious what kind of problems you see in topcoder competitions, I have a list of problems and solutions from some of the earlier contests. The difficulty level of the problems isn't marked, so you'll have to log into the arena applet to see the problems in context. But that's something I highly recommend doing.

Even if you aren't brave enough to put your ego on the line in a rated competition, working through the problems is really fun. No matter how good of a coder you THINK you are, you'll definitely find kata to challenge you at topcoder.