Practices of an Agile Developer

I just finished reading "Practices of an Agile Developer". It's filled with tons of practical advice. I think it should have been called "Practices of a Good Developer. Period.", but I doesn't have the nice sexy ring to it. It's extremely short and they touch on the topics. It's great if you don't have a lot of time on your hands. I still recommend "Code Complete 2" for more coverage on good practices. But, I loved the "how to work with people" aspect of it which is unusual in technical books, but common in manager texts. The devil/angel quotes were cute and entertaining. It's certainly not a dull moment with lots of excellent analogies (common for the pragmatic programmer series). Anyway, I recommend it and it doesn't take long to read at all.

Back To Opera

I downloaded the lastest Opera today. I left Opera a year ago because Firefox held so much promise. Well, I liked the thoughts behind Firefox (Javascript coding with GreaseMonkey, Plug-ins, etc), but I have decided to return to Opera. It's faster. The interface is better planned and it just fits the way I browse the web. Oh, did I mention it was faster and doesn't hog the CPU at weird times? Opera is love. I am going to miss Sage though.

What A Compliment!

Brent Adkisson just started his blog and gave me a compliment. Perhaps one of the best that I've ever heard. It'll be one of those that I stash away for those rainy negative days.

If you know Blaine you have had a glimpse of one of the best coding minds I have ever had the pleasure to meet.

Wow! Brent is too kind. I don't think I would go that far...I'm still a journeyman in my mind. Brent is a great guy. Always laughing and smiling and never ceases to put me in a good mood. Oh, and did I mention, he's a kick ass coder as well?! I only keep the best company (so I always plenty of brains to learn from).

Iterable and for

I love the fact that there's a new interface in java.util: Iterable. Why you might ask? Could it be for the new shorthand for?

List someList = ... ;
for (SomethingCool each : someList) {
   ...
}

Well, that would be one reason to get excited. Close, but no cigar, no, I like the fact that the method iterator() has been split from java.util.Collection. It allows one to have infinite collections. Most of the time, you don't care how large the collection is, you just want to traverse over its elements. Iterable allows you to do just that. All you care about is that it can produce elements. This means if you have a large file, you could read it in chunks without anyone being the wiser. They would just have an Iterable object and not know how things worked in the back end. Encapsulation at its finest.

  String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader) {
    ...do something cool with each record...
  }
  class RecordReader implements Iterable {
    ...
  }

The client of RecordReader knows nothing about how many records are read in from the file at once nor should they care. They just want each record. We could for example read in 500 records in at a time or just one. It doesn't matter. We could even pass how many to read in at once as an argument to on. Throttling is left to us as a performance enhancement in one class.

Iterables allow us to have true object streams. How cool is that! For giggles, we could have also implemented it totally differently. This time I return an Iterable when asked instead of making the RecordReader implement it. I like this approach much better.

String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader.records()) {
    ...do something cool with each record...
  }
  class RecordReader{
    ...
    public Iterable records() {
      ...
    }
  }

The naive (or simplest) implementation of records() could simply return the entire collection of the file using an ArrayList. And when the file got too big, then move to a custom Iterable object that could read in chunks of the file. By putting iterator() into its own interface, we got a greater flexibility beyond the nice new for sugar. Polymorphism is a wonderful thing wouldn't you agree?

I use Iterables all over the place in my Reflective Testing Framework to traverse over classes, class path items, and methods. It allowed me to have a nice pipes and filters pattern throughout the code. It also made it easy for others to extend what I have done. Have fun! Iterable might be the best new feature of Java5.

Talk Went Great!

Matt Payne had great things to say about my talk:

"a Java 5 tour de force presentation that was backed up with a whole bunch of fantastic BSD licensed code"

WOW! You can't ask for a better compliment than that! Harish Keshwani had good things to say as well.

The thing that shocked me the most was how well my talk and Matt Secoske's on Performance fit so well together. We discussed our presentations before the meeting, but didn't plan on them being such a one-two punch! It was very cool.

I can't wait to expand the code that I have. ROCK!

Automated Standards Enforcement

In celebration of my talk tomorrow night, I have started a page on Automated Standards Enforcement. There's not a lot of content there yet. But, I plan on adding plenty of examples and more resources. Right now, I link to a bunch of books, articles, and my two frameworks. One is written for Squeak and the other Java 5. Both have source and tests available. I'm going to try to have the Java presentation up soon. My talk from Smalltalk Solutions is already there. Enjoy!

Right On

Mike Bowler said:

The majority of programmers fall into the non-expert category. They can see the differences between some of the less powerful languages like Visual Basic or Java™. They do not, however, understand how much more powerful some languages are.

You have to have a deeper understanding of languages to be able to compare them effectively. If you don't understand closures or continuations, for example, then you won't understand why languages that support them are more powerful than languages that don't. If you don't have a good grasp on the idea of self modifying code then you have no hope of understanding why lisp macros are so incredibly powerful.

Someone who only knows languages like Java™ or Visual Basic or C#, will not be able to appreciate why Smalltalk (or Ruby, or Lisp, or ...) is a more powerful language than what they already know.

Right on!

Four is The Perfect Team Size

The most successful teams that I have been have all been small. In fact, I've long believed that four was the perfect team size (three the minimum, and five the max). Of course, this was simply a gut instinct. It has been experience. I never thought to look up an research on the matter.

I was talking with my co-workers today and about fell over myself when one of the mentioned that the optiomal team size was three to five. I asked him why he felt this and he said, "Well, I found some research that says so." The look on my face must have been priceless. Eagerly, I asked him to give me the papers. He kindly told me to google "Optimal Team Size". I asked him what made him look it up and he replied, "I wanted to know the optimal group size for role playing games."

Here are the best articles that I found. Enjoy reading! All of it gave me lots of information to chew on.

The most telling quote was one by Steve McConnell. He not only advocates a small team, but relates what we've always known: code quality is dependent on the qaulity of the programmer. Methodology plays a little role in all of that. It's all about the people. Check it out:

According to Capers Jones's "Program Quality and Programmer Productivity" (IBM Technical Report TR 02.764, Jan. 1977), on small projects, construction errors make up about 75% of all errors found. Methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the program.

On typical larger projects, construction errors taper off to about 50% of total errors, while requirements and architecture errors make up the difference. Presumably, this is related to the fact that proportionately more time is spent in requirements development and architecture on large projects, so the opportunity for mistakes in those activities is proportionately larger.

I thought it was cool that there was research out there to prove my gut instincts.

Lead Vs. Follow

It is written that a great leader is not only good at leading, but following too. The same rule can be applied to coders. Sometimes you take the lead over a design when you feel the passion and other times you let someone else take the reigns. The important thing is not to feel the need to always be the one in charge. Let others lead.

Following does not mean to blindly go over the cliff, but to question and suggest. Realize that the person leading has the final decision. Without a clear leader, tug of wars result in code decay of the worst kind. Trust your team partner, but make sure your communication is clear when you disagree.

Too many times developers get into the mindset of always wanting to be the lead dog. Resist the urge. Learn to standback, do things differently, and most importantly grow and learn from doing a design differently. You will also gain the respect and admiration of your team. If you want people to support you, you must support them too.

When Is Too Complex, Too Complex?

This Java Generics FAQ is a whopping 433 pages in PDF form. Holy Moses! I went to print it out at work and was shocked by the size. The special cases are simply amazing. There's things that I hadn't even thought about it. It's comprehensive and well-written. 433 pages is a whole book on one small feature.

I've been using Java 5 at work and I must admit it makes developing proper frameworks possible, but it also complicates matters. It made my life as a framework developer nicer, but made the life of my user more difficult. Features should make my user's life easier, not mine. Simplicity is the key to good design.

Re: Cool Block Idea

Colin Putney was kind to inform me that #--> method from the previous is already implemented in Squeak! In Squeak, it's called #in:. So, the code before looks like this now:

((2 in: [:x| x * x ]) in: [:x| x + 5 ]) in: [:x| x sqrt ]

How cool is that?

Cool Block Idea

Howard Oh had the following suggestion on comp.lang.smalltalk.dolphin:

Block is one of the reasons that makes Smalltalk so lovable. But sometimes, block can make expressions very hard to read, because we human read parameter object first and then read inside the block just like Smalltalk runtime would do. This makes our reading cursor jump to right end and then back to left.

A guick example that can depict this point can be...

[:x| x sqrt ] value: ([:x| x + 5 ] value: ([:x| x * x ] value: 2))

An idea came up to me a few minutes ago,

Define a method for Object

Object>>--> aBlock

    ^aBlock value: self

This new method can transform the example expression to...

2 --> [:x| x * x ] --> [:x| x + 5 ] --> [:x| x sqrt ] 

What a cool idea! How I love messages and closures!

Why I Love The Smalltalk And Ruby Communities

This discussion on Lisp and its community is revealing. I've found comp.lang.lisp to be imitidating, not because of the hostility of some of the posters, but because everyone is so scary smart. It seems a lot of people have felt the wrath of impatient masters. The discussion shows a community taking a good long hard look at itself.

I remember not looking at PLT Scheme for years because of their poor behavior at Lightweight Langugages Conference Two. Matz gave a talk at the same conference and it's when Ruby won my heart. The community follows his lead. I have had nothing but great experiences in the Smalltalk and Ruby communities. I am thankful for that. The exchange of ideas and enthusiasm of people is contagious. I wish the same for the Lisp community.

I guess I'm shocked. I've always found Lisp folks to be helpful. The Lisp community has a lot going for it with two new books published last year. Renewed interest from a young audience is growing. I say forget the past and bury all hatchets. Start new. Lisp and Scheme are mad fun.

Upcoming Talks

I almost forgot to post about the talks that I'm giving in the near future. If you're in the Omaha area, please stop by. It's going to be a blast!

June 20,2006 - Reflective Testing In Java
Omaha Java User's Group
This is my talk from Smalltalk Solutions geared toward Java. The idea is the same, but the implementation is different. I will show how JUnit with other technologies can be used for contract enforcement and uncovering design smells. If you have any interest in meta/reflective systems or AspectJ, then this might be the talk for you. The presentation is itself written in Java5/AspectJ using the Eclipse/SWT APIs. Expect the unexpected! Learn how automation in testing can not only verify your code, but your designs as well! Stop code smells before they stink.

July 11, 2006 - Seaside
Omaha Dynamic Language User's Group
My infamous Seaside presentation updated for 2006! Same Smalltalk goodness, but with added more. I plan on adding topics for persistence and Seaside/Javascript integration. See the future of web development. Seaside is unapologetic in many of its stances and it makes for an extremely elegant framework. This is a great talk if you're curious about Smalltalk to see the power of the environment and language.

I hope to see everyone there at BOTH!

National Day Of Slayer

Yes, I will be observing National Day Of Slayer tomorrow. They are the band that got me started down the road to extreme music. Long live metal! I will be playing "Reign in Blood" and "South of Heaven" as loud as I possibly can.

A Dare

I have a simple dare. In fact, it's a triple dog dare to all developers. Are your ready? Here it is:

Stop using the same examples to show how great your favorite technology is.

Programming in general has "Hello, World" and every beginning programming book uses it. Even worse is the heavy use of "foo bar" in all its forms. Used to be cute, but not any more.

But, the worse by far is the fibonacci sequence used by every beginning functional programming article to prove the elegance of recursion or functional pattern matching. Come on. There are examples that prove it much better (pick anything in the real world). And that leads me to the final one...

ATMs are used as the example in almost every book in OO design. It's played to death and no longer interesting. Certainly, there's better examples than that out there now, right? And no, don't continue with the bowling example. It's already a cliche in all of the agile books.

Computer science is an exciting field filled with untapped potential and great ideas. But, cliched examples, while good for comparisons, fall flat in their simplicity. Fibonacci doesn't show the elegance obtained from functional programming. Much like showing that you can create a function to add one to prove the elegance of closures. I think a meatier example grounded in the real world will excite the reader much more. This is my dare. Dare to write an original example that makes me realize how clever you are and not @#$%^& ANOTHER FIBONACCI EXAMPLE?!

Code As Prose

Reading great code is like reading a great book. If you don't believe me, download Seaside or Dolphin Smalltalk. Of course, there's more examples than just that (Lisp 1.5 manual, Paul Graham's Lisp books, Structure and Interpretation of Computer Programs, etc), but I digress. You might now think I'm off my rocker and my brain is burnt from too much heavy metal music. But, I have a point to make.

There are simple rules to follow when writing: Outline your ideas; know your audience; and be concise. I'm sure there's more, but these are the three that I strive for. The funny thing is that these concepts correlate directly to code. Code is not merely communicating with the compiler and making things happen. If your software does anything of value or importance, it will be read by other people.

The act of design is the way we frame our ideas before we code. It allows us to plan out the high level view. It should not spell out everything, but give a blue print to how things will interface. It's the journey of thinking about the design that helps us. Code with a clear design is easier to maintain. Otherwise, it's a collection of incoherent thoughts glued together that might execute, but breaks often.

Writing your program for the computer is flat out wrong. In reality, the computer never really reads your code nor does it have to. It's the poor person awoken at three o'clock in the morning because a developer forgot to check for a null condition. It's the team interfacing their project on your library. In short, it's humans. We know this. Your audience is fellow developers. Take the extra time to name your variables well. Don't succumb to i,x,y, index, or each. Think about what business functionality you are implementing and write in that language. What if you had to give your code to someone non-technical? Could they understand what the code was doing? They should. Requirements live on in the program listing. Always strive for creating a domain specific language inside of your code.

Don't repeat yourself. I can't say it more simply. Don't be too clever and be concise. Prevent clutter from ruining the flow of a good program. Try to say the most with the least. It's good advice in art, writing, and programming.

There's probably more parallels that I could draw from, but I thought to keep this post simple. I enjoy reading books on good writing because I can try out new ideas for writing my code. I'm always asking myself how I could write something better for other developers to read. You can't learn from or maintain unreadable code. It's not hard to write well. It just takes practice. I'm amazed at how much code I read that is written for the computer. There's an over abundance of good code out there. The only way to become a great author is by reading great authors. Open source gives us a plethora of great code to admire and learn from. Get reading!