T.H.O. Part ][

Malcolm Sparks had this to say:

I think that we a few more people with that T.H.O. attitude to prevent open-source libraries from stagnating. It is a good thing that the incumbent 'standard' library gets regularly challenged by contenders. Without continual selection and reselection, evolution dies and progress stops.

The argument that we only need just one of anything is really unhealthy. It leads to mediocrity: I present J2EE as a perfect example. One of everything you could possibly want, put it all together and what do you have? Crap.

I think you might have misunderstood me or I didn't make myself clear. My point is if you have want to do something better, then do it in the open source community. Go at it and have all the fun you want. I think the open source community needs and thrives on forward thinkers. At least there, you will have feedback, tons of people testing, and a chance for your idea to mature. But, I believe doing that on a corporate project is risky and prone to maintenance nightmares. Why? Because generally they have not gone under the same scrutiny an open source project has.

When I learn some new technique or have some crazy idea, I write it in my spare time. If I like it, I'll publish it on my site. Now, there's a lot of things that I did (like LazyCollections) that I would never do on a real project. Why? Well, LazyCollections was a chance for me to play around and try things out. I thought the experiment might be a helpful learning exercise to other people. But, the code is generally hard to understand for most developers.

I have empathy for the people that will have to maintain my code. Generally, this means I don't code things that I can, but what can be easily tested and maintained. It's not dumbing down the code or the design. Simple designs don't need tricks. They just need thought and lots of it. Simple designs are not easy and generally not the first solutions you come to. They are hard work.

Good code tells you where it hurts

I've been meaning to write an entry on exception handling and how important it is to not throw away information. So, here it is. I'll start with one my pet peeves below:

try {
    ...hard stuff here...
} catch(Exception problem) {
  problem.printStackTrace();
}

OK, first off, I'm usually skeptical of catch all blocks at low levels. But, there can be good reasons for them, but the problem I have with code above is printing the stack to the standard out and continuing. At the very least, this is only good for when you are doing command line utilities and even then it's not good. Worse yet, this is the default from Eclipse! I've been bitten too many times where code went wrong and we couldn't find out why because the stack was written to the standard out and we couldn't see what it was. Or maddeningly the code continued and caused other problems further down. Fun to debug those problems it really is. My solution is if it's informational and you can continue log it, if not re-throw the exception. But, there's times when you catch a checked exception, but it's something that's serious enough to stop current processing. I've seen this:

try {
    ...something hard here...
} catch(Exception ex) {
  throws new RuntimeException("Something bad happened");
}

Thankfully, I haven't seen the above code so much since 1.4 added support for wrapped exceptions. But, I still see it. The problem with the above is the original exception is dropped. When debugging or trying to find a problem, the above code gives me no information of the original context. It's useless, but it did stop bad things from happening further down. But, it would be almost possible to find out what really went wrong.

Always catch the most specific exception and leave the catch all exception handlers to the top level code. It will save you headaches, I promise you.

My rule of thumb to exception handling is: if something goes wrong, what would I want to know? I see too much code where this is forgotten or it is written as if nothing will go wrong. In a perfect world, all code works beautifully and there is no need for exception handling, but we don't live in that world. As always think about helping the poor developer that has to come behind you.

T.H.O.

T.H.O. used to be an acronym that a friend of mine would use to describe code in which it was apparent that a developer put his ego before the good of the team. The code exhibits clever behavior when a simple approach would have sufficed. But, the developer had to show off that they knew a certain trick. Sometimes, it can be more sinister. A complete library written from scratch when there are open source equivalents better tested and designed. But, they just couldn't resist doing it themselves (also known as the "not invented here" syndrome). They think they can do better. But, normally, it is some poor maintainer that has to deal with their "better" solution after they are long gone to the next T.H.O. In this day and age, I can't see how anyone can justify writing a library from scratch if there is an open source equivalent. It boggles my mind. Of course, if you think you can do better, then do so on your own open source project and live with the code before causing a maintenance nightmare for years to come. Besides, you'll get valuable feedback and fix bugs from other developers. Value simplicity and doing the least to get the most.

"Get 'Er Done" Programming

OK, if you don't like my rants, stop reading now. I've been trying to write this entry for a while without sounding venomous, but I just can't do it. But, I'll start with what I call "Get 'Er Done" programming. Now, I'm sure you've seen the highly annoying "cable guy" comedian that utters this despicable phrase. But, it's what I hear when I see lazy code written until it works. It's maddening I tell you! Basically, writing code until you can get a simple example to work and stopping there is lazy. Failure to look at the big picture should be punishable. But, I see examples of it littered everywhere.

Alright, you might ask what does "look at the big picture" mean exactly? What I mean is do proper analysis. Think about your problem before you write any code. I'm not advocating huge up-front design here, just thinking before you burn up your keyboard. It might also entail asking a few questions about the problem to fellow team mates and the user. It all depends on what your coding and your understanding. Looking at the big picture also means in making your code to be able to have future extensions that you can't anticipate. You might think this is impossible, but it's not. If you make the objects small, each one has a single responsibility, have good intention revealing names, and make small methods, then you have made your code extensible.

The whole point of this blog post is don't be lazy and make life difficult for the person that has to come behind you. Think about what you're doing and make your code easy to read. Remember there is always someone coming behind you that has to learn what you did. Make it obvious and show that you cared by going beyond the simple example. Well, looking back this wasn't so bad was it? Sometimes rewriting and thinking about what you write works too.

I'll end with a piece of advice: always re-read your code once you have written it and it works. You would be amazed at what you catch (misspelled words, uncalled methods, unused variables, etc). Of course, with today's tool this is quite easy. In fact, Eclipse can flag most of these with a warning, but it's still a good habit to read your code before you check-in. Let's stop "Get 'Er Done" coding today. Besides, only idiots write code that way and I know you are not an idiot, right?

Omaha Dynamic Language Group

The air is warm, the sun is shining bright, and the monitors are glowing. Yes, it's time again for another stupendous Omaha Dynamic Language User's Group meeting! This month we are honored to have Ryan Stille speak on Cold Fusion! If you've ever been curious about this technology, then you need to see this presentation. You may never see the world the same again afterwards!

This month we are also honored to have Concentric sponsor us! They will be providing food, drinks, and much merriment. We are glad for their participation.

I will see you all there for the greatest user group ANYWHERE!

Topic	Cold Fusion
Speaker	Ryan Stille
Time	June 5, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Jargon

I just have to scream, "RIGHT ON!", on this post from Penelope Trunk: What the jargon you use reveals about you. I think this is true for us technologists as well. See my post below about Idea Killers. Stop using jargon and mantras! Think! Wait a minute? Isn't that a mantra?

Idea Killers

Recently, I've loathed hearing the phrases: "YAGNI" (You Ain't Gonna Need It) and "Is that the simplest possible thing?". My gut becomes knotted and disgusted. It makes me not want to be considered agile anymore. Why you ask? I always saw agile as positive forces in the software industry. I welcomed them with open arms because they were a shot of fresh air and made everyone think about how they did things. But, now the mantras are being used to be idea killers.

The mantras were meant to shake your thinking. How could you do this as simple as possible and still work. A nod to good engineering and design to shake the brain to think of another solution. Or ask questions like "Do you really need that huge framework?" But, lately, these mantras have been having the opposite effect. I've been in meetings where they were used to shoot down good ideas. And they work well. It's hard to argue against. You don't want to be the person that doesn't want the simplest solution right? But, when you are at the phase of generating ideas, these critical phrases kill the creative spirit. I say no more.

I say no more mantras. Let's think. Let's generate ten great ideas and then be judgmental of each one. At the idea phase, all ideas cost the same. Crying "It's not the simplest thing" too soon kills good design thoughts dead before they are allowed to grow. I think these phrases have become too common place. They are used to shut off thought and prove you are right. Besides, it's been a rare event when someone meant truly simple and not easiest. The two are confused frequently. Simplicity takes practice and thought. There's a reason why Einstein said it. It took several rewrites to get Smalltalk to its current state of simplicity.

Think about it. Refuse the use of mantras. And let ideas flourish.

Truth, Justice, And The American Way

There's one subtle feature of some languages that keeps causing me pain and in the wrong hands causes more harm than good. What is this feature? Let me show you some Javascript code:

if (transaction.amount) {
  transaction.markValid();
} else {
  transaction.markInvalid();
}

Nothing wrong here, from the looks of it the code is checking if the transaction has an amount defined and then marks the transaction valid or invalid. Simple right? But, what if an amount is defined and it is zero? You would think the transaction is marked valid right? WRONG! It will be marked invalid because anything that's zero, nil, or undefined in Javascript is considered false.

And that's my beef, why not treat booleans with their own type. Why treat any other value as equivalent? Subtle bugs like the one above are infuriating to me. The simple reason is that they can easily be avoided with a few extra characters.

if (transaction.amount == undefined) {
  transaction.markValid();
} else {
  transaction.markInvalid();
}

The moral of this story is to code exactly what you mean. Be specific. Don't rely on arcane language features to save a few key strokes. Java and Smalltalk do the right thing and make you use boolean types.

I Can't Stand Pretentiousness

There I said it. I don't care what it is. A programming language, methodology, religion, music, art, coffee, movies, or what have you it doesn't matter. It reeks to me and I'm sorry for anyone who uses it to make themselves feel superior. Somethings I don't understand being pretentious over like wine (angry grapes because they are bitter for being made into that) or scotch (yes, I would like some turpentine please). I've tried them, I didn't like them. But, if you do, then more to you. It's not a reason to think your are better. But, I digress. I'm always running into people that stick their noses up based on what I like. Nothing cuts off a conversation sooner for me than when someone says, "Why do you listen to that Y garbage?" or "How can you stand to program in language X?" I just walk away because you are not worth my breath. I think it blinds your thoughts and makes it impossible to reason. I would rather hear, "Why do you like X?" or "Give me the top greatest pleasures of Y". I like to ask those questions. I'm always amazed at the answers.

I guess it's my southern upbringing. I like simple things, but I also enjoy richer experiences as well. I just hate it when someone is not open to the joys of the simpler things. I listen to all kinds of music, food, or what have you. I will try anything once. And I research any language I can get my hands on. They each have their strengths and pluses.

Now, don't mistake pretentiousness with excitement. I love excitement and a healthy jubilation for your newest discovery. But, when it turns to thumbing your nose at something, then I think the coin has been flipped.

Oh well, I had to get that rant off my chest. I'll probably read it tomorrow and go "What the hell were you thinking?!" Or maybe I was just trying to say, "There's something positive about everything, find it", in a really negative way.

Live Refactoring May 15

I got talked into doing a "live" code refactoring at this month's Omaha Java User's Group with Sam Tesla. It will happen on May 15. Actually, you need to come because we don't know what code we will refactor yet except that it will be horrendous. You will see the ugly come elegant and simple! Sam and I did a similiar "live" refactoring for the local Software Process Improvement Group not too long ago. It went well and was a lot of fun. It's fun collaborating with Sam and our styles compliment each other very well. Of course, the code will be in Java and we'll be showing off what you can do with Eclipse. It's rare you get to see the journey to elegance and this will be an opportunity not to be missed! I hope to see everyone there.

DSLs: What's the big deal?

I've always wondered what the big deal with DSLs was. Now, i'm not saying they are bad quite the contrary.But, I believe a DSL is a healthy bi-product of a good object-oriented design. So, I was a little annoyed with all of the talk and the tricks. I kept thingking to myself, "But, if you did a good design, you would have this!"

But, I should really be kicking myself. I should be glad that good design is back in vogue. and you know what? I am. I'm not annoyed any long and I relish all of this new talk on DSLs. I even feel guilty. You see, DSLs have always been part of the Smalltalk farbic. It's natural to us because it's the way we have learned to code. I remember having the mantra "Code should read like a conversation" shoved down my throat until it became second nature. The cool thing is that there is a whole new generation finding out about this and doing it. Very cool.

I'm now promising myself to show non-Smalltalkers the other cool things that we have in our fabric and what we take to heart. The power of messages compels thee!

Groovy: Java 7?

Sometimes I wonder why they just don't make Groovy Java 7 (or even 8). I mean, c'mon! I think it makes a lot of sense. Closures and dynamic typing that is still understandable by most Java developers. I think it would be a step in the right direction. I know I enjoy programming in Groovy more than in Java.

Built-in Persistence/Transactions

We have long now been able to let the computer handle memory management in our programs via garbage collection. Why not let it also handle persistence and change management? I think these are things that should be built-in and it would be handled more easily by the virtual machine. There could be a low level API for hooking up different persistence strategies (relational, object, etc) and code would no longer have to be dirtied up with SQL or even worse HSQL. At the very least, change management of objects should be handled by the VM. How much easier would exception handling be if you could also rollback all the changes that had occurred and you could get back to the state you were in before the error? I think these should be the new primitives.

Gemstone is the realization of this on the server. It would be nice to make the code on the client as transparent as well. I know some might laugh at this idea, but I think it has merit. Just like garbage collection seemed strange at first, why not allow automatic persistent management as well?

Re: Make Debugging Tests Easy

Boris Popov left a comment on my post "Make Debugging Tests Easy":

Can you give a more specific example please? I don't see anything wrong with this, for instance,

| file |
file := self loadPaymentFile: self sample.
self assert: file validPayments size = 3.
self assert: file invalidPayments size = 1.

Well, I would probably change the file to a stream, but that's a different topic and discussion (I generally don't like to access outside resources in my test; they only cause problems later). Back to the conversation, the last two lines are what I don't like. The reason is that say another developer changes any of the code that gets called during the loadPaymentFile: and they run all tests. And let's say it's in common code and this test fails. Let's also say that we get back 2 valid payments and 2 invalid payments.

The developer is going to have no clue which one became invalid and what made it valid in the first place. You could put in comments explaining what the 3 valid payments and 1 invalid payment were to help. or you could break out and have several asserts for each of the cases. Otherwise, I have to revert code and rerun this test to see which payment is now incorrect. And then, put my code in and see where my code is incorrect. The above code makes the original intent hard to understand. Why were only 3 valid? Why was only 1 invalid and what made it invalid?

Really the above test is not incorrect per se, it's just not very thoughtful of the other developer's time. A couple of extra minutes of coding time would save the other developer a couple of hours. It's about coding and feeling sorry for the poor person that has to come behind you and figure out what you did. I try to always code with the maintainer in mind. Most times, the maintainer happens to be me and I'm always thankful I took the extra time to help myself.

Omaha Dynamic Language User Group

This month's meeting is brought to you by the letters G and B. Brent Adkisson is taking time out of his busy schedule to show us the power of Google's new GData API. It's a safe bet that you'll be astonished and will can't wait to find a use for GData for yourself. Brent has been telling me all about the exciting things he has been discovering with it. This is one meeting not to be missed.

Pizza, drinks, and a special prize (just like a box of Cracker Jack) will be provided for by this month's sponsor's Tek Systems.

Free food and stimulating conversation make for an exciting Tuesday night! See you all there.

Topic	GData
Speaker	Brent Adkisson
Time	May 1, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Make Debugging Tests Easy

One pattern I see over and over in tests is the assumption that the tests will always run to green. Now, you might think that's an odd statement right? I mean the whole point of tests is to make them run green, right? Well, in a way, yes. But, more importantly they are a communication device to help new developers understand your intentions. Too many times, I've seen assert statements that simply check a size of a collection. Sure, the tests pass, but what does that saw? Why that specific size for that collection? It's frustrating because when I see these things, it's obvious the developer never thought the code would break after the test was passing.

Think about it if I check that the size of a certain collection is 5. I can bet in 6 months the reason will be fuzzy. Of course, you could name the 5 as a constant and that would certainly make it more readable. It is a step in the right direction even. But, why 5? If I change code and I get back 7, what does that mean? A constant might help, but it might not. Be specific in what you check. Don't get lazy in naming or being general. Spell it out. It might take more effort now, but it will pay huge dividends when the test breaks. More than likely, when a test breaks after it is running that it is unexpected.

Feel sorry for the poor developer that has to change your code and then figure out your tests. Take as much care in your test code as your main code. You will be thankful later. Your tests will spell out exactly what's wrong, be easy to debug, and most importantly easy to be fixed again.

Tiny Types, Abstract Data Types, And Little Objects

Darren Hobbs wrote about one of my favorite topics: Tiny Types. I call them abstract data type, but I like Darren's name better. The idea is the same. I think it's just good design. I once thought that tiny objects were too much as well. But, I now think tiny objects is the only way to go.

Tiny objects make unit testing easier, aid in reuse, stop duplication dead, provide for better messages when things do break, puts functionality closer to where it is used, and I could go on all night. The amazing thing is at first I started to use tiny objects to put constraint checking in so that it didn't get propagated everywhere. But, something strange happened. These tiny objects started to take on more functionality and have real protocols beyond just get and set of their values.

I think tiny objects are even more important in dynamic languages than in Java. They can make stupid programming errors easy to find and correct. Also, your functionality is spread across several single responsibility objects working in concert to provide complexity.

Tiny objects are good design period.

The Power OF Smalltalk Compels Thee

I've been talking with Edward Povazan lately and showing him Smalltalk to give him ideas for the Eclipse Groovy plug-in and he had some nice things to say here: Crazy Sensible Smalltalk - random ripples. I think us Smalltalkers forget what a unique experience we have inside of our tools. It's great to get someone excited about our world and show off what's possible. I'm hoping for great things to come for the Eclipse Groovy plug-in. ROCK!

Java VM Puts Shackles On Development Tools

I love showing off Smalltalk. It never ceases to impress people with what you can do with it. One thing java developers find strange is no pauses in your work flow. What do I mean by that? Smalltalk compiles on the fly and immediately links in the new code. The time to compile one little piece is almost instantaneous to us. But, to developers not used to this environment, it feels weird. The Smalltalk IDE image comes up immediately (pick any Smalltalk and it's the same story). Strange, it takes a few minutes to even start up Eclipse. Smalltalk just feels like magic and we've been taught to mistrust magic.

But, this post is not about how foreign Smalltalk is to java developers, but how still in 2007 with dynamic languages finally getting recognition that few people are screaming for the capabilities of a Smalltalk VM. The productivity of Smalltalk owes not only to its dynamic nature, but to its always running and lively IDE. It's a living environment. Objects are alive and not dead. Why are there not other environments that do this? (OK, Lispers, I didn't forget about you...anyone else?) And why aren't these environments in the newer dynamic languages (Ruby, Python, Groovy, etc)? Have the shackles of the java runtime environment ruined us?

Or maybe the problem is just that we are always thinking of runtime and not development time. Java places a lot of barriers in the way of developers in the name of security. Why not have a specific VM purely for development? One that could dynamically load classes and code. One that could take snapshots of the running system and save the state for later. One that could compile incrementally and keep all of the bookeeping in order so that our tools stay snappy. One can dream.

Now, for Ruby and Python, there is no excuse. They have their own VM and why don't they support IDEs to implemented in themselves? Java, Groovy, and Scala have the excuse of the java VM. One of my hopes for Ruby was a Smalltalk-like IDE, but sadly, I don't think it will ever happen. The first step would be not to throw away the source code when they compile.

The thing that makes Smalltalk IDEs so cool is that they are alive. The VM supports object mutability and snapshotting state. The whole IDE is written in Smalltalk and is part of the live development system. You don't have to restart anything to try something out or shut down the everything to run a new tool. It morphs into what you want and let's you do what you want. No shackles.

This is what I want from the new generation of dynamic languages. I wonder how hard it would be to have a development java VM. Hmmm....

Omaha Dynamic Language Group

Has it already been a month? Wow. We have a stupendous talker this month, Axel Jenson. He will be presenting the us the new Flex framework and showing off the next verion of ECMAScript: ActionScript! This promises to be a talk that you will be talking about for months. I've heard it will make you instantly download Flex and try out all the cool things it has.

Want more? How about sponsorship from ProKarma, Inc. (eSymbiosis)! They will be providing us with a door prize, pizza, and drinks.

This is one exciting meeting that you can not afford to miss. I will see you all there!

Topic	Flex/ActionScript
Speaker	Axel Jensen
Time	April 3, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE